Le dataLayer, ou pourquoi vos conversions ne remontent jamais correctement

J'ai passé plusieurs années à faire du tracking dans une agence marketing. Mon travail, c'était d'intégrer des pages et de m'assurer que ce qui se passait dessus remontait correctement vers Google Ads, Meta, et une poignée d'autres plateformes. Des budgets publicitaires réels, des ventes réelles, et des gens qui prenaient des décisions sur la base de mes chiffres.

Ce qui m'a le plus surpris au début, c'est que le tracking casse rarement dans Google Tag Manager. Il casse presque toujours avant, au moment où le site est censé dire ce qui vient de se passer. Et cet endroit, c'est le dataLayer.

Si vous avez déjà eu un compte Google Ads qui annonce 40 conversions alors que vous avez reçu 12 emails, cet article est pour vous.

---

Le malentendu de départ

Beaucoup de gens imaginent que Google Tag Manager observe leur site. Qu'il voit les clics, comprend qu'une commande a été validée, et transmet l'information. Ce n'est pas du tout ce qui se passe.

GTM est un lecteur. Il attend qu'on lui donne une information, il vérifie si cette information correspond à une de ses règles, et si oui il déclenche une balise. C'est tout. Il ne sait pas ce qu'est un panier, il ne sait pas ce qu'est un client, et il n'a aucune idée du montant d'une commande à moins qu'on le lui dise explicitement.

Le dataLayer, c'est le canal par lequel on le lui dit. Concrètement, c'est un simple tableau JavaScript que votre site remplit au fil de la navigation.

window.dataLayer = window.dataLayer || [];

Cette ligne, vous l'avez déjà sur votre site si GTM est installé. Elle est dans le snippet que Google vous a fait copier. Et à partir de là, chaque fois que quelque chose d'important arrive, le site pousse un message dedans.

window.dataLayer.push({
  event: "form_submit",
  form_name: "contact",
  form_location: "page_tarifs",
});

Voilà. C'est l'intégralité du concept. Un tableau, des objets qu'on y ajoute, et un event qui sert de nom.

---

Ce que ça change par rapport aux déclencheurs automatiques

GTM propose des déclencheurs prêts à l'emploi : clic sur un élément, soumission de formulaire, affichage d'une page. Ils fonctionnent, et pour un site simple ils suffisent souvent. Alors pourquoi s'embêter avec le dataLayer ?

Parce que les déclencheurs automatiques devinent. Le déclencheur de soumission de formulaire, par exemple, écoute l'événement submit du navigateur. Si votre formulaire est en React et envoie les données en arrière-plan sans jamais faire de vrai submit, le déclencheur ne se déclenche jamais. Si votre formulaire affiche une erreur de validation et que l'utilisateur soumet trois fois avant que ça passe, le déclencheur compte trois conversions.

Un push dataLayer, lui, se fait à l'endroit exact du code où vous savez que ça a marché.

const response = await fetch("/api/leads", {
  method: "POST",
  body: JSON.stringify(data),
});

if (response.ok) {
  window.dataLayer.push({
    event: "lead_generated",
    lead_type: "devis",
    lead_value: 200,
  });
}

La différence est fondamentale. Le déclencheur automatique dit « quelqu'un a cliqué sur un bouton qui ressemble à un bouton d'envoi ». Le push dataLayer dit « le serveur a confirmé l'enregistrement du lead ». Ce ne sont pas les mêmes chiffres, et seul le second est utilisable pour décider d'un budget.

---

Le piège du timing

Voici l'erreur que j'ai vue le plus souvent, et celle qui est la plus difficile à diagnostiquer parce qu'elle fonctionne la moitié du temps.

Le snippet GTM est chargé en haut de page. Si vous poussez des données dans le dataLayer après le chargement de GTM, tout va bien, GTM écoute et réagit. Mais si vous poussez des données avant, elles sont bien dans le tableau, et GTM les lira au démarrage. Le problème apparaît quand le push arrive pendant le chargement, ou quand il dépend d'une donnée qui n'est pas encore là.

Le cas classique est la page de confirmation de commande. Le montant de la commande arrive d'un appel serveur, l'appel prend 300 millisecondes, et pendant ce temps le push est parti avec une valeur vide.

// Ce qui arrive vraiment trop souvent
window.dataLayer.push({
  event: "purchase",
  value: order.total,  // order n'est pas encore chargé, value vaut undefined
});

Dans Google Ads, ça se traduit par des conversions enregistrées avec une valeur de zéro. Le nombre de conversions est correct, donc personne ne remarque rien pendant des semaines. Puis quelqu'un se demande pourquoi le retour sur investissement des campagnes est à plat.

La règle que j'applique : le push se fait dans le même bloc de code que la confirmation de l'action, jamais dans un bloc séparé qui s'exécute en parallèle.

---

Pourquoi avoir un plan de marquage écrit

Sur un site avec trois pages, vous pouvez garder le tracking en tête. Dès qu'il y a plusieurs plateformes publicitaires, plusieurs types de conversion et deux personnes qui travaillent dessus, ça ne tient plus.

Le plan de marquage, c'est un document qui liste pour chaque action : le nom de l'événement, les données transmises, le moment exact du déclenchement, et les plateformes destinataires. Rien de sophistiqué, un tableau suffit.

Ce document sert trois fois. La première quand vous implémentez, parce qu'il évite les noms d'événements incohérents du type formSubmit, form_submit et submit_form qui coexistent sur le même site. La deuxième quand quelque chose casse, parce que vous savez exactement ce qui était censé se produire. Et la troisième six mois plus tard, quand vous ou quelqu'un d'autre devez reprendre la configuration.

Cette partie là n'est pas technique, mais c'est celle qui fait la différence entre un tracking qui tient et un tracking qu'il faut refaire chaque année.

---

La vérification, qui n'est pas optionnelle

Un tracking non vérifié est un tracking qui ne marche pas, simplement vous ne le savez pas encore. La vérification se fait en trois passes, et j'ai appris à ne jamais en sauter une.

En prévisualisation. Le mode Preview de GTM montre le contenu du dataLayer à chaque événement. Vous refaites le parcours complet et vous regardez, pour chaque étape, si l'événement part et si les données sont là. C'est fastidieux et c'est là qu'on trouve 80% des problèmes.

Dans la console. Tapez dataLayer dans la console du navigateur. Vous voyez le tableau complet avec l'historique des pushs. Pratique pour vérifier un ordre de déclenchement ou repérer un doublon.

Dans les plateformes, quelques jours plus tard. C'est l'étape que tout le monde oublie. Vous comparez le nombre de conversions dans Google Ads avec vos vrais leads reçus, et le chiffre d'affaires de GA4 avec celui de votre back-office. Un écart de quelques pourcents est normal, notamment à cause du consentement aux cookies. Un écart de 30% signifie qu'il y a un problème quelque part.

---

Et le consentement dans tout ça

Depuis que le Consent Mode existe, le dataLayer joue aussi ce rôle. Le choix du visiteur y est poussé, et GTM décide ensuite ce qu'il déclenche ou non.

window.dataLayer.push({
  event: "consent_update",
  analytics_consent: "granted",
  ad_consent: "denied",
});

Ce qui compte, c'est l'ordre. Le consentement doit arriver avant les événements de mesure, sinon vous vous retrouvez soit à tracker quelqu'un qui a refusé, soit à perdre des données de quelqu'un qui avait accepté. Les deux sont des problèmes, le premier plus que le second.

---

Ce que je retiens de tout ça

Le tracking n'est pas un sujet d'outil. GTM s'apprend en quelques jours, et la plupart des interfaces publicitaires se ressemblent. Ce qui est difficile, c'est de faire le lien entre ce qui se passe dans le code d'un site et ce qu'une équipe marketing a besoin de savoir pour décider.

C'est précisément là que se situe mon travail : comprendre suffisamment le code pour poser le push au bon endroit, et comprendre suffisamment le marketing pour savoir quelle donnée mérite d'y être.

Si vous avez un doute sur votre configuration actuelle, le plus rapide est de commencer par la troisième passe de vérification. Comparez vos conversions annoncées avec vos conversions réelles. Si les chiffres ne collent pas, vous savez maintenant où chercher en premier.