Il y a une nouvelle version de ce post pour GTM V2 ici.
En parcourant mon article précédent sur l’utilisation des conditions météorologiques pour segmenter les données dans Google Analytics, j’ai commencé à réfléchir aux problèmes de performances. Étant donné que j’utilise une dimension personnalisée de portée de visite, il semble futile de lui faire envoyer les détails météorologiques à chaque chargement de page. Les chances que le temps change radicalement au cours d’une visite sont minces (sauf si vous vivez au Royaume-Uni), et je n’ai pas encore trouvé de bonne raison de changer mon comportement sur place car le temps est passé d’une bruine à une averse.
Avec Universal Analytics, il n’est pas possible d’extraire les données de session du cookie défini par le service. En effet, l’ID client personnalisé défini par le cookie est “utilisé ultérieurement par Google Analytics les serveurs pour calculer le visiteur, session, et les données de campagne. » (c’est moi qui souligne; voir le guide du développeur). Ceci est pertinent car je veux que mon JavaScript personnalisé ne se déclenche qu’une seule fois, en début de session (visite). Je n’ai aucun moyen d’utiliser le _Géorgie-cookie puisque, comme indiqué ci-dessus, il calcule les données de session dans les entrailles des serveurs de Google Analytics.
Pour surmonter ce problème, je crée un cookie de session personnalisé, qui imite les propriétés par défaut du cookie Google Analytics, principalement en ce sens qu’il expire également après 30 minutes d’inactivité.
Notez qu’il ne s’agit pas d’une émulation précise à 100 % de la façon dont Google Analytics calcule les sessions. Le cookie ne tient pas compte des changements de sources de campagne qui, par défaut, initient toujours une nouvelle session dans Google Analytics. Les recherches préliminaires montrent que la précision est d’environ 95 %, bien que j’obtienne également des résultats manqués sur l’API Open Weather, ce qui signifie que le cookie est en fait encore plus précis.
Comment ça fonctionne
J’essaie d’être générique ici, mais je vais utiliser un exemple concret du script météo que j’ai créé précédemment.
Voici comment fonctionne l’implémentation :
-
Lorsque le visiteur arrive sur le site, mon script recherche un cookie nommé “session” à l’aide de Google Tag Manager. Macro de session
-
Si le cookie existe, cela signifie qu’une session est toujours active et qu’aucun code n’est exécuté sauf pour une réinitialisation du délai d’expiration du cookie
-
Si le cookie n’existe pas, cela signifie que la session a expiré, et dans ce cas j’exécute le code météo puis crée le cookie
Si vous essayez de créer un cookie qui existe déjà, il écrase le cookie d’origine. C’est pourquoi je peux utiliser le même code de configuration de cookie pour (2) et (3) ci-dessus.
Puisqu’il s’agit d’un cookie propriétaire et qu’il est défini sur le chemin racine du site (/), il n’y a aucun risque d’écraser d’autres cookies (à moins qu’un autre plugin de site n’ait un cookie nommé “session”).
Le code des cookies
Ma solution de suivi météo d’origine s’est déclenchée à chaque chargement de page. Cela crée une charge importante pour l’API ainsi que pour les performances du site (car le déclenchement du script d’API peut prendre près d’une demi-seconde). Mon nouveau code ressemble à ceci :
<script> if (typeof({{Session alive}}) == "undefined") { // Weather tracking code here } var d = new Date(); d.setTime(d.getTime()+1800000); var expires = "expires="+d.toGMTString(); document.cookie = "session=1; "+expires+"; path=/"; </script>Comme vous pouvez le voir, l’ancien code n’est exécuté que si la macro {{Session en cours}} n’est pas défini, c’est-à-dire que le cookie n’existe pas.
La création de la macro est extrêmement simple :
-
Créer une nouvelle macro appelée “Session en vie”
-
Définir le type de macro Biscuit propriétaire
-
Définir le nom du cookie “session”
Donc, ce que vous faites ici est de créer une macro qui renvoie la valeur du cookie “session”. Chaque fois que cette macro est référencée dans le code, vous utilisez en fait la valeur du cookie.
Lorsque j’interroge ce cookie dans le code ci-dessus, je ne m’intéresse en fait qu’à savoir si ce cookie existe ou non. C’est pourquoi j’utilise le if(typeof({{Session active}}) == “non défini”) structure. Si le cookie n’existe pas, la macro n’a pas de référence, ce qui signifie qu’il s’agit d’un indéfini structure.
Enfin, que le cookie ait été trouvé ou non, un cookie nommé “session” est créé avec une date d’expiration 30 minutes dans le futur (1 800 000 millisecondes plus tard).
Avantages et inconvénients
Évidemment, faire en sorte que l’API encombrante ne se déclenche qu’une seule fois par session est une victoire pour les performances du site et pour l’analyse des « meilleures pratiques ». Parce que j’ai déjà un visite– dimension de portée, il serait contre-intuitif de l’envoyer avec chaque accès à une page vue.
Les principaux problèmes, tels que je les vois, ont à voir avec l’entretien. Si vous avez un délai d’expiration personnalisé pour la session GA, vous devez vous rappeler de modifier également la date d’expiration (maintenant 1800000 millisecondes) dans le cookie “session”, si vous souhaitez qu’il imite les performances de Google Analytics. Aussi, si vous avez déjà un cookie nommé « session » qui se déclenche sur votre site, vous devez changer le nom de celui-ci.
Un autre problème a été discuté dans les premiers paragraphes de ce post. Il ne s’agit pas d’une émulation précise à 100 % du calcul de session Google Analytics, vous aurez donc une légère marge d’erreur dans le nombre de visites avec la météo comme dimension par rapport au nombre de visites sur votre site. N’hésitez pas à explorer comment rendre le calcul d’une session GA encore plus précis, et envoyez-moi un message si vous trouvez quelque chose d’intéressant 🙂
J’aimerais vraiment que je puisse lier mon code au réel _Géorgie-cookie, mais autant que je sache, ce n’est pas possible.
ÉDITER: Voir cet article sur l’envoi de dimensions personnalisées avec des événements pour une mise en œuvre plus intelligente de l’idée ci-dessus.
