(Dernière mise à jour mars 2014) Cet article est le dernier chapitre d’une trilogie. Le raffinement ultime, si vous voulez. Tout a commencé avec mon incursion dans les eaux troubles du contexte, lorsque j’ai testé comment les données météorologiques pouvaient être utilisées pour fournir des informations supplémentaires sur les visites de sites. Lorsque j’ai écrit cet article, j’avais deux appréhensions : 1) l’envoi de l’appel d’API avec chaque vue de page affecte-t-il négativement les performances du site, et 2) forcer l’appel de vue de page à attendre la fin de l’appel d’API affecte-t-il la qualité de la visite ? métrique.
J’ai corrigé (1) à ma satisfaction dans un article ultérieur sur l’utilisation d’un cookie personnalisé pour effectuer l’appel API une seule fois par session. Cela signifie que les performances du site se sont améliorées, puisque l’appel API (qui peut prendre jusqu’à 500 ms) n’est effectué qu’une seule fois par visite. En outre, cela a un effet positif sur le calcul des visites, car la possibilité que l’appel de la vue de la page échoue en raison de problèmes dans la chaîne d’événements est minimisée.
Cependant, je n’étais toujours pas content d’avoir tout code exécuté avant la vue de page, car les vues de page sont quelque chose que vous ne voulez pas compromettre en raison, par exemple, de problèmes avec une API tierce (telle que l’API météo).
J’ai donc fait ce que j’aurais dû faire tout du long.
Des dimensions personnalisées peuvent également être envoyées avec des événements
Voici un petit historique. J’ai un script qui interroge une API météo, avec l’emplacement du visiteur comme paramètre. Le script collecte les conditions météorologiques dudit emplacement et les transmet à un portée de la visite dimension personnalisée, qui est ensuite envoyée à Google Analytics.
Une dimension personnalisée limitée aux visites (ou sessions) signifie que vous n’avez qu’à l’envoyer une fois par visite. Tous les accès suivants et précédents (pages vues, événements, transactions) de la visite sont également annotés avec la dimension. Naturellement, c’est une évidence d’envoyer ainsi la dimension une seule fois par session, d’où la nécessité d’un cookie personnalisé (encore une fois, voir ce post).
De plus, puisque vous pouvez envoyer la même dimension personnalisée avec un événement, pourquoi même utiliser une vue de page ? Un événement sans interaction fait la même chose PLUS vous pouvez comparer le nombre d’événements météorologiques et de visites de la même période pour voir s’il y a des écarts qui indiquent des problèmes avec l’appel API.
Un autre avantage, si vous utilisez GTM, est que vous n’avez pas besoin de balises de vue de page séparées et déroutantes (une avec la dimension météo, une sans), mais vous pouvez plutôt avoir votre balise de vue de page de base pour le suivi et une balise d’événement pour envoyer le données météo (qui ne se déclenchent que lorsque l’appel API est effectué).
Mise en œuvre
Eh bien, je dois me référer au code de mes deux messages précédents. Voici à quoi devrait ressembler la NOUVELLE balise HTML personnalisée (rappelez-vous que vous devez charger jQuery et le service geoPlugin pour que cela fonctionne).
<script> if (typeof({{Session alive}}) == "undefined") { var lat = geoplugin_latitude(); var lon = geoplugin_longitude(); var weather = ""; var weatherAPI = "http://api.openweathermap.org/data/2.5/weather?lat="+lat+"&lon="+lon; $.ajax({ type : "POST", dataType : "jsonp", url : weatherAPI + "&units=metric&callback=?", async : true, success : function(data) { weather = data.weather[0].main ; dataLayer.push({"weather": weather}); },error : function(errorData) { console.log("Error while getting weather data :: "+errorData.status); dataLayer.push({"weather": "Undefined"}); },complete : function() { dataLayer.push({"event": "weatherDone"}); } }); } var d = new Date(); d.setTime(d.getTime()+1800000); var expires = "expires="+d.toGMTString(); document.cookie = "session=1; "+expires+"; path=/"; </script>Voici l’ordre des événements :
-
Vérifier si un cookie nommé “session” existe
-
Si cookie n’a pas existent, utilisez l’emplacement du visiteur pour interroger les conditions météorologiques à cet endroit
-
Enregistrer les conditions météorologiques dans la variable de couche de données “weather”
-
Envoyer l’événement “weatherDone” à la couche de données, que l’appel d’API soit réussi ou non
-
Enfin (indépendamment de l’existence ou non du cookie), réinitialisez le cookie de “session” pour qu’il expire dans 30 minutes
Donc, pas besoin d’un deuxième événement “noWeather” pour la vue de la page sans temps. Vous pouvez simplement envoyer la vue de page normale à chaque chargement de page, puis utiliser “weatherDone” comme règle de déclenchement pour l’événement (n’oubliez pas d’en faire un hit sans interaction) qui envoie la variable “weather” en tant que dimension personnalisée. Mort simple.
Enfin, vous devrez configurer votre tag d’événement. N’oubliez pas que vous devez créer la dimension personnalisée dans la section d’administration de Google Analytics (voir ici pour un guide). Notez le numéro d’index attribué à votre nouvelle dimension personnalisée au niveau de la session.
Ensuite, créez une nouvelle balise d’événement. Maintenant, vous pouvez avoir tout ce que vous voulez comme champs d’événement, mais assurez-vous que Coup sans interaction est réglé sur Vrai. Dans cet exemple, j’envoie mon type de temps et ma température personnalisés (ce sont des macros de variable de couche de données), mais comme vous pouvez le voir, Coup sans interaction est Vrai. C’est important, car alors cet événement météorologique ne le fera pas affecter le calcul du taux de rebond (parce qu’il ne dit rien sur l’engagement maintenant, n’est-ce pas ?).
Et voici à quoi ressemblent les paramètres de dimensions personnalisées. Vous les définissez à la fin de la balise, sous Plus de réglages.
Conclusion
Je pense que j’ai tout compris maintenant. J’ai trouvé une méthode pour
-
interroger les API externes pour obtenir des informations contextuelles
-
envoyer ces informations une seule fois par visite
-
utiliser un événement sans interaction pour annoter les visites avec cette dimension
Les prochaines étapes consisteraient à s’assurer que l’API est fiable et rapide. En outre, peut-être qu’une sorte de déclencheur de délai d’attente pour l’appel d’API devrait être en place, avec une valeur “weather”: “Undefined” envoyée si l’appel d’API ne se termine pas.
