Guide Google Tag Manager : dataLayer et événements GTM

Vous souhaitez comprendre Google Tag Manager et être capable d’en profiter rapidement ?

Vous souhaitez un guide qui vous explique avec des mots simples, de monsieur tout le monde, comment l’utiliser pour améliorer votre marketing ?

Alors vous êtes au bon endroit 🙂

Cet article est le deuxième de la série. Ici nous traiterons de concepts un poil plus compliqué que dans la partie 1 : datalayer et évenements datalayer.

Mais ces concepts sont extrêmement importants également. Ce sera la dernière partie théorique alors faites un effort.

Comme dans toute discipline, sans de bonnes bases, vous n’arriverez pas à masterer la suite.

Les autres chapitres du guide

Vous pouvez vous rendre directement aux autres articles si vous le souhaitez :

Sommaire de ce chapitre

Le concept du datalayer GTM

Tout d’abord qu’est ce que c’est ? Et bien c’est un container. (oui, un de plus 😄).

Comme celui que l’on installe au moment d’installer GTM sauf qu’il n’a pas la même utilité.

Il ressemble à ça :

A quoi il sert ? C’est un « endroit » dans lequel on va pouvoir placer des informations sur nos visiteurs et/ou leurs interactions avec le site.

On pourra ensuite les récupérer dans GTM pour les envoyer à quelqu’un d’autre (Google Ads, Google Analytics, Facebook, etc…)

Exemple concret pour comprendre

Un visiteur remplit un champ de formulaire lié au titre de son job.

On peut récupérer cette information et l’envoyer dans Google Analytics.

Et on pourrait ensuite comparer les performances selon le type de poste des visiteurs qui ont remplit des formulaires. Pratique non ?

En fait, grâce au datalayer, GTM devient un intermédiaire entre vos visiteurs, ce qu’ils font lors de leur visite ET tous les tiers (souvent analytics ou publicitaires) qui ont besoin de ces informations pour vous permettre de mieux cibler et/ou analyser.

Ok, mais concrètement comment ça marche ?

Le datalayer est un objet javascript (version simple : un endroit dans le code de votre site) dans lequel on va stocker et/ou envoyer et/ou récupérer des variables.

Ces variables peuvent être :

  • constantes (vous demandez à votre développeur de les mettre dedans),
  • dynamiques (des informations de la page sont poussées vers ces variables en fonction de ce que font les utilisateurs sur le site).

Exemple concret pour comprendre

Un cas concret de constantes que l’on voudrait mettre dans le datalayer serait par exemple la thématique d’une page.

Exemple cette page parle de GTM. Je pourrai vouloir mettre cette information dans mon datalayer et la donner à Google analytics pour pouvoir analyser la popularité de mon site selon les thématiques.

C’est ce que l’on appelle un regroupement de contenu, on verra ça en détail dans les prochains tutos. 🙂

Un cas concret de variables dynamiques. On peut vouloir récupérer les ids de produit vus par les visiteurs pour les envoyer chez Google et Facebook et faire du remarketing dynamique (montrer aux gens des pubs du dernier produit consulté sur notre site).

Ca aussi, on verra en détail dans les prochains tutos.

Un autre cas concret de variables dynamiques. On peut savoir si un utilisateur est sur mobile et s’en servir comme une condition dans un déclencheur.

S’il l’est ET qu’il clique sur un numéro de téléphone, je déclenche une balise d’évènement Google Analytics.

En résumé

On peut utiliser les variables dynamiques pour :

  • envoyer des données liées à vos visiteurs et leur interactions avec votre site aux plateformes analytics et/ou publicitaire.
  • créer des variables personnalisées (comme on l’a vu dans la 1ère partie du guide) afin de créer des déclencheurs dynamiques basés sur le comportement des utilisateurs (on va y revenir).

Créer un datalayer

Déjà, doit-on le créer ?

Et bien oui et non. 😁

GTM va le créer tout seul par défaut. Toutefois dans ce cas de figure, il n’y aura pas de variables constantes.

Si l’on veut un datalayer avec des variables constantes, on doit le créer soi-même (ou demander à son dev) et mettre les valeurs qu’on veut à l’intérieur.

Ou utiliser un plugin qui les met pour nous (si on a un site de type CMS, on y reviendra dans les tutos WordPress et Prestashop 😉)

FAQ sur le datalayer

Question : Imaginons qu’on veuille créer un datalayer nous-même pour y mettre des constantes. On le placerait où ?

Réponse : juste avant le container GTM. C’est à dire entre la balise ouvrante <head> et votre code de container GTM.

Question : Pourquoi ?

Réponse : Et bien s’il n’est pas placé avant, les variables qui sont à l’intérieur ne seront pas disponibles au chargement de la page.

Ce qui est problématique si par exemple vous souhaitez utilisez l’une d’elle dans un filtre de condition au chargement de la page.

Exemple : pour un déclencheur de type page vue sur toutes les pages de la thématique GTM. (vous comprendrez encore mieux avoir lu la partie suivante : évènements datalayer 😉)

Question : Est-on obligé d’utiliser le datalayer ?

Réponse : En théorie non. Si vos balises n’ont pas à être déclenchées par des interactions autres qu’un chargement de la page et/ou si les données dont vous avez besoin sont disponibles au moment du chargement de la page directement à partir de variables JavaScript ou du DOM. (En résumé utilisateur de niveau 1 😃)

Par contre, si vous voulez remonter des informations à GTM et/ou que vos balises puissent être déclenchées uniquement par des interactions sur la page, il vous faudra utiliser le datalayer. (utilisateur de niveau 2 🙌)

Evidemment, je recommande fortement l’utilisation du datalayer.

Ok, résumons tout ça :

  • Le datalayer c’est un container que l’on place avant le container GTM principal.
  • Il sert de tampon entre le DOM et GTM.
  • Il permet de réduire le risque que nos données à récupérer soient impactées par un changement du DOM (mise à jour automatique par exemple),
  • de placer des informations spécifiques au contenu d’une page,
  • de déclencher des balises en fonction d’événements réalisés pendant la navigation des utilisateurs et récupérer toutes sortes d’informations pouvant être utilisées elles-mêmes dans un déclencheur.

Le concept d’événements datalayer dans GTM

Un autre concept important 😁(mais après celui-ci, terminé les concepts).

Déjà, je souhaiterais revenir sur l’un des points de la FAQ ci-dessus. Est on obligé d’utiliser le datalayer ?

En fait, il y a plusieurs moyens d’utiliser le datalayer, comme expliqué ci-dessus (constantes, variables dynamiques, rappelez-vous 😁)

Mais il y en a un dont nous n’avons pas encore parlé. Et celui-ci, vous l’utilisez obligatoirement, malgré vous.

Ce sont les événements datalayer (à ne pas confondre avec les évènements Google Analytics, ce ne sont pas les mêmes 😅).

Comme pour les variables (cf partie 1), il existe des événements datalayer standards, natifs.

Et l’on peut aussi créer des événements datalayer personnalisés.

Commençons par les événements standards.

Les événements datalayer natifs

Lorsque vous installez GTM et avant que vous n’ayez ajouté les différentes variables dont vous avez besoin, il y a nativement 3 événements datalayer :

  • la page vue (aussi appelé gtm.js ou Page view)
  • le DOM prêt (aussi appelé gtm.dom ou DOM ready)
  • la fenêtre chargée (aussi appelé gtm.start ou Window Ready)

Vous les trouvez dans la liste des déclencheurs :

Aller, tapons fort une bonne fois.

  • Un évènement datalayer constitue un changement d’état du datalayer.
  • Une balise ne peut être déclenchée que lors d’un changement d’état du datalayer.
  • L’activation des variables GTM de type clic, formulaire, visibilité, etc… débloquent de nouveaux evénements datalayer
  • A chaque changement d’état du datalayer, toutes les conditions des déclencheurs du container sont analysées pour déterminer si une balise doit être déclenchée.

Très bien. Respirons un bon coup et expliquons chaque point en détail 😃

Un évènement datalayer constitue un changement d’état du datalayer.

Redonnons un poil de contexte un peu technique.

Une page web affichée dans un navigateur est un fichier de code que le navigateur lit de haut en bas et « interprête ».

GTM.js

Au moment ou le navigateur lit le code du container GTM (placé sous la balise <head>, pour rappel), le datalayer est initialisé et un premier évenement datalayer est déclenché : gtm.js

Le datalayer prend donc son « premier état » sur lequel vous pouvez déclencher des balises.

C’est sur cet évènement que vous déclencherez la plupart des balises qui se mettent sur toutes les pages et ne sont pas liées à des interactions sur une page (exemple : pixel facebook, code de suivi analytics, balise de remarketing Google Ads, etc…).

GTM.dom

Le navigateur continue de parcourir le fichier de code et lorsqu’il l’a parcouru en entier il modélise la page qu’il va vous afficher (je simplifie volontairement).

On dit que le DOM est prêt. Pour autant, ça ne veut pas dire que la page est affichée, le navigateur peut encore être en train de charger les scripts, images, fichiers de style, etc…

A ce moment ou le DOM est chargé, un nouvel évènement datalayer est déclenché : gtm.dom.

Le datalayer passe donc dans un second état et vous avez un deuxième point d’accroche pour déclencher des balises (DOM prêt dans la liste des déclencheurs).

Celui-ci est utile pour plusieurs raisons :

  • déclencher des balises ayant des conditions qui dépendent du DOM
  • déclencher des balises nécessitant qu’une autre balise ait été exécuté avant elle (exemple : un évènement de pixel Facebook ne peut pas fonctionner si le pixel de base n’a pas été exécuté avant).
  • étaler le chargement des scripts (idéal pour les scripts secondaires). La on optimise le temps de chargement.

En général, gtm.dom intervient en moyenne entre 1 et 4 secondes après gtm.js selon la taille de la page.

GTM.start

Cette fois le navigateur a complètement affiché la page et chargé toutes les ressources qui lui sont attaché.

Un troisième évènement datalayer et déclenché : gtm.start.

Le datalayer passe donc dans un troisème état et vous avez un troisième point d’accroche pour déclencher des balises (Fenêtre chargée dans la liste des déclencheurs).

En général, gtm.start intervient en moyenne entre 1 et 5 secondes après gtm.dom selon le nombre de scripts, d’images, de styles de la page.

Cela signifie qu’entre le moment où la page commence à charger et l’évenement gtm.start, il peut facilement se passer 10 secondes.

Attention donc de ne pas déclencher des balises vitales sur cet évènement. Vous pourriez louper pas mal de monde.

Apparté sur l’outil de prévisualisation

L’outil de prévisualisation est un outil natif de GTM qui vous permet de voir dynamique en temps réel les tags déployés ou non sur votre site.

Il s’agit d’une fenêtre en surimpression qui vous permet de debugger et de voir si les balises que vous avez paramétré se déclenchent comme prévu lorsque vous interagissez avec votre site.

Il vous permet aussi de voir tous les changements d’état du datalayer :

Ce qui vous permet de vérifier les balises déclenchées (Tafs fired on this event) à chacun des états du datalayer.

Mais aussi celles non déclenchées (Tags not fired on this event).

Exemple ici sur l’état DOM Ready :

Savoir se servir de la console de débug est primordial et ce que je vous ai expliqué la n’est que toucher la surface de ce qu’il faut savoir. Ca mériterait un chapitre de guide à lui tout seul.

En attendant que je le fasse, voici 2 excellentes ressources :

Une balise ne peut être déclenchée que lors d’un changement d’état du datalayer

Effectivement, comme dit plus haut, seul un changement d’état du datalayer (autrement appelé un évènement datalayer) peut déclencher une balise.

Il n’y a pas d’intermédiaire.

L’activation des variables GTM de type clic, formulaire, visibilité, etc… débloquent de nouveaux evénements datalayer

En activant les variables natives supplémentaires dont vous avez besoin telles que les clics, les formulaires, etc… cela active de nouveau évènements datalayer.

Ou pour être plus précis, cela les rend disponible. Mais pour qu’ils soient actifs, vous devez créer un déclencheur utilisant l’une des variables de clic.

Admettons que vous créiez un déclencheur qui déclenche lorsqu’un visiteur clic sur un email cliquable (c’est à dire un lien qui contient mailto:).

On le paramètrerait ainsi :

A partir du moment ou ce déclencheur est enregistré, chaque clic sur un lien entrainera un changement d’état du datalayer (ici gtm.linkClick)

Ce changement d’état deviendra donc un point de déclenchement possible pour vos balises.

Et il en va de même pour tous les autres types d’événements datalayer : formulaires, vidéos, visibilité d’éléments, scroll, etc…

La liste complète des évènements datalayer natif est disponible ici.

A chaque changement d’état du datalayer, toutes les conditions des déclencheurs du container sont analysées pour déterminer si une balise doit être déclenchée.

C’est ainsi que fonctionne GTM.

Tout évènement datalayer déclenche en interne une évaluation de toutes les conditions présentes dans tous les déclencheurs.

Si l’une des conditions est vraie, alors le déclencheur s’active et… déclenche la ou les balises qui lui sont rattachées.

Les événements datalayer personnalisés

Nous l’avons vu, il existe de nombreux événements datalayer natifs. Et GTM ne nous limite pas à uniquement ceux-ci.

Nous pouvons créer des événements datalayer personnalisés :

Pour ce faire, vous aurez besoin de l’aide d’un développeur. Ou savoir modifier un peu le code de votre site web.

A quoi servent-ils ?

  1. à compenser certaines limitations que peuvent avoir les déclencheurs natifs.

Il peut arriver par exemple que certains formulaires ne soient pas traquables (s’ils ne submit pas pour les plus avancés d’entre vous).

Il peut également y avoir un problème de propagation dans votre javascript, empêchant les détecteurs de GTM d’entendre les clics par exemples.

Pour ceux qui souhaitent creuser ce sujet, rendez-vous chez Simo.

2. à ajouter du contexte à une action réalisée sur votre site

Nous allons le voir juste après, la manière dont nous créons un évènement datalayer personnalisé nous permet d’ajouter du contexte à l’évènement (comprendre des informations envoyées dans le datalayer).

Notamment des informations que ce qui est natif dans GTM nous nous permettrait pas d’avoir.

Créer un évènement datalayer personnalisé

On va employer la méthode datalayer.push();

Ok j’explique. 😁

datalayer.push(); est une méthode javascript. C’est-à-dire une action que l’on peut faire exécuter à un objet javascript.

Le datalayer est un object javascript. Et donc je vais pousser des éléments à l’intérieur.

Je vais pousser quoi ? D’abord un évènement. Et comme il est personnalisé, je devrais définir son nom.

Exemple :  window.dataLayer || [] window.dataLayer.push({‘event’: ‘event_name’});

Maintenant, on ne peut pas faire ça n’importe quand. On doit le faire sur un évènement javascript. C’est à dire sur un clic, au moment ou un formulaire est envoyé, etc… La liste des possibles est énorme.

Par exemple, imaginons un lien pour télécharger ce guide en version pdf, on aurait la syntaxe suivante :

<a href= »https://www.bruno-guyot.com/guide-GTM-datalayer.pdf » name= »GuideGtmDataLayerPdf » onclick= »window.dataLayer || [] window.dataLayer.push({‘event’: ‘pdf-download’}); » >Guide GTM Datalayer en Pdf</a>

Ce qui aurait pour résultat de créer un nouvel état dans mon datalayer :

Mais question à 1 million 🤔

Comment je déclenche un balise la dessus ?

Et bien en fait, vous devez créer cet évènement personnalisé dans GTM (lui apprendre à le reconnaitre en fait) pour ensuite pouvoir vous en servir comme déclencheur.

On crée donc un nouveau déclencheur de type évènement personnalisé :

Et on définit que la condition c’est de déclencher sur tous les évènements qui s’appellent pdf-download :

Restera ensuite simplement à accrocher ce déclencheur à une balise (au hasard une balise d’évènement Google analytics ou une balise de suivi des conversions Google Ads).

Ajouter du contexte aux évènements datalayer personnalisés

Comme dit précédemment, on peut aussi remonter informations contextuelles (par le biais de variables).

Syntaxe générique :window.dataLayer || [] window.dataLayer.push({‘variable_name’: ‘variable_value’, ‘event’: ‘event_name’ });

Exemple : window.dataLayer || [] window.dataLayer.push({‘color’: ‘red’,’event’: ‘addToCart’});

On peut également faire du multipush. C’est à dire un évènement de plusieurs variables. Vous trouverez plusieurs exemples ici.

C’est notamment la technique utilisée pour envoyer des informations de ecommerce à Google Analytics :

Mais, nouvelle question à 1 million 😄

Comment je récupère mes variables et leur valeur dans GTM ?

Créer des variables personnalisée de couche de données

Et bien, on crée de nouvelles variables. Je vous en parlais rapidement dans le chapitre précédent.

L’une des raisons les plus communes pour lesquelles nous créons des variables personnalisées, c’est pour récupérer des informations envoyées dans le datalayer lors de push.

Pour faire ça, on va dans Variables >Variables définies par l’utilisateur > Nouvelle

De là vous choisissez le type variable de couche de données.

Il s’agit ensuite de lui donner le nom de la variable envoyée dans le datalayer.

Reprenons mon exemple plus haut : window.dataLayer || [] window.dataLayer.push({‘color’: ‘red’,’event’: ‘addToCart’}); on créera donc une variable color. Et elle aura pour valeur « red » lorsque le datalayer sera à l’état « addToCart ».

Vous pourrez ensuite passer ces informations additionnelles à Google Analytics sous forme de dimension personnalisée et ainsi pouvoir comparer par exemple la performance de vos produits par couleur.

Ou vous pourrez également utiliser cette variable dans vos conditions de déclenchement.

Par contre, j’attire votre attention sur le fait que tant que l’évènement datalayer addToCart n’est pas arrivé, la valeur de cette variable est nulle (undefined pour être précis).

Le datalayer, des règles à respecter

Le datalayer c’est règlementé. Vous devez faire attention à respecter ces règles sinon ça ne marche pas.

Le nom d’objet datalayer est sensible à la casse. dataLayer est différent de datalayer.

Le nom des variables doit être entre apostrophe : dataLayer.push({variable_name: ‘variable_value’});

dataLayer.push({variable_name: ‘variable_value’}); ça ne marche pas.

Le nom des variables doit être le même sur toute les pages ou le datalayer est appliqué. Par exemple : dataLayer.push({‘pageview’: ‘/’});

Sur toutes les autres pages ça doit être pareil : dataLayer.push({‘pageview’: ‘merci.php’});. Et par exemple dataLayer.push({‘Pageview’: ‘ merci.php’}); ne marcherait pas.

Plus d’informations détaillées sur la page d’aide aux développeurs de Google : https://developers.google.com/tag-manager/devguide#thepits

Résumé de cette deuxième partie

  • On sait mettre en place le datalayer (où et comment).
  • On sait y mettre des variables de départ liées au contenu de la page.
  • On sait utiliser les évènements de datalayer natifs
  • On sait également pousser des nouvelles informations à l’intérieur, que ce soit des variables ou des événements personnalisés.
  • Enfin on sait aussi qu’il faut faire attention à pas mal de détails qui peuvent générer des erreurs.

La troisième partie du guide est ici : GTM et WordPress. A partir de maintenant on beaucoup moins théoriser et rendre ça beaucoup plus concret, pratique et actionnable. 🙌

En attendant, si vous avez des questions/remarques/recommandations d’amélioration sur cette première partie, n’hésitez pas à laisser vos commentaires 🙂

Auteur : Bruno Guyot

Expert en marketing digital & Générateur de business par des campagnes data-driven. J'aide les agences et les entreprises à accroitre leur business par la mise en place de mécanismes de tracking évolués. La récolte des données va nourrir une stratégie digitale et des campagnes à haute performance. Parmi les leviers technologiques utilisés : Analytics, Tag Management, Adwords, Facebook, LinkedIn, Twitter.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *