7 erreurs de dataLayer qui faussent vos données GA4 (et comment les corriger)

En bref : les erreurs de dataLayer les plus courantes qui faussent GA4 sont : un page_view compté deux fois, un purchase sans montant, un tableau items vide, un événement qui ne se déclenche plus après une mise en prod, une casse incohérente, des valeurs undefined, et un événement qui part avant le consentement. Chacune se repère à un symptôme précis et se corrige.

Vos chiffres GA4 ont l'air propres. Les courbes montent, les rapports se remplissent, tout le monde regarde le dashboard avec confiance. Le problème, c'est que GA4 ne vous dit jamais « attention, cette donnée est fausse ». Il affiche ce qu'on lui envoie, point. Et si le dataLayer envoie de travers, vous pilotez avec des chiffres qui mentent, sans le savoir.

En clientèle, je retrouve toujours les mêmes coupables. Voici les 7 erreurs de dataLayer qui polluent GA4 le plus souvent. Pour chacune : le symptôme dans vos rapports, la cause côté dataLayer, et le correctif. On y va.

Le page_view compté deux fois

Symptôme : un trafic anormalement élevé, un nombre de sessions gonflé, parfois un taux d'engagement étrangement bas. Les chiffres paraissent bons, trop bons.

Cause : le grand classique, ce sont deux conteneurs GTM sur le site (souvent l'héritage d'une migration où l'ancien n'a jamais été retiré), ou une double configuration du tag GA4. Chaque page_view part donc en double.

Correctif : auditez vos conteneurs et n'en gardez qu'un. Dans GTM, vérifiez qu'il n'existe pas deux tags de configuration GA4 qui se déclenchent sur les mêmes pages. Un simple contrôle dans le mode Preview suffit à voir le page_view partir deux fois.

Le purchase qui remonte sans montant

Symptôme : vos conversions sont bien comptées dans GA4, mais le revenu est à zéro ou largement sous-estimé. Le nombre d'achats colle, le chiffre d'affaires non.

Cause : l'événement purchase se déclenche, mais la clé value n'est pas poussée dans le dataLayer, ou elle est mal mappée dans la variable GTM. J'ai vu ce cas après une refonte de tunnel : l'event partait bien, mais sans le montant.

Correctif : vérifiez que le push de purchase contient bien value et currency, avec le bon type (un nombre, pas une chaîne). Contrôlez ensuite le mapping de la variable côté GTM, et confirmez la valeur dans le DebugView de GA4.

Le tableau items qui part vide

Symptôme : vos revenus e-commerce sont mécaniquement sous-estimés, les rapports par produit sont vides ou incomplets, alors que les ventes ont bien lieu.

Cause : après une migration, le tableau items part vide vers GA4. La structure e-commerce n'a pas été correctement repeuplée, souvent parce que les données produit ne sont plus disponibles au moment du push.

Correctif : vérifiez que chaque item contient au minimum item_id, item_name et price. Gardez à l'esprit que items doit être rempli au moment où l'événement se déclenche, pas après. Le DebugView de GA4 montre immédiatement si le tableau arrive vide.

L'événement qui ne se déclenche plus après une MEP

Symptôme : la chute brutale d'un événement précis dans vos rapports. Un view_cart, un sign_up ou un add_to_cart qui, du jour au lendemain, tombe à quasi zéro.

Cause : une mise en production (MEP) a déplacé un bout de code, changé l'id CSS d'un bouton, ou modifié l'ordre des push. Le listener ne trouve plus son déclencheur. Le site marche, mais l'event est muet. Ce genre de régression passe souvent inaperçu pendant des semaines.

Correctif : recettez systématiquement après chaque MEP et comparez le comportement avant/après. Dans GA4, surveillez les variations soudaines de volume par événement : une chute nette est presque toujours un signal de régression, pas de baisse d'activité.

La casse incohérente (camelCase vs snake_case)

Symptôme : des variables GTM vides sans raison apparente, des données présentes sur certaines pages et absentes sur d'autres.

Cause : une page envoie pageType, une autre page_type. Pour GTM, ce sont deux variables différentes. Résultat : la variable ne se valorise que la moitié du temps.

Correctif : choisissez une seule convention de nommage (camelCase ou snake_case) et documentez-la dans le plan de marquage. En cas de doute, la console suffit à repérer les incohérences de casse d'une page à l'autre. Une règle, une seule, et vous vous épargnez des heures de débogage.

Les valeurs undefined ou au mauvais format

Symptôme : la valeur littérale « undefined » qui apparaît dans vos rapports, des dimensions personnalisées cassées, ou des métriques qui refusent de s'agréger correctement.

Cause : une variable poussée avant d'être disponible se retrouve à undefined. Autre cas fréquent : un nombre envoyé sous forme de chaîne de caractères ("29.90" au lieu de 29.90), ce qui casse les calculs côté GA4.

Correctif : prévoyez des valeurs par défaut pour éviter les undefined, et vérifiez le type des valeurs, en particulier les montants, qui doivent être des nombres. À noter que ce contrôle de type est l'un des plus vite oubliés, alors qu'il fausse silencieusement tous vos revenus.

L'événement qui part avant le consentement

Symptôme : des conversions Ads qui disparaissent après un changement de consent mode, ou à l'inverse de la donnée collectée alors que le consentement n'a pas été donné (un vrai risque RGPD).

Cause : un problème d'ordre. Un événement custom se déclenche avant que l'information de consentement soit disponible. La séquence des push n'est pas respectée, et la CMP (la plateforme de gestion du consentement) arrive trop tard.

Correctif : assurez-vous que les événements liés au consentement se déclenchent avant les événements custom. Le mode Preview de GTM permet de visualiser la séquence et de repérer ces race-conditions. Bien fait, consentement et qualité de la donnée ne s'opposent pas : on peut avoir les deux.

Comment attraper ces erreurs avant qu'elles ne coûtent cher

Vous l'avez sans doute remarqué : ces 7 erreurs ont un point commun. Aucune n'affiche d'alerte rouge. Le site fonctionne, les visiteurs achètent, et pendant ce temps la donnée dérive en silence, parfois pendant des semaines, jusqu'à ce qu'une analyse ou un budget média en paie le prix.

La parade classique, c'est la recette manuelle : rejouer les parcours, contrôler chaque event dans le Preview de GTM. Indispensable, mais chronophage, et impossible à refaire intégralement à chaque mise en prod. Entre deux recettes, personne ne regarde.

C'est exactement le vide que MayIA° vient combler : un système qui rejoue les parcours et vérifie chaque événement du dataLayer en continu, avant et après chaque MEP, avec une alerte contextualisée dès qu'une de ces erreurs apparaît. La recette manuelle reste utile pour le cadrage ; l'automatisation, elle, ne dort jamais.

Pour conclure

Si vous ne devez retenir qu'une chose : quand vos chiffres GA4 vous surprennent, ne commencez pas par accuser l'outil. Neuf fois sur dix, le problème est en amont, dans le dataLayer. Un page_view doublé, un items vide, une casse incohérente, et tout un rapport bascule dans le faux.

Le bon réflexe : partir du symptôme, remonter à la cause côté dataLayer, corriger, puis mettre en place de quoi éviter que ça revienne à la prochaine MEP.

Vos données GA4 vous semblent bizarres et vous voulez en avoir le cœur net ? Parlez-en à l'équipe MayIA°, on regarde ça ensemble.

FAQ

Comment savoir si mon dataLayer fausse mes données GA4 ?

Le premier signal est un écart entre GA4 et une source fiable comme votre back-office ou votre outil de paiement. Le DebugView de GA4 et le mode Preview de GTM permettent ensuite de vérifier, événement par événement, si la donnée envoyée est correcte. Une variation soudaine de volume sur un événement est un autre signal classique.

Pourquoi mes conversions GA4 ne correspondent pas à mon back-office ?

Les causes les plus fréquentes sont un purchase qui remonte sans montant, un tableau items vide, ou un événement compté deux fois à cause d'un double conteneur GTM. Un écart persistant est presque toujours un problème de collecte, pas un problème de GA4.

Une erreur de dataLayer peut-elle avoir un impact RGPD ?

Oui. Si un événement se déclenche avant le recueil du consentement, vous risquez de collecter de la donnée sans base légale. À l'inverse, un consent mode mal ordonné peut faire perdre des conversions. L'ordre des push par rapport à la CMP est un point de contrôle technique et réglementaire.

Comment éviter que ces erreurs reviennent à chaque mise en production ?

En recettant le dataLayer avant et après chaque MEP, et en surveillant les volumes par événement dans GA4. Pour les sites qui déploient souvent, une surveillance automatisée du dataLayer attrape les régressions en continu, sans dépendre d'une recette manuelle refaite à chaque fois.