Comment vérifier que votre tracking GA4 fonctionne vraiment ?
- Publié le
- 9 min de lecture
En bref : « est-ce que GA4 fonctionne ? » recouvre trois questions distinctes : le tag part-il, la donnée arrive-t-elle, et la donnée est-elle juste ? Les outils de debug répondent à la première en deux minutes et à la deuxième en dix. Presque personne ne pose la troisième, et c'est la seule qui garantit que vos rapports ne racontent pas d'histoires. Un tag vert n'a jamais prouvé une donnée juste.
Le tag est vert dans Tag Assistant. Le rapport temps réel affiche du trafic. Le conteneur GTM est publié. Tout indique que le tracking fonctionne.
Et pourtant le chiffre d'affaires remonté par GA4 est 17 % en dessous de celui du back-office.
Les deux constats sont vrais en même temps. Le tag part bien, et la donnée est fausse. C'est exactement la situation que les vérifications habituelles ne détectent pas, parce qu'elles s'arrêtent une marche trop tôt : elles contrôlent le transport, pas le contenu.
Cet article prend les trois niveaux dans l'ordre. Ce que chacun prouve, ce qu'il ne prouve pas, et le moment où il faut passer au suivant.
Les trois questions que « est-ce que ça marche ? » recouvre
Quand quelqu'un demande si le tracking fonctionne, il pose en réalité trois questions empilées, de difficulté croissante :
- Le tag se déclenche-t-il ? Est-ce que la requête part du navigateur.
- La donnée arrive-t-elle dans GA4 ? Est-ce que Google la reçoit, l'accepte et la traite.
- La donnée est-elle juste ? Est-ce que ce qui est arrivé décrit la réalité de ce qui s'est passé sur le site.
Chaque niveau se vérifie avec des outils différents, et surtout : un niveau validé ne dit rien du niveau suivant. Un tag qui part peut envoyer un purchase sans montant. Une donnée bien reçue par GA4 peut être comptée deux fois. C'est pour cela que « le tag est vert » est une réponse à la question la plus facile des trois, présentée comme une réponse aux trois.
La ligne à retenir : les trois niveaux sont hiérarchiques dans la vérification, pas dans l'importance. Le troisième est celui qui compte pour la décision business, et c'est celui qu'on saute.
Niveau 1 — vérifier que le tag part
Quatre méthodes, de la plus rapide à la plus fiable :
- Le mode Aperçu de GTM. Vous naviguez sur le site avec la fenêtre Tag Assistant ouverte, et vous voyez tag par tag ce qui s'est déclenché, sur quel événement, et pourquoi. C'est le point de départ quand GA4 est posé via GTM.
- L'onglet Réseau du navigateur. Filtrez sur
collect?. Chaque requête vers/g/collectest un hit GA4 qui part. Ses paramètres sont lisibles dans l'URL :enporte le nom de l'événement,tidl'identifiant de flux. - L'extension Google Analytics Debugger. Utile quand GA4 est implémenté en
gtag.jsdirectement, sans GTM. - La console.
dataLayertapé dans la console renvoie l'historique des pushes de la page en cours. C'est le préalable à tout le reste : si l'information n'est pas dans ledataLayer, aucun tag ne pourra l'envoyer. Si ce mot ne vous dit rien, commencez par cet article.
Ce que ce niveau prouve : la mécanique de déclenchement est branchée.
Ce qu'il ne prouve pas : absolument rien sur la justesse. Tag Assistant confirme qu'un tag s'est déclenché, pas que GA4 a accepté et correctement traité ce qu'il contenait. Le voyant vert est un test de tuyauterie.
Niveau 2 — vérifier que GA4 reçoit la donnée
Le tag part : reste à savoir ce que Google en fait.
- DebugView est l'outil de référence. Il montre le flux d'événements de votre session en direct, événement par événement, avec tous les paramètres reçus. Il faut activer le mode debug pour y apparaître : le mode Aperçu de GTM l'active automatiquement, sinon l'extension Google Analytics Debugger ou un paramètre
debug_modesur la configuration font le travail. - Le rapport Temps réel confirme que du trafic non-debug arrive, donc que ça fonctionne aussi pour les vrais utilisateurs et pas seulement pour vous.
- Les rapports standards ne se remplissent qu'après 24 à 48 heures pour les propriétés hors GA4 360. Ne concluez jamais à une panne parce qu'un rapport standard est vide le jour de la mise en production.
Dans DebugView, la vérification utile n'est pas « l'événement apparaît ». C'est ouvrir l'événement et lire ses paramètres : value est-elle renseignée, items contient-il des produits, currency est-elle là. Un purchase qui apparaît dans DebugView avec value vide est un purchase qui casse votre chiffre d'affaires, et il est parfaitement vert.
Ce que ce niveau prouve : GA4 reçoit et traite les événements.
Ce qu'il ne prouve pas : que ça marche pour tout le monde. DebugView ne montre que votre session, dans votre navigateur, avec votre consentement accordé et vos extensions. C'est un échantillon de un. Vérifier que la donnée arrive réellement dans les outils, pour GA4 comme pour Meta ou Segment, est un exercice distinct.
Niveau 3 — vérifier que la donnée est juste (le niveau qu'on saute)
C'est ici que se joue la question qui vous intéresse vraiment, et elle ne se règle avec aucun outil de debug. Elle se règle en confrontant votre collecte à une vérité extérieure.
- Rapprochez GA4 de votre back-office. Le nombre de transactions et le chiffre d'affaires d'une journée écoulée, GA4 contre back-office. Un écart de 8 à 10 % est normal (consentement, bloqueurs, fenêtres d'attribution). Un écart de 20 % est un incident.
- Mesurez les taux de remplissage. Pas «
add_to_cartexiste », mais «add_to_cartportevaluedans 98 % des cas ». Un paramètre rempli à 60 % est un paramètre cassé sur un parcours entier. - Comparez les volumes à eux-mêmes dans le temps. Une chute nette de volume sur un événement, à trafic constant, est presque toujours une régression, pas une baisse d'activité.
- Vérifiez sur plusieurs environnements. Un autre navigateur, un vrai mobile, une session avec consentement refusé. C'est là qu'apparaissent les pannes partielles.
Le rapprochement au back-office est la vérification la plus importante de tout l'article, et la plus souvent absente. C'est la seule qui compare votre mesure à autre chose qu'elle-même. Sans elle, vous vérifiez la cohérence interne d'un système qui peut être cohéremment faux.
La ligne à retenir : un tag vert prouve que quelque chose part. Seul un rapprochement externe prouve que ce quelque chose est vrai.
Le tableau de contrôle
| Niveau | Vérification | Outil | Signal que c'est cassé |
|---|---|---|---|
| 1 | Le tag se déclenche | Mode Aperçu GTM, onglet Réseau | Aucune requête /g/collect sur l'action |
| 1 | L'information existe en amont | dataLayer en console | Variable absente ou vide au moment du push |
| 2 | GA4 reçoit l'événement | DebugView | L'événement n'apparaît pas en mode debug |
| 2 | Les paramètres sont renseignés | DebugView, détail de l'événement | value, items ou currency vides |
| 2 | Le trafic réel arrive | Rapport Temps réel | Trafic debug présent, trafic réel absent |
| 3 | Les montants sont justes | GA4 contre back-office, sur une journée close | Écart > 20 % sur le CA ou les transactions |
| 3 | La couverture est complète | Taux de remplissage par paramètre | Un paramètre clé sous 95 % |
| 3 | Rien n'est compté deux fois | Volumes par événement contre sessions | Volumes brutalement doublés |
| 3 | Le consentement n'écrase pas tout | Session avec refus explicite | Événements envoyés malgré le refus |
Les trois dernières lignes sont celles qu'aucun outil de debug ne remontera, et celles qui coûtent le plus cher.
Les cas où tout paraît fonctionner et où rien ne va
Les pannes silencieuses sont la spécialité de ce domaine, parce qu'elles ne produisent aucune erreur : elles produisent des chiffres plausibles.
- Deux conteneurs GTM actifs. Chaque événement est compté deux fois. Le trafic paraît excellent, et c'est l'une des erreurs les plus fréquentes.
- Les tags partent avant le consentement. Les données arrivent, mais dans une situation juridiquement intenable — et souvent avec un modèle de consentement qui les fera disparaître des rapports plus tard.
- La casse des noms a changé.
add_to_cartdevenuaddToCartaprès une refonte : l'événement part, GA4 le reçoit, et il n'alimente plus aucun rapport existant. - Le paramètre est là mais mal typé. Un
valueenvoyé comme chaîne"49,90"au lieu du nombre49.90. Le hit passe, l'agrégation se casse. - La panne ne touche qu'un segment. Un seul navigateur, le seul tunnel mobile, les utilisateurs connectés. Le volume global bouge peu, donc personne ne le voit.
- Le filtrage interne mange le trafic de test. Vous vérifiez depuis une IP exclue et concluez à une panne inexistante.
Le point commun : aucun de ces cas ne se voit sans un référentiel qui dit ce qui devrait être envoyé. Ce référentiel, c'est le plan de marquage. Sans lui, vous ne vérifiez pas votre tracking, vous le contemplez.
Pourquoi cette vérification ne tient pas dans le temps
Tout ce qui précède décrit un contrôle ponctuel. Fait sérieusement, sur les trois niveaux, il prend une demi-journée sur un site e-commerce de taille moyenne. Le problème n'est pas de le faire une fois, c'est qu'il est valide jusqu'à la prochaine mise en production, c'est-à-dire souvent quelques jours.
Et l'écart entre le moment où la collecte casse et le moment où quelqu'un s'en aperçoit est mesurable. Nos propres relevés donnent une moyenne de deux semaines, sauf quand la régression touche directement le chiffre d'affaires — parce que là, quelqu'un regarde tous les jours. Tout le reste (engagement, étapes de tunnel, événements qui alimentent l'attribution) n'a pas de vigie quotidienne et dérive sans bruit.
C'est ce que MayIA° automatise. Des agents LLM rejouent vos parcours comme un utilisateur, comparent chaque événement observé à ce que votre plan de marquage annonce, et signalent l'écart à chaque déploiement plutôt qu'au moment où quelqu'un s'étonne d'un chiffre. Le niveau 3, celui que personne n'a le temps de refaire manuellement à chaque MEP, devient un contrôle systématique. Si vous voulez la méthode manuelle complète avant d'automatiser quoi que ce soit, elle est détaillée dans recetter un dataLayer ; et si vous comparez les approches du marché, nous avons documenté les outils de QA dataLayer automatisée.
Pour conclure
« Est-ce que GA4 fonctionne ? » est une question mal posée, et c'est ce qui la rend dangereuse : elle reçoit toujours une réponse rassurante. Le tag part, donc ça marche.
Posez-la en trois temps. Le tag part-il, la donnée arrive-t-elle, la donnée est-elle juste ? Les deux premières prennent un quart d'heure et se règlent avec les outils de Google. La troisième demande de comparer votre collecte à quelque chose d'extérieur, et c'est la seule dont dépendent vos décisions média et vos rapports de direction.
Si vous ne devez retenir qu'une chose : un tag vert est un test de transport, pas un test de vérité.
Vous voulez savoir ce que votre collecte remonte vraiment, sans y passer la demi-journée ? Faites-le auditer — on regarde vos parcours critiques et on vous dit où sont les écarts.
FAQ
Comment savoir si Google Analytics 4 fonctionne sur mon site ?
En trois étapes, pas une. Le mode Aperçu de GTM confirme que le tag se déclenche, DebugView confirme que GA4 reçoit l'événement et ses paramètres, et un rapprochement avec votre back-office confirme que les chiffres sont justes. Les deux premières prennent un quart d'heure ; la troisième est la seule qui prouve quelque chose sur la qualité des données.
Pourquoi mon tag est-il vert dans Tag Assistant alors que mes données sont fausses ?
Parce que Tag Assistant vérifie le transport, pas le contenu. Il confirme qu'un tag s'est déclenché, pas que les valeurs envoyées étaient correctes ni que GA4 les a traitées comme prévu. Un purchase sans montant, un événement compté deux fois par un second conteneur GTM ou un paramètre envoyé en texte au lieu d'un nombre affichent tous un tag vert.
Combien de temps faut-il pour que les données apparaissent dans GA4 ?
DebugView et le rapport Temps réel sont immédiats. Les rapports standards, eux, ne se remplissent qu'après 24 à 48 heures. Ne concluez jamais à une panne parce qu'un rapport standard est vide le jour de la mise en production : vérifiez dans DebugView, qui répond tout de suite.
Pourquoi DebugView ne montre-t-il pas mes événements ?
Le plus souvent parce que le mode debug n'est pas actif : DebugView ne montre que les sessions en mode debug. Le mode Aperçu de GTM l'active automatiquement, sinon il faut l'extension Google Analytics Debugger ou un paramètre debug_mode sur la configuration. Vérifiez aussi que vous ne naviguez pas depuis une IP exclue par un filtre de trafic interne.
Quel écart est normal entre GA4 et mon back-office ?
Entre 8 et 10 % sur les transactions et le chiffre d'affaires, du fait du consentement refusé, des bloqueurs de scripts et des fenêtres d'attribution. Au-delà de 20 %, traitez-le comme un incident de collecte et cherchez la cause. Ce rapprochement est la vérification la plus importante et la plus souvent absente.
À quelle fréquence faut-il vérifier son tracking GA4 ?
À chaque mise en production, parce qu'une vérification n'est valide que jusqu'au déploiement suivant. Nos propres relevés montrent qu'une régression met en moyenne deux semaines à être remarquée, sauf quand elle touche directement le chiffre d'affaires. À partir de quelques MEP par mois, refaire le contrôle manuellement à chaque fois n'est plus tenable et l'automatisation devient le seul moyen de tenir le rythme.