En 2013, j’ai écrit un guide pour Universal Analytics et Google Tag Manager sur la façon d’interroger les conditions météorologiques et d’envoyer ces informations à Google Analytics en tant que dimension personnalisée de la session. Le guide était conçu comme une introduction technique à Google Tag Manager, et je pense qu’il y est parvenu.

Cependant, GTM a beaucoup changé au cours des 1,5 dernières années, et j’ai apporté quelques améliorations à la méthode en cours de route. J’ai donc voulu mettre à jour le guide pour la nouvelle version de Google Tag Manager (V2), et introduire quelques changements dans le code qui le rendent plus flexible et efficace.

(MISE À JOUR 21 août 2017) – J’ai mis à jour cet article pour qu’il fonctionne avec l’API Weather Unlocked (merci à Kévin Coppens pour l’astuce), car openWeatherMap a mis à niveau son plan SSL à un niveau assez coûteux. Notez que Weather Unlocked nécessite l’utilisation d’une clé API et que la transmission de la clé API côté client est risquée et ouvre votre plan API à des abus. Pour ceux qui veulent prendre cette analyse météo au sérieux, je recommande vraiment de passer à une solution 100% côté serveur, où les données météo sont interrogées avant que la page elle-même ne soit rendue, et les données sont écrites dans le dataLayer de la page.

Comme il s’agit d’un gros message, j’ai un table des matières ici:

1. Ce qu’il fait

L’idée derrière la solution est d’interroger un service météo, de sorte que toutes les sessions dans Google Analytics soient annotées avec des informations sur les conditions météorologiques au moment de la session. La question sous-jacente à laquelle nous essayons de répondre est : “La météo joue-t-elle un rôle dans la façon dont les gens interagissent avec votre site Web ou votre marque ?”. Cela pourrait être une question très pertinente pour les entreprises très dépendantes des conditions météorologiques, comme celles qui ont des terrains de golf et des pistes de ski.

La méthode technique se décompose en trois parties :

1. Géolocalisation – nous devons avoir une approximation de la zone géographique à partir de laquelle le visiteur navigue.

2. API Météo – nous utiliserons ces données de géolocalisation pour interroger les conditions météorologiques dans la région du visiteur.

3. Couche de données – enfin, nous allons stocker toutes les informations que nous recevons dans l’objet dataLayer pour qu’elles soient disponibles pour nos Tags.

Ce n’est pas le processus le plus simple, et il existe de nombreuses façons de l’optimiser (je les expliquerai dans les chapitres concernés). De plus, l’une des principales raisons pour lesquelles ce guide a été écrit en premier lieu est de montrer un prototype pour tout appel d’API générique que vous voudrez peut-être effectuer. Il ne s’agit donc pas seulement de la météo, mais aussi du cours de l’action, des détails du trafic, des résultats du basket-ball, etc. S’il existe une API pour cela, vous pouvez utiliser cette méthode pour enrichir les sessions de vos visiteurs avec de nouvelles dimensions et métriques personnalisées.

La solution elle-même suit le flux suivant, visualisé avec mes compétences folles en PowerPoint :

C’est un processus assez simple, avec seulement deux jonctions : l’état du cookie de session et le succès/l’échec de l’appel d’API lui-même.

2. Exigences de base

Quelle que soit la façon dont vous finissez par résoudre la solution, vous aurez besoin de certains composants de base. Ceux-ci sont:

1. Clé API geoPlugin et informations d’identification de l’API Weather Unlocked

2. Balise HTML personnalisée pour interroger l’API et stocker les informations dans dataLayer

3. Déclencheur pour déclencher une balise d’événement lorsque les données sont dans dataLayer Variables de couche de données pour extraire les informations de la couche de données dans la balise d’événement

4. Variable de cookie propriétaire pour maintenir l’état de la session

5. Dimensions personnalisées au niveau de la session configurées dans Google Analytics pour recevoir les données d’API de la balise

6. Universal Analytics Event Tag pour envoyer les données à Google Analytics

Nous créerons la balise HTML personnalisée plus tard, car elle nécessite un peu plus de travail et de réflexion que les autres exigences de base.

2.1. Déclencheur

Le déclencheur est simple. Il s’agit simplement d’un déclencheur d’événement personnalisé qui se déclenche lorsqu’une clé “événement” avec la valeur “weatherDone” est poussée dans dataLayer. Donnez-lui un nom descriptif, tel que Événement – météoFait.

Assurez-vous que le déclencheur ressemble à celui de la capture d’écran ci-dessus.

2.2. Variables de la couche de données

Dans cette solution, nous utiliserons deux variables de couche de données. Une pour contenir une description simplifiée des conditions météorologiques (par exemple « Nuageux », « Pluie », « Orage »), et une pour mémoriser la température, également simplifiée (par exemple « 5°C – 15°C »).

Créez donc deux variables de couche de données, une pour le nom de la variable la météoet un pour le nom de la variable Température.

La variable ci-dessus est nommée DLV – météo.

Donnez à la deuxième variable un nom tel que DLV – température. C’est la convention de nommage que j’utilise (DLV signifie Data Layer Variable, bien sûr), mais vous pouvez les nommer comme vous le souhaitez.

2.3. Variable de cookie propriétaire

Nous maintiendrons artificiellement l’état de la session à l’aide d’un cookie personnalisé, écrit par le script et actualisé à chaque chargement de la page. La raison pour laquelle nous voulons maintenir un état comme celui-ci est parce que nous ne voulons envoyer les données météo qu’une seule fois par session.

L’appel API au service météo n’est pas léger. Nous voulons éviter autant que possible de faire des appels comme celui-ci, car de cette façon, le processus de chargement de la page ne sera pas entravé par le chargement lent d’appels d’API asynchrones comme celui-ci. Ainsi, lorsque le visiteur arrive pour la première fois sur le site, un cookie est créé qui imite la logique de session de GA en ayant une expiration de 30 minutes. Naturellement, ce n’est pas toute la logique de session (il nous manque des éléments comme les exclusions de références, le suivi inter-domaines, etc.), mais c’est suffisamment proche pour nous éviter de passer des appels inutiles.

Le script de cookie se trouve dans le script d’API réel présenté plus loin dans cet article, mais la variable que vous devrez créer devrait ressembler à ceci :

2.4. Dimensions personnalisées au niveau de la session

Étant donné que nous souhaitons envoyer deux mesures en tant que données supplémentaires, nous aurons besoin de deux dimensions personnalisées pour les stocker. Maintenant, vous vous demandez peut-être : “Pourquoi ne pas utiliser les métriques personnalisées pour la température ? C’est numérique, après tout ? ». C’est une bonne question, et la raison en est que vous ne pouvez pas encore calculer sur les métriques personnalisées. Ainsi, toutes les données de température que vous enverriez seraient cumulées dans vos rapports. Cela n’a pas de sens de demander “Quelle était la somme de toutes les températures pour convertir les visites depuis Helsinki ?”, mais cela a beaucoup de sens de demander “Quelle était la moyenne de toutes les températures pour convertir les visites depuis Helsinki ?”. Ce dernier n’est malheureusement pas encore disponible via Google Analytics.

Quoi qu’il en soit, créez deux dimensions personnalisées de session et nommez-les de manière à les retrouver lorsque vous parcourez vos listes de dimensions. J’ai utilisé simplement “Météo” et “Température”.

Il est important de noter le numéro d’index de dimension pour les deux nouvelles dimensions. Nous aurons besoin de ces informations pour notre tag d’événement.

2.5. Balise d’événement Universal Analytics

La balise d’événement a deux “personnalisations”, si vous voulez. Tout d’abord, nous envoyons ce hit comme un événement sans interaction. Cela signifie que cela n’affectera pas le taux de rebond de la session. La raison en est que les données météorologiques ne sont pas quelque chose qui résulte d’une action du visiteur. Ce ne sont que des méta-informations sur la session, donc ce n’est pas interactif.

Utilisez le déclencheur que vous avez créé à l’étape 2.1. pour déclencher cette balise d’événement.

Pourquoi ne pas utiliser une balise de vue de page, alors ? Une autre grande question. Eh bien, les appels d’API que nous allons effectuer dans la balise HTML personnalisée prennent du temps, car ils sont exécutés de manière asynchrone. Cela signifie que nous ne serons pas en mesure de déterminer le moment de la séquence de chargement de la page où les données sont réellement envoyées, mais nous saurons qu’elles seront différées aussi longtemps que l’appel d’API prendra. Si l’appel prend beaucoup de temps à se terminer, cela retardera le déclenchement de notre balise de vue de page. Ceci, je pense, est définitivement non-non. Les pages vues sont une partie cruciale de la collecte de hits basée sur la session, et les manquer n’est tout simplement pas une option.

Il n’y a aucun inconvénient à utiliser un événement sans interaction.

Quoi qu’il en soit, la balise que j’ai utilisée ici a les paramètres d’événement suivants :

Catégorie d’événement – Temps
Action d’événement – {{DLV – météo}}
Libellé de l’événement – {{DLV – température}}
Non-interaction – Vrai

Ensuite, faites défiler jusqu’à Plus de paramètres et développez Dimensions personnalisées. Ici, vous devrez ajouter deux nouvelles lignes de dimensions personnalisées pour accueillir les deux dimensions qui attendent avidement que les données passent par l’interface GA.

À ce stade, vous devrez vous souvenir ou rechercher les numéros d’index de dimension à partir de Google Analytics Admin. Dans mon exemple, ils sont simplement 1 (pour la température) et 2 (pour la météo), mais n’oubliez pas d’ajuster si nécessaire.

Ajoutez les variables de couche de données respectives aux champs de valeur, comme dans l’image ci-dessus.

C’est tout pour les exigences de base.

La suite devient assez compliquée.

3. Construire le script

Si vous vous souvenez du début, cette solution technique se divise en trois parties : la géolocalisation, la requête météo et le stockage des informations dans dataLayer.

Pour commencer, vous aurez besoin d’une balise HTML personnalisée qui utilise le Toutes les pages Déclencheur. Donnez-lui un nom descriptif. j’ai utilisé Utilitaire – HTML – Requête météomais, encore une fois, vous êtes libre d’utiliser votre propre convention de dénomination.

Ce code a été réécrit pour fonctionner avec les sites protégés par HTTPS. Si votre site n’utilise pas HTTPS, cela sera en grande partie exagéré et inutilement coûteux, mais je vous recommande de mettre à niveau la sécurité de votre site dès que possible.

Le code à l’intérieur, dans toute sa splendeur JavaScript, est celui-ci :

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script> <script>   (function() {     var fetchWeatherData = function(longitude, latitude) {       // You need to sign up to Weather Unlocked for an account. Once you do,       // you will find your APP ID and APP KEY in your account dashboard.       var wuAppId = 'paste_your_weather_unlocked_app_id_here';       var wuAppKey = 'paste_your_weather_unlocked_app_key_here';       jQuery.getJSON('https://api.weatherunlocked.com/api/current/' + latitude + ',' + longitude + '?app_id=' + wuAppId + '&app_key=' + wuAppKey)         .done(function(data) {            window.dataLayer.push({             event: 'weatherDone',             weather: data.wx_desc,             temperature: data.temp_c           });         }).fail(function(jq, status, msg) {           console.log('Weather request failed: ' + status + ' - ' + msg);         });     };               var geoLocateUser = function() {       // This is your API key for GeoPlugin, which you can purchase at       // http://www.geoplugin.com/premium#ssl_access_per_year       var geoPluginAPIKey = 'paste_your_api_key_here';       jQuery.getJSON('https://ssl.geoplugin.net/json.gp?k=' + geoPluginAPIKey + '&jsoncallback=?')         .done(function(data) {           fetchWeatherData(data.geoplugin_longitude, data.geoplugin_latitude);         }).fail(function(jq, status, msg) {           console.log('Geolocation failed: ' + status + ' - ' + msg);         });     };      if (typeof {{Session alive}} === 'undefined') {       geoLocateUser();     }          // Reset "session" cookie with a 30-minute expiration     var d = new Date();     d.setTime(d.getTime()+1800000);     var expires = "expires="+d.toGMTString();     document.cookie = "session=1; "+expires+"; path=/";   })(); </script>

Oh mon Dieu, c’est beaucoup de code. Dans les prochains chapitres, je vous expliquerai exactement ce qui se passe ici.

Il est important de noter que je charge jQuery tout en haut du script. De plus, j’ai enveloppé tout le script lui-même dans un expression de fonction immédiatement invoquée pour étendre toutes les variables à la fonction et ainsi éviter de polluer l’espace de noms global.

Si vous chargez déjà jQuery sur le site, vous ne devez pas le recharger dans cette balise, mais vous devrez alors vous assurer que la balise HTML personnalisée ne se déclenche qu’après le chargement complet de jQuery. Si vous chargez jQuery de manière asynchrone, cela ne vous laisse pas d’autre choix que de déclencher la balise HTML personnalisée sur le Fenêtre chargée Déclencheur, car c’est le seul moment où vous pouvez être sûr que jQuery a été chargé.

Pour la journalisation des erreurs, j’invoque simplement le .fail() rappel des requêtes JSON aux deux API (geoPlugin et Weather Unlocked). En cas d’erreur, le message est simplement écrit dans la console, mais vous pouvez également invoquer un dataLayer.push() pour enregistrer l’erreur ailleurs, comme Google Analytics.

3.1. Géolocalisation

Il existe de nombreuses façons de faire de la géolocalisation, mais pour des raisons de convivialité, j’utilise également un appel API pour cela. Si vous êtes sérieux au sujet de cette solution, vous voudrez peut-être installer un service de géolocalisation sur votre propre serveur Web, afin d’éviter d’avoir à effectuer des appels d’API supplémentaires dans le client.

La géolocalisation repose sur une chose : l’adresse IP du visiteur. Il existe de nombreuses façons d’obtenir ces données, car il s’agit d’informations publiques, exposées dans les en-têtes HTTP des requêtes du visiteur. Vous avez peut-être deviné à ce stade que la précision de la solution dépend donc du type de proxy ou de VPN que le visiteur pourrait utiliser. C’est quelque chose que nous ne pourrons pas contourner, et vous devrez donc prendre les données de géolocalisation, comme toute autre donnée sur le Web public, avec un grain de sel.

Ce dont nous aurons besoin en retour du service de géolocalisation, ce sont la latitude et la longitude du visiteur. La géolocalisation basée sur IP est généralement précise jusqu’à la ville d’où vient le visiteur, mais dans de nombreux cas, il peut s’agir d’un spectre beaucoup plus large, comme un état entier ou même un pays. Néanmoins, nous prendrons ce que nous pouvons obtenir.

La méthode du script utilise une API tout-en-un pour à la fois obtenir l’adresse IP et récupérer la longitude et la latitude de la visite. Le service s’appelle geoPlugin et le plan SSL est relativement peu coûteux.

var geoLocateUser = function() {   // This is your API key for GeoPlugin, which you can purchase at   // http://www.geoplugin.com/premium#ssl_access_per_year   var geoPluginAPIKey = 'paste_your_api_key_here';   jQuery.getJSON('https://ssl.geoplugin.net/json.gp?k=' + geoPluginAPIKey + '&jsoncallback=?')     .done(function(data) {       fetchWeatherData(data.geoplugin_longitude, data.geoplugin_latitude);     }).fail(function(jq, status, msg) {       console.log('Geolocation failed: ' + status + ' - ' + msg);     }); }; 

Dans cette méthode, vous devez d’abord écrire votre clé API dans le geoPluginAPIKey variable. Vous obtiendrez cette clé API en souscrivant à un plan très bon marché chez geoPlugin. Ensuite, nous utilisons le point de terminaison JSONP de l’API geoPlugin pour récupérer les données de géolocalisation de l’utilisateur. Tout est enveloppé dans jQuery extrêmement utile getJSON() méthode.

La requête asynchrone est complétée par la done() callback, qui est invoqué si tout se passe bien. Dans ce rappel, nous transmettons les informations de longitude et de latitude à la fonction suivante de la chaîne : fetchWeatherData().

En cas d’erreur, les informations d’erreur sont sorties dans la console du navigateur.

3.2. Construire l’appel d’API

Alors maintenant, nous avons la géolocalisation. La prochaine chose que nous devons faire est d’utiliser ces informations pour interroger les données météorologiques.

Je utilise le Météo déverrouillé service pour cela. Il a un plan gratuit assez généreux et prend en charge les requêtes SSL et non SSL. (METTRE À JOUR: Il semble que l’API Weather Unlocked Developer pour les requêtes SSL nécessite maintenant un petit abonnement.)

Une fois inscrit au service, vous trouverez votre APP ID et APP KEY dans le tableau de bord.

Le fetchWeatherData() la méthode elle-même ressemble à ceci :

var fetchWeatherData = function(longitude, latitude) {   // You need to sign up to Weather Unlocked for a free account. Once you do,   // you will find your APP ID and APP KEY in your account dashboard.   var wuAppId = 'paste_your_weather_unlocked_app_id_here';   var wuAppKey = 'paste_your_weather_unlocked_app_key_here';   jQuery.getJSON('https://api.weatherunlocked.com/api/current/' + latitude + ',' + longitude + '?app_id=' + wuAppId + '&app_key=' + wuAppKey)     .done(function(data) {        window.dataLayer.push({         event: 'weatherDone',         weather: data.wx_desc,         temperature: data.temp_c       });     }).fail(function(jq, status, msg) {       console.log('Weather request failed: ' + status + ' - ' + msg);     }); }; 

C’est assez similaire à la méthode de géolocalisation. Nous utilisons les informations de latitude et de longitude pour interroger l’API Weather Unlocked. Vous aurez besoin de votre APP ID et de votre APP KEY à portée de main pour cela !

En cas de requête réussie, la réponse est analysée pour la description de la météo actuelle (data.wx_desc) ainsi que la température actuelle (data.temp_c). Ceux-ci sont ajoutés à l’objet dataLayer sous leurs clés respectives.

Notez que tout Ajax les appels sont effectués à l’aide de jQuery. Maintenant, les avantages et les inconvénients d’être dépendant d’un framework externe et gonflé comme jQuery peuvent être débattus, mais jQuery gère parfaitement les requêtes Ajax. C’est parfait pour ce que nous essayons de réaliser ici, donc cela ne me dérange pas d’utiliser le cadre.

Et c’est tout ! La solution est assez simple, reposant sur des requêtes asynchrones enchaînées assez simples. Si l’un échoue, le reste n’est pas exécuté, vous pouvez donc ajouter une gestion des erreurs si vous voulez connaître votre taux de réussite. Mais comme nous utilisons des dimensions personnalisées de session, vous pouvez déjà obtenir un taux de réussite en examinant le nombre de sessions contenant des données météorologiques sur toutes les sessions.

Il ne reste qu’une chose.

3.3. Maintenir l’état avec un cookie

La dernière partie du puzzle consiste à déclencher la balise une seule fois par session. Pour ce faire, nous ne démarrons l’ensemble du processus que si un cookie propriétaire personnalisé a n’a pas été défini. La variable {{Session active}} renvoie indéfini si le cookie n’est pas défini, nous pouvons donc vérifier cela avant d’exécuter la première étape (la géolocalisation).

  if (typeof {{Session alive}} === 'undefined') {     ...the geolocation call...   }            // Reset "session" cookie with a 30-minute expiration   var d = new Date();   d.setTime(d.getTime()+1800000);   var expires = "expires="+d.toGMTString();   document.cookie = "session=1; "+expires+"; path=/"; 

À la fin du script, que le cookie ait été défini ou non, nous créons/mettons à jour le cookie avec une nouvelle expiration de 30 minutes.

Et c’est tout. Facile, non ?

N’oubliez pas de le tester attentivement en mode Aperçu. Vérifiez la console JavaScript pour détecter d’éventuelles erreurs, testez le fonctionnement de la logique des cookies et surveillez les rapports en temps réel dans Google Analytics pour vérifier que les données arrivent.

4. Résumé

Voici donc le script météo pour Google Tag Manager V2. N’hésitez pas à échanger l’API Weather Unlocked avec tout autre point de terminaison d’API que vous souhaitez interroger. Vous devrez étudier l’API, modifier les paramètres et analyser les données différemment, mais la logique est la même.

Ce serait cool de savoir si l’analyse météorologique vous a apporté des informations. Une bonne idée pour modifier le script serait de ne pas simplement suivre d’aujourd’hui météo, mais le temps le week-end prochain ou pendant les vacances. Une Pâques chaude contribue-t-elle à réduire les réservations sur les pistes de ski, et un week-end pluvieux à venir fait-il chuter les ventes de green fee sur le terrain de golf local ?