Comment une couche de données alimente vos tags d'analytics en événements

Qu'est-ce qu'une couche de données ?

En analyse web, une couche de données est un objet JavaScript présent sur la page, dans lequel votre site écrit les événements et leurs valeurs, pour que les tags d'analytics et de marketing lisent des données propres et nommées au lieu de les extraire du HTML. La documentation de Tag Manager de Google en donne la version courte : "The data layer is an object used by Google Tag Manager and gtag.js to pass information to tags."

L'intérêt de la couche, c'est la séparation. Le code de votre application sait qu'un paiement vient d'aboutir et combien il valait. Vos tags savent où envoyer cette information. La couche de données se place entre les deux, et Google énonce directement l'objectif de conception : les tags "are designed to reference information that is added to the data layer in an organized and predictable way, rather than by parsing variables, transaction information, page categories, and other signals scattered throughout your page." Quand une refonte déplace le prix dans une autre <div>, les tags qui lisent la couche de données continuent de fonctionner et ceux qui fouillent la page cassent.

Quels sont les deux types de couche de données ?

Les couches de données prennent deux formes : un objet d'état qui décrit la page, et une file d'événements qui enregistre ce qui s'est passé, dans l'ordre. La forme détermine la façon dont un tag la lit.

Le modèle de l'objet d'état est le plus ancien. Le Customer Experience Digital Data Layer 1.0, un Community Group Final Report daté du 10 décembre 2013, indique que l'objet racine "MUST be digitalData, and all data properties within this specification MUST fall within the hierarchy of the digitalData object." Sa section sur le statut ajoute : "It is not a W3C Standard nor is it on the W3C Standards Track." Les événements vivent dans un tableau à l'intérieur de l'objet, digitalData.event[n], que la spécification définit comme une "List of events that were measured."

Le modèle de la file s'est imposé en pratique à cause de l'ordre de chargement. La documentation d'Adobe en explique l'avantage : les pages et les scripts "can start to register data, to trigger events, and to register callbacks by adding them to the array, even before the data layer script itself has been loaded." Un simple tableau accepte des push avant même que le code d'un fournisseur existe sur la page.

Comment un dataLayer.push devient-il un événement d'analytics ?

Un dataLayer.push() devient un événement d'analytics quand Tag Manager traite le message, fait correspondre sa clé event à un déclencheur et déclenche un tag qui lit les valeurs poussées. La séquence compte cinq étapes :

1. Déclarez le tableau une seule fois, au-dessus de l'extrait du conteneur. Le code d'installation de Google est window.dataLayer = window.dataLayer || [];, placé avant le chargement de Tag Manager.
2. Poussez un message avec un nom d'événement. La syntaxe de Google est dataLayer.push({'event': 'event_name'}), et un même push peut transporter des valeurs à côté de l'événement, comme dans dataLayer.push({'color': 'red', 'conversionValue': 50, 'event': 'customize'}).
3. Tag Manager met le message en file et le traite. Google indique que "Tag Manager processes messages on a first-in, first-out basis: Each message is processed one at a time, in the order it was received."
4. Un déclencheur Custom Event correspond au nom de l'événement. "If the message is an event, any tags with trigger conditions that have been met will fire before Tag Manager moves on to the next message."
5. Une variable Data Layer Variable transmet la valeur au tag, et le tag l'envoie plus loin, par exemple comme paramètre d'événement GA4.

L'étape 4 explique une règle qui piège beaucoup de monde. Un push sans clé event met à jour des valeurs mais ne déclenche rien. Google prévient que les push venant du code de la page "are not guaranteed to be available for the next event", et sa solution consiste à "add an event name to a message as it is pushed to the data layer, and then listen for that event name with a Custom Event trigger."

L'extrait gtag.js utilise la même file. L'extrait de Google définit la fonction gtag comme un wrapper d'une ligne :

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'TAG_ID');

Un site qui fait tourner à la fois gtag.js et Tag Manager a donc un seul tableau qui reçoit les messages des deux. Google est explicite : "Only one dataLayer object is supported per page."

Pourquoi les valeurs de la couche de données se reportent-elles d'un push à l'autre ?

Les valeurs de la couche de données se reportent parce que chaque push est fusionné dans un "abstract data model" en cours au lieu de le remplacer. La bibliothèque open source data-layer-helper de Google, qui documente ce modèle, indique qu'il "holds the most recent value for all keys that have been set by a data layer message." Les scalaires écrasent. Les objets simples et les tableaux fusionnent de façon récursive : les clés d'un nouvel objet sont copiées sur l'ancien objet, et les index d'un nouveau tableau sont écrits par-dessus ceux de l'ancien, en laissant en place tout index que le nouveau tableau ne définit pas.

Cette règle est sans danger pour une chaîne pageType et dangereuse pour l'ecommerce. Poussez une vue de panier avec deux articles, puis un achat avec un seul article, et le modèle peut encore contenir le second article du push précédent. Le guide ecommerce GA4 de Google pour Tag Manager l'évite en vidant d'abord l'objet dans ses 14 exemples d'événements. Son exemple d'achat, raccourci :

dataLayer.push({ ecommerce: null });  // Clear the previous ecommerce object.
dataLayer.push({
  event: "purchase",
  ecommerce: { transaction_id: "T_12345", value: 72.05, currency: "USD", items: [ ... ] }
});

Le null fonctionne parce que null entre dans la catégorie "everything else" du tableau de fusion, et écrase donc l'ancien objet d'un coup. Le push suivant fusionne alors sur du vide. Si vos rapports de revenus affichent des articles que personne n'a achetés, cherchez un vidage manquant avant de vérifier quoi que ce soit d'autre. Le côté GA4 de cette configuration est traité dans choisir des outils de suivi ecommerce sans surtracking.

Qu'est-ce qui casse une couche de données ?

Six erreurs expliquent la plupart des couches de données qui semblent correctes et perdent des événements. Chacune vient de la liste de dépannage de Google ou découle des règles de fusion ci-dessus.

La ligne sur le nommage est l'endroit où la couche de données rencontre le reste de votre instrumentation. Une couche de données n'est cohérente que dans la mesure où la spécification qui la sous-tend l'est, et c'est le rôle d'un plan de tracking, tandis que les noms eux-mêmes suivent les règles de comment une convention de nommage d'événements survit à son premier renommage.

Que doit contenir un push dans la couche de données ?

Un push dans la couche de données doit contenir le nom de l'événement et les valeurs dont un rapport a besoin, et rien qui identifie une personne. Tout ce qui est poussé est lisible par chaque tag du conteneur, y compris les tags ajoutés plus tard par quelqu'un d'autre. Le contenu des champs de formulaire, les adresses e-mail et les noms n'ont rien à faire dans la file ; poussez plutôt un identifiant de formulaire et un résultat, comme le détaille le guide pratique du suivi sans cookies pour les formulaires.

Un test utile est celui que vous appliquez à n'importe quel événement : chaque valeur du push doit répondre à une question que pose un rapport. Si personne ne peut nommer le rapport, supprimez la clé. La pratique sous-jacente, enregistrer les actions comme des événements nommés avec des propriétés, est traitée dans comment le suivi d'événements enregistre ce que les utilisateurs ont vraiment fait.

Tous les outils d'analytics ont-ils besoin d'une couche de données ?

Aucun outil d'analytics n'a strictement besoin d'une couche de données ; la couche existe pour qu'un gestionnaire de tags puisse router un seul jeu de valeurs vers de nombreux fournisseurs. Un outil qui reçoit les événements par un appel de fonction direct se passe de la file et des règles de fusion. Flowsery fonctionne ainsi : son suivi des objectifs enregistre les événements à partir d'un seul appel comme window.flowsery("signup"), avec "No complex setup or tag managers needed." Les événements apparaissent dans un flux en temps réel pour que vous puissiez "Debug and validate your tracking instantly", des valeurs de revenus peuvent être attachées aux événements pour mesurer l'impact de chaque action, et les événements sont suivis sans cookies ni données personnelles. La fonctionnalité de suivi des objectifs et des événements montre la configuration. Les sites qui utilisent déjà une couche de données pour d'autres fournisseurs peuvent la garder, et appeler window.flowsery() depuis le code qui pousse l'événement.

Questions fréquentes

La couche de données est-elle la même chose que Google Tag Manager ?

Non. La couche de données est le tableau présent sur votre page, et Tag Manager est l'un des consommateurs qui la lisent. L'extrait gtag.js de Google utilise le même tableau dataLayer sans Tag Manager, et la couche de données client d'Adobe utilise son propre tableau nommé adobeDataLayer.

Où placer le code de la couche de données sur la page ?

Déclarez-la le plus haut possible dans la page, au-dessus de l'extrait Tag Manager ou gtag.js. Google indique que toutes les valeurs qui "need to be available to Tag Manager when the page loads" doivent aussi être poussées au-dessus du code du conteneur. Les push placés plus bas atteignent quand même la file, mais arrivent après les premiers événements du conteneur.

Puis-je renommer la variable dataLayer ?

Oui. Tag Manager reçoit le nom comme paramètre dans l'extrait de son conteneur, et gtag.js accepte un paramètre de requête l, comme dans l=myNewName. Chaque déclaration et chaque push doivent alors utiliser le nouveau nom, parce que les push vers l'ancien nom n'atteignent rien.

Pourquoi mon événement purchase GA4 contient-il des articles d'un événement précédent ?

Le push précédent a fusionné dans le modèle de données et votre push d'achat ne l'a pas vidé. Les tableaux et les objets simples fusionnent de façon récursive, donc les articles restants survivent. Poussez { ecommerce: null } juste avant chaque événement ecommerce, comme le font les exemples de Google.

Les valeurs de la couche de données persistent-elles d'un chargement de page à l'autre ?

Non. Google indique que chaque variable de la couche de données persiste "only as long as the visitor remains on the current page." Les valeurs qui comptent sur chaque page, comme un type de visiteur ou une catégorie de page, doivent être poussées à nouveau à chaque chargement de page.

Quelle est la différence entre dataLayer.push et gtag ?

gtag() est un wrapper qui appelle dataLayer.push(arguments), donc les deux écrivent dans la même file. La différence tient au format des messages et aux méthodes personnalisées : Google indique que les fonctions poussées pour accéder à set, get et reset "must use .push" directement, parce que gtag interprète une fonction comme "an invalid command" et l'ignore.

Pourquoi mon dataLayer.push n'a-t-il déclenché aucune balise ?

Un push ne déclenche une balise que s'il porte une clé event attendue par un déclencheur d'événement personnalisé. Les valeurs poussées sans cette clé mettent quand même à jour la couche de données, mais Tag Manager n'a rien à comparer, donc aucun déclencheur ne s'exécute et aucune balise ne se déclenche. Ajoutez le nom de l'événement dans le même push, sinon ces valeurs restent en attente jusqu'au prochain message qui en apporte un.

Faut-il utiliser digitalData ou dataLayer pour un nouveau projet ?

Choisissez le modèle de file d'événements, celui que dataLayer et adobeDataLayer utilisent tous les deux. Il accepte les pushes avant même qu'un script du fournisseur soit chargé, ce qui est justement le problème d'ordre de chargement du modèle d'objet d'état. Une balise qui lit digitalData avant que l'objet soit rempli ne lit rien. digitalData vient par ailleurs d'un rapport d'un Community Group de 2013 qui précise qu'il ne s'agit pas d'un standard W3C.

Est-il prudent de pousser des adresses e-mail dans la couche de données ?

Non. Tout ce qui est poussé dans la couche de données est lisible par chaque balise du conteneur, y compris celles qu'une autre personne ajoutera plus tard. Poussez plutôt un identifiant de formulaire et un résultat, jamais le contenu réel du champ, un nom ou une adresse e-mail.

adobeDataLayer est-il la même chose que le dataLayer de Google ?

Les deux sont de simples tableaux qui traitent les messages dans l'ordre, mais ce sont des variables globales distinctes. Tag Manager et gtag.js de Google partagent window.dataLayer, et la couche de données client d'Adobe utilise son propre tableau, window.adobeDataLayer. La documentation d'Adobe décrit le même avantage lié à l'ordre de chargement. Les pages et les scripts peuvent enregistrer des données et déclencher des événements en poussant dans le tableau avant même que le script de la couche de données soit chargé.