Comment vérifier que son tracking GA4 fonctionne vraiment

Mesurer ce qui rapporte · mis à jour le 3 novembre 2026

Le seul test fiable consiste à refaire vous-même le parcours d'un client jusqu'à l'achat ou la demande de devis, puis à vérifier que l'événement arrive une seule fois, avec le bon montant, dans GA4, Google Ads et Meta. Ensuite, on compare chaque semaine les conversions enregistrées aux ventes réelles du back-office.

Comment savoir si son tracking GA4 est cassé ?

Un tracking cassé ne se voit presque jamais en regardant GA4 seul : les rapports se remplissent et les courbes bougent. Il se repère en comparant avec la réalité. Plus d'achats que de commandes, des ventes à zéro euro ou attribuées à votre banque : la mesure est fausse.

Le tableau ci-dessous relie les symptômes les plus fréquents à leur cause probable et à l'endroit où la vérifier. Chacun est détaillé plus bas.

La semaine qui suit une refonte ou un changement de thème est la plus risquée : les balises posées par l'ancien prestataire disparaissent, ou se retrouvent en double à côté des nouvelles. C'est une ligne à exiger dans le devis de votre site internet : qui reprend la mesure, et qui vérifie qu'elle fonctionne après la mise en ligne. Sans cette ligne, personne ne s'en occupe, et la panne se découvre des semaines plus tard, quand une campagne semble s'effondrer ou au contraire exploser sans raison.

Pourquoi refaire le parcours d'un client est-il le seul test fiable ?

Parce qu'un outil de diagnostic vérifie qu'une balise existe, pas qu'elle compte juste. Seul un vrai parcours, de la page d'arrivée à la page de confirmation, fait passer la mesure par tous les endroits où elle casse : bannière de cookies, panier, paiement externe, retour sur le site.

Trois vérifications courantes rassurent à tort. « L'extension voit la balise GA4 sur la page » : elle ne dit rien de l'événement d'achat. « Il y a des conversions dans les rapports » : elles peuvent être doublées. « Le prestataire l'a installé » : peut-être, avant la dernière mise à jour du thème.

Le test qui tranche se fait en quinze minutes, depuis une fenêtre de navigation privée. Vous arrivez sur le site comme un client, vous acceptez les cookies, vous ajoutez un produit au panier, vous payez avec une vraie carte, et vous allez jusqu'à la page de confirmation. Puis vous vérifiez trois choses : l'événement d'achat est arrivé, il est arrivé une seule fois, et il porte le montant et le numéro de la commande que vous venez de passer. Pour un site sans vente en ligne, la conversion est l'envoi du formulaire de devis ou de contact, et la preuve est l'e-mail reçu. Refaites ensuite le parcours sur téléphone : c'est souvent là que le paiement passe par une autre page.

Comment utiliser DebugView, Tag Assistant et le rapport Temps réel ?

Tag Assistant ouvre votre site en mode débogage et montre les balises qui se déclenchent. DebugView, dans GA4, affiche en direct les événements envoyés depuis votre appareil, avec leurs paramètres. Le rapport Temps réel confirme que l'événement atteint bien la propriété dans les 30 dernières minutes.

Dans l'ordre :

1. Ouvrez Tag Assistant (tagassistant.google.com) et saisissez l'adresse de votre site. Il ajoute à l'adresse un paramètre qui active le mode débogage ; si votre site passe par Google Tag Manager, le mode Aperçu de Tag Manager fait la même chose⁵.
2. Dans GA4, ouvrez Administration, puis, sous Affichage des données, DebugView. Le flux affiche les événements des 60 dernières secondes, et un cercle par minute sur les 30 dernières minutes⁵. Cliquez sur l'événement purchase et lisez ses paramètres : value, currency, transaction_id.
3. Ouvrez le rapport Temps réel, qui montre l'activité des 30 dernières minutes et sert précisément à vérifier que le code de mesure fonctionne⁶.

Un piège fait perdre beaucoup de temps : DebugView n'affiche rien si le mode de consentement est actif et que vous avez refusé les cookies Analytics⁵. Acceptez-les pendant ce premier test, sinon vous chercherez une panne qui n'existe pas. Google recommande aussi d'exclure le trafic des développeurs quand le mode débogage est activé, pour que vos essais ne se mélangent pas aux vraies données⁵.

Pourquoi GA4 compte-t-il certains achats deux fois ?

Le plus souvent, la mesure est installée deux fois : une fois par la plateforme du site (Shopify, WooCommerce, Wix) et une fois dans Google Tag Manager. Chaque achat envoie alors deux événements. L'autre cause classique est la page de confirmation rechargée, ou rouverte depuis l'e-mail de commande.

Le scénario est banal : un premier prestataire installe Tag Manager avec un événement d'achat, puis le commerçant active l'application Google de sa plateforme, qui pose sa propre balise. Google le documente pour Shopify : des balises restées en place après la migration vers l'application Google & YouTube provoquent un suivi en double, des données inexactes et un impact négatif sur l'optimisation des campagnes publicitaires⁷. Dans Tag Assistant, cela se voit tout de suite : deux événements purchase pour une seule commande.

La correction consiste à choisir un seul chemin et à retirer l'autre. Le filet de sécurité est l'ID de transaction : GA4 déduplique les achats qui portent le même transaction_id, mais uniquement pour les flux web¹. Cet ID doit être le vrai numéro de commande. Si l'ID est vide, ou identique pour toutes les commandes à cause d'une variable mal branchée, GA4 déduplique toutes ces ventes entre elles et en sous-compte une grande partie¹.

Pourquoi l'achat remonte-t-il sans montant ?

Parce que l'événement purchase part sans les paramètres value et currency, ou avec une variable vide. GA4 compte alors bien un achat, mais à zéro euro, ou avec un montant que ses rapports ne savent pas convertir. La devise est obligatoire dès qu'une valeur est transmise.

La documentation de Google est explicite : si value est renseigné, currency est requis pour que les métriques de revenus soient calculées correctement, et transaction_id est requis pour un achat². Elle précise aussi que value est un nombre, et qu'il correspond à la somme des prix multipliés par les quantités, sans les frais de livraison ni les taxes².

Deux conséquences pratiques. D'abord, le chiffre d'affaires de GA4 ne sera jamais égal à votre total TTC livraison comprise : décidez quelle base vous suivez, et comparez avec la même base dans le back-office. Ensuite, la panne la plus fréquente n'est pas l'absence du paramètre, mais une variable qui change de nom après une mise à jour du thème : le montant passe à vide du jour au lendemain, alors que le nombre d'achats reste correct. Une campagne optimisée sur la valeur des ventes continue de tourner, mais elle apprend sur un chiffre faux.

Pourquoi les ventes sont-elles attribuées à PayPal ou à la banque ?

Parce que le client quitte votre site pour payer, puis revient sur la page de confirmation. Sans réglage, GA4 traite ce retour comme une nouvelle visite venue du site du prestataire, et lui attribue la vente. Votre campagne Google ou Meta perd la conversion qu'elle a réellement produite.

Google décrit ce cas précis : quand un utilisateur revient sur votre site après avoir payé sur un domaine tiers, ce domaine est traité comme un site référent et la seconde session lui est attribuée³. La correction se fait dans Administration, Flux de données, Configurer les paramètres de la balise, puis « Sites référents à ignorer », où l'on ajoute le domaine du prestataire (jusqu'à 50 par flux). Elle ne reclasse pas les sessions déjà attribuées³.

Le problème voisin concerne les domaines croisés : une boutique, un module de réservation ou un formulaire de devis hébergé sur un autre domaine que le site. Sans configuration, chaque domaine pose ses propres cookies, et un même visiteur devient deux utilisateurs et deux sessions⁸. Pendant votre test, cliquez vers l'autre domaine et regardez la barre d'adresse : elle doit contenir un paramètre _gl. Google prévient que certaines redirections ou certains scripts le suppriment⁸.

Le refus des cookies fausse-t-il la vérification ?

Oui, dans les deux sens. Pendant le test, refuser les cookies peut faire croire à une panne, puisque DebugView n'affiche alors rien. En production, chaque visiteur qui refuse réduit ce que GA4 observe : un écart à la baisse avec le back-office est donc attendu, à condition qu'il reste stable.

Google distingue deux implémentations du mode de consentement. En mode de base, les balises sont bloquées jusqu'à l'obtention du consentement. En mode avancé, elles se chargent avant la bannière et, en cas de refus, envoient des signaux sans cookie qui servent à modéliser le comportement et les conversions ; sans mode avancé, GA4 ne reçoit pas de données modélisées pour combler les lacunes⁹.

Ce qu'il faut tester, c'est que la bannière transmet bien le choix. Faites le parcours une fois en acceptant : l'achat doit arriver. Refaites-le en refusant : en mode de base, rien ne doit partir. La casse typique est une bannière installée après coup, qui bloque la balise même après acceptation : les conversions chutent le jour de son installation. Un écart stable vient du consentement ; un écart qui se creuse brutalement vient d'une panne.

Comment vérifier le tracking côté Google Ads et Meta ?

Côté Google Ads, regardez l'état du suivi de chaque action de conversion et lancez Tag Assistant depuis l'écran des conversions. Côté Meta, l'extension Meta Ads Data Advisor (l'ancien Pixel Helper) signale un pixel en double ou un achat sans valeur. Le même parcours de test sert aux trois outils.

Dans Google Ads, ouvrez Objectifs, Conversions, Récapitulatif. Les actions à examiner affichent « Non validé », « Balise inactive » ou « Attention requise » dans la colonne « État du suivi ». Le bouton « Résoudre le problème » lance Tag Assistant ; vous refaites la conversion sur le site, vous fermez Tag Assistant, et au bout de 30 minutes environ les actions validées sont mises à jour. Leur état passe alors à « Aucune conversion récente », puis à « Enregistrement de conversions » quand des conversions arrivent⁴.

Côté Meta, l'extension affiche les pixels trouvés sur la page et s'ils se sont chargés ; après votre action de test, l'événement attendu doit apparaître comme réussi. Elle signale notamment le code du pixel dupliqué sur une même page, les paramètres manquants comme value et currency, et les événements en double¹⁰.

Retenez qu'un GA4 juste ne prouve rien pour les autres. Chaque plateforme a sa propre balise : une boutique peut avoir un GA4 exact et un pixel Meta qui compte chaque achat deux fois.

Que faut-il contrôler 30 jours après une correction ?

Les chiffres, et non plus les balises. Trente jours après, on compare semaine par semaine le nombre de commandes ou de demandes du back-office avec les conversions de GA4, de Google Ads et de Meta. Un écart stable et expliqué est acceptable ; un écart qui bouge d'une semaine à l'autre signale une nouvelle casse.

Prenons un exemple type. Une boutique de décoration en ligne, trois personnes, sur Shopify avec Tag Manager. Sur la semaine du 5 au 11 octobre 2026, le back-office affiche 42 commandes pour 3 150 euros ; GA4 annonce 79 achats pour 5 940 euros. Tag Assistant montre deux événements purchase par commande : l'un posé par l'application Google de la plateforme, l'autre par Tag Manager. On retire celui de Tag Manager et on vérifie que l'ID de transaction reprend le numéro de commande. Trente jours plus tard, sur quatre semaines pleines : 171 commandes, 152 achats dans GA4, soit 89 %, avec un ratio compris entre 86 % et 91 % chaque semaine. L'écart restant est stable, et la part de refus de la bannière suffit à l'expliquer.

Les contrôles à faire à cette date :

• commandes du back-office contre achats GA4, semaine par semaine, sur des semaines closes ;
• chiffre d'affaires contre revenus GA4, sur la même base (avec ou sans livraison et taxes) ;
• aucune vente attribuée à un prestataire de paiement dans les sources de trafic ;
• conversions Google Ads et achats Meta jamais supérieurs au nombre total de commandes, ce qui trahirait un double comptage.

GA4 et Google Ads n'afficheront pas le même nombre, et c'est normal : ils ne datent ni n'attribuent les conversions de la même façon. Ce qui ne l'est pas, c'est un outil qui annonce plus de ventes que vous n'en avez fait.

Que pouvez-vous vérifier vous-même dès cette semaine ?

Passer une vraie commande ou envoyer une vraie demande avec Tag Assistant ouvert, puis noter ce qui arrive dans GA4, Google Ads et Meta. Si un contrôle échoue et que la cause n'est pas évidente, il vaut mieux faire vérifier la mesure que continuer à piloter la publicité sur des chiffres faux.

La liste tient sur une page :

1. Un parcours complet sur ordinateur, un autre sur téléphone, cookies acceptés.
2. Dans DebugView : un seul purchase par commande, avec value, currency et le vrai numéro de commande en transaction_id.
3. Le même parcours en refusant les cookies, pour voir ce que fait la bannière.
4. Un clic vers le paiement ou la boutique externe, en regardant la barre d'adresse au retour.
5. Dans Google Ads, l'état du suivi de chaque action ; dans Meta, l'extension Data Advisor.
6. Une note dans votre agenda à trente jours, pour comparer avec le back-office.

Si vous préférez déléguer, l'audit et la correction du tracking reprennent exactement ces étapes sur vos comptes, et le diagnostic gratuit de 30 minutes permet de voir d'abord si c'est nécessaire : réserver un diagnostic.