Suivi inter-domaines dans les sous-domaines

Attendez. Quoi? Pourquoi écrire un article sur quelque chose qui devrait fonctionner par défaut dans Universal Analytics ? Je veux dire, voici une capture d’écran du guide auquel je viens de faire un lien dans la phrase précédente :

Le voilà. Clair comme le jour : “Le suivi des utilisateurs dans les sous-domaines ne nécessite aucune configuration supplémentaire.” En outre, certains des récents, excellent Les guides de suivi inter-domaines, écrits par E-Nor et Bounteous appliquent la même chose : vous avez juste besoin d’une balise Universal Analytics par défaut dans Google Tag Manager.

Eh bien, malheureusement, ce n’est pas vrai. Vous avez besoin d’un paramètre de configuration, mais c’est heureusement très simple.

TL ; RD : Dans le Champs à définir de votre balise Universal Analytics (page vue), ajoutez le paramètre suivant :

Mais comme tu es génial, tu n’es pas venu ici pour la sale vérité, tu veux savoir Pourquoi Ceci est nécessaire. Alors lisez la suite !

Comment Universal Analytics écrit les cookies

Pour suivre le même utilisateur et la même session sur deux pages, ces pages nécessitent les éléments suivants :

1. Un objet de suivi qui effectue le suivi vers le même ID de propriété Google Analytics (UA-XXXXXX-Y)

2. UN _ga cookie qui a le même identifiant client

L’ID client est ce qui est utilisé pour assembler les hits de la session, et également pour assembler les sessions que le même utilisateur a eues dans un niveau commun d’agrégation (le concept GA d’un utilisateur).

Maintenant, si vous ne pas avez des personnalisations dans votre balise Universal Analytics, voici la logique avec laquelle les cookies sont écrits :

1. Si le nom d’hôte de la page (http://c’est le nom d’hôte/home/) commence par www., le “www” est supprimé et le cookie est écrit sur ce qui reste. Ainsi, dans le cas de www.simoahava.comle cookie est écrit sur .simoahava.com.

2. Sur tous les autres noms d’hôte, le cookie est écrit sur le nom d’hôte lui-même, précédé d’un point. Donc, test.simoahava.com récupérerait un _ga cookie écrit sur .test.simoahava.com

S’il est précédé d’un point, comme le _ga cookie est, le cookie peut être utilisé sur tous les noms d’hôtes qui contenir cette chaîne. Alors le .simoahava.com cookie peut être utilisé par test.simoahava.com, www.simoahava.com, simoahava.comet immortel.genius.simoahava.compar exemple.

Les .test.simoahava.com cookie, en revanche, peut être utilisé par www.test.simoahava.commais pas par www.simoahava.comcar ce dernier ne contient pas la chaîne « test.simoahava.com ».

Pouvez-vous voir où je veux en venir?

Si le trafic va de www.simoahava.com à test.simoahava.com, le _ga cookie est partagé, et tout va bien. Droite?

Cependant, si le visiteur visite pour la première fois test.simoahava.com, et ensuite migre vers www.simoahava.com, ces deux domaines auront différent _ga cookies, et donc des ID Client différents, et donc l’utilisateur sera un utilisateur différent avec une nouvelle session !

Il est donc clair que dans de très nombreux cas, cela entraînera des problèmes. Nous devons nous assurer d’une manière ou d’une autre que _ga le cookie est toujours écrit sur .simoahava.com, afin qu’il puisse être utilisé par tous les sous-domaines, qu’ils aient ou non “www.” ou autre chose comme préfixe.

cookieDomain : auto

La réponse est dans le cookieDomain paramètre. Lorsque vous définissez cookieDomain sur autoce qui suit se produira avec un domaine (fictif) comme www.simoahava.co.uk:

1. GA essaie d’écrire le cookie sur .co.uk, qui est le premier candidat de domaine racine possible. Cela échoue car le navigateur n’est pas autorisé à écrire un cookie sur un domaine de premier niveau comme celui-là.

2. Ensuite, GA essaie d’écrire le cookie sur .simoahava.co.uk, qui est le prochain candidat de domaine racine possible. Cela fonctionne car il s’agit d’un domaine valide sur lequel écrire le cookie.

Il existe donc un algorithme récursif, qui essaie d’écrire le cookie, en commençant par le niveau de domaine le plus générique (le domaine de premier niveau), et en s’arrêtant une fois qu’il réussit. Ce qu’il devrait rester, c’est domaine racineet ainsi le cookie sera disponible pour tous les sous-domaines.

Yay!

La nouvelle recommandation améliorée

Voici la recommandation améliorée pour suivi inter-domaines dans les sous-domaines:

Toujours défaut d’avoir cookieDomain : auto dans les paramètres de votre tracker. Dans GTM, j’ai montré un exemple au début du post.

Dans le code de suivi Universal Analytics, l’extrait ressemblerait à ceci :

<script>   (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){   (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),   m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)   })(window,document,'script','//www.google-analytics.com/analytics.js','ga');    ga('create', 'UA-40669554-1', 'auto');   ga('send', 'pageview'); </script>

C’est en fait ce que le code de suivi Google Analytics, s’il est copié-collé depuis les paramètres de la propriété, offre par défaut, donc tout va bien si vous l’utilisez.

Personnellement, je pense que le réglage devrait toujours par défaut sur “auto” à moins qu’il ne soit explicitement modifié par une autre valeur.

Voici un fil dans Google+ qui m’a inspiré pour écrire ce post.