DataLayer GTM : guide complet et exemples par CMS

Qu’est-ce qu’un dataLayer GTM ?

Le dataLayer est un tableau JavaScript, window.dataLayer, où le site ajoute des objets avec dataLayer.push(). GTM lit ce tableau et déclenche les balises GA4 ou publicitaires. Il remplace le scraping du DOM par un contrat documenté. Pour la définition courte, voir le glossaire du data layer et la FAQ data layer et GTM.

Pourquoi un dataLayer plutôt que du scraping DOM

Lire le prix ou le nom d’un produit dans une balise HTML paraît suffisant jusqu’à la première refonte de thème. Le sélecteur change, la balise disparaît, et les données GA4 s’arrêtent sans alerte. Si votre dataLayer existe déjà et que les chiffres ne collent pas, un audit de tracking fait l’état des lieux avant toute correction. Sur Shopify, où le checkout échappe au dataLayer classique, la mise en place suit une autre logique, décrite dans la page tracking Shopify avec GA4, Pixels et sGTM.

Un dataLayer découple les deux mondes. Le développeur pousse les données métier au moment où elles existent côté serveur. L’équipe analytics définit les balises à partir de ce contrat. Si le design change, le contrat reste, et la mesure aussi.

Anatomie d’un push

Il existe deux types d’objets, à ne pas confondre.

• Les variables : données de contexte, poussées sans event. Exemple : { page_type: 'product', logged_in: false }.
• Les événements : une clé event qui déclenche une balise. Exemple : { event: 'add_to_cart', ... }.

Trois règles de fonctionnement :

1. L’initialisation vient en premier. Déclarez window.dataLayer = window.dataLayer || []; au-dessus du snippet GTM. Google recommande aussi de ne jamais réassigner le tableau après le chargement du conteneur.
2. La portée est celle de la page. Sur un site classique, une variable poussée sur une page ne survit pas à la navigation. Il faut la repousser sur chaque page avec un nom constant.
3. Une écriture écrase l’ancienne. Pousser une variable qui existe déjà remplace sa valeur. C’est utile pour une mise à jour, dangereux si la clé est partagée entre deux contextes.

Les clés d’objet doivent être entre guillemets dans le JSON, et le nom du tableau est sensible à la casse.

Conventions de nommage et plan de marquage

Je travaille avec un plan de marquage partagé : un tableur qui liste chaque événement, chaque variable, son type, la page qui la déclenche et la balise qui la consomme. Ce document évite les dérives, du type addToCart, add_to_cart et AddToCart coexistant dans le même site.

Les conventions que j’applique :

• Événements et paramètres en snake_case, alignés sur les noms recommandés par GA4 (view_item, add_to_cart, purchase, generate_lead) quand ils existent. Cela évite de réinventer un événement déjà géré par GA4.
• Pas de préfixe réservé. GA4 interdit les noms d’événements qui commencent par google_, ga_ ou firebase_.
• Types stables. value et price sont des nombres, pas des chaînes. currency est un code ISO à trois lettres en majuscules, EUR.
• Un identifiant par objet. item_id correspond au SKU ou à l’identifiant du flux produit Google Merchant Center, pour que le remarketing dynamique reste aligné.

Le modèle e-commerce GA4 dans le dataLayer

La référence e-commerce de GA4 définit le format. Pour un achat, transaction_id est obligatoire, value est la somme de price * quantity, et currency s’indique au niveau de l’événement dès qu’une valeur est envoyée. Chaque article du tableau items a au moins un item_id ou un item_name, et je recommande les deux.

Voici un purchase complet :

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'T-20261102-0042',
    value: 109.8,
    tax: 18.3,
    shipping: 4.9,
    currency: 'EUR',
    coupon: 'AUTOMNE10',
    items: [
      {
        item_id: 'SKU-123',
        item_name: 'Veste imperméable',
        item_brand: 'Maison Exemple',
        item_category: 'Vestes',
        price: 49.9,
        quantity: 2,
        discount: 5.0
      }
    ]
  }
});

Le ecommerce: null qui précède l’événement vide le bloc précédent. Il évite qu’un ancien panier se mélange au nouvel achat. Ce réflexe est courant dans les implémentations GTM, même si la documentation GA4 ne le décrit pas explicitement : je le valide donc en mode Preview avant de l’imposer à une équipe.

Pour les liens entre ce format et les données de vente, le tracking e-commerce avec GA4 reprend la logique du funnel. Le transaction_id a une fonction précise : il sert à dédupliquer. Si la page de confirmation se recharge, un achat déjà envoyé ne doit pas se compter une seconde fois. Un identifiant unique généré par la commande, pas par la page, règle ce cas.

Le dataLayer pour la génération de leads

Le lead gen n’a pas de panier, mais il a un moment clé : la soumission du formulaire. Je pousse un événement generate_lead au succès de la requête, pas au clic sur le bouton, car un clic n’indique pas qu’un lead existe réellement.

window.dataLayer.push({
  event: 'generate_lead',
  lead_source: 'formulaire_contact',
  value: 1,
  currency: 'EUR',
  user_data: {
    email_sha256: '...hash calculé côté serveur ou dans GTM...'
  }
});

Le bloc user_data sert aux Enhanced Conversions de Google Ads. Google attend des données utilisateur hachées (SHA-256) avant envoi. Le hachage se fait côté serveur ou dans une variable GTM dédiée, jamais en clair dans le dataLayer. Un email en clair dans le tableau est lisible par tous les scripts de la page : c’est une fuite de données, pas une optimisation.

Le suivi de formulaire demande aussi de vérifier que l’événement part après le succès et pas avant la validation côté serveur. Un formulaire qui affiche une erreur ne doit pas produire de lead.

Exemples par CMS

Le point d’injection dépend du CMS, mais la logique reste la même : un bloc qui lit les données du serveur et les pousse avant GTM. Voici comment je l’aborde sur les plateformes les plus fréquentes.

PrestaShop : le dataLayer se branche sur les templates du thème et les hooks d’affichage. Le guide PrestaShop détaille les pages à couvrir.

WordPress : le contexte de page se pousse depuis le thème ou une extension dédiée. Pour une boutique, passez par le guide WordPress avant de choisir.

WooCommerce : les événements de panier et de commande se déclenchent côté serveur, puis se lisent dans le dataLayer. Le guide WooCommerce couvre les pièges de la page de remerciement.

Shopify : le thème et l’éditeur de checkout limitent les injections. Le guide Shopify explique ce qui se branche et ce qui ne se branche pas.

Magento : le dataLayer s’alimente depuis les blocs et les observateurs d’événements. Le guide Magento précise les points d’extension.

Webflow : les sites sans logique e-commerce poussent surtout des variables de page et des événements de formulaire. Le guide Webflow traite ces cas.

HubSpot : le suivi passe souvent par ses propres outils de formulaire. Le guide HubSpot détaille l’articulation avec GTM.

Drupal : les données de contenu se transmettent via les templates Twig et les services du module. Le guide Drupal couvre ces points.

Applications JavaScript : en SPA, le dataLayer se pousse depuis le routeur et les composants. Le guide SPA et headless détaille les vues virtuelles.

Le hub des plateformes rassemble les autres cas, et les pages de l’audit tracking évaluent un dataLayer existant avant de le corriger.

Erreurs fréquentes

Push après le tag. Le dataLayer est lu au chargement du conteneur. Un événement poussé après le déclenchement de la balise n’existe pas pour elle. Initialisez le tableau et poussez les variables de page avant le snippet GTM, puis les événements au moment où ils surviennent.

Types string à la place de number. "49.90" n’est pas 49.9 pour un calcul de valeur. Les totaux GA4 et les règles de valeur de conversion se trompent sans signaler d’erreur.

Devise manquante. Un value sans currency produit des revenus mal convertis ou ignorés selon la configuration. Poussez toujours les deux.

Doublons. Un événement poussé à chaque rendu d’un composant, ou sur une page de confirmation rechargée, se compte plusieurs fois. Le transaction_id et un garde-fou côté code (un drapeau par achat) règlent ce problème.

Données personnelles. Email, téléphone, nom en clair : à proscrire dans le dataLayer. Hachez ce qui doit l’être, et ne poussez que ce qui sert à la mesure.

Événements sans contrat. Un développeur qui renomme add_to_cart en addToCart casse la balise sans prévenir. Le plan de marquage et un test automatisé préviennent cette régression.

Outils de contrôle

Je vérifie chaque dataLayer avec quatre outils, dans cet ordre.

1. Le mode Preview de GTM : il montre chaque push, son contenu et les balises déclenchées.
2. GA4 DebugView : il confirme que les paramètres arrivent dans GA4, avec les bons types.
3. Tag Assistant : il contrôle l’ordre de chargement, le consentement et les balises en erreur.
4. Une extension de type dataLayer checker : elle affiche le contenu du tableau à tout moment, pratique pour les tests manuels.

Pour une recette répétable, j’ajoute des tests automatisés. Un script Playwright ou Cypress ouvre la fiche produit, ajoute au panier, puis lit window.dataLayer pour vérifier la présence et le format de add_to_cart. Ce test attrape les régressions avant la mise en production, sans attendre un rapport d’écart dans GA4.

FAQ

Faut-il un dataLayer si GA4 est déjà installé ?

Oui, dès que vous voulez mesurer des événements métier (achat, lead, inscription). Le connecteur natif de votre CMS couvre souvent les pages vues et rarement tout le tunnel. Le dataLayer est la seule façon d’avoir une source propre et documentée.

Peut-on se passer de GTM avec un dataLayer ?

Le dataLayer est un tableau JavaScript, il existe sans GTM. Mais sans conteneur pour le lire, il faut écrire et maintenir soi-même chaque balise. GTM reste le moyen le plus économe de le consommer, surtout pour plusieurs plateformes publicitaires.

Le dataLayer est-il visible par l’utilisateur ?

Oui. Tout script de la page peut le lire, et la console du navigateur l’affiche. C’est une raison de ne jamais y mettre de donnée sensible, et de pousser uniquement ce qui sert à la mesure.

Comment savoir si mon dataLayer est correct ?

Par la recette : Preview GTM pour le déclenchement, DebugView pour les paramètres dans GA4, puis un test automatisé sur le parcours d’achat. Un dataLayer correct est un dataLayer dont chaque événement passe ces trois contrôles.

Le dataLayer découle d’un document amont : le plan de taggage GA4, méthode et modèle à copier.

Sources

• Présentation du dataLayer GTM, Google for Developers
• Référence e-commerce GA4, Google for Developers