Une commande est comptée deux fois lorsque l'événement purchase est envoyé deux fois avec le même transaction_id, ou avec deux identifiants différents pour une même commande. Pour trancher, comparez le nombre d'achats GA4 au back-office, puis inspectez les événements en mode DEBUG et vérifiez si deux déclencheurs envoient purchase. L'interface GA4 ne garantit pas un dédoublonnage automatique de tous les cas.
Pourquoi une commande peut apparaître deux fois dans GA4
Le point de départ est simple : GA4 compte des événements, pas des commandes. Un achat n'existe dans les rapports que parce qu'un événement purchase a été collecté. Si cet événement part deux fois, le rapport Monétisation affiche deux achats, même si la boutique n'a encaissé qu'une seule commande.
La documentation Google sur la mesure e-commerce recommande de définir la devise au niveau de l'événement lorsqu'une valeur est transmise et de renseigner tous les paramètres e-commerce disponibles (Measure ecommerce). C'est ce paramètre qui sert de référence pour rattacher un achat à une transaction.
Deux familles de causes reviennent :
- Deux envois du même identifiant : un déclencheur se déclenche deux fois (rechargement de page de confirmation, double déclenchement d'un trigger, balise dupliquée dans le conteneur).
- Deux identifiants pour une même commande : le site génère un nouvel identifiant à chaque affichage de la page de confirmation, ou le CMS et le module e-commerce produisent chacun leur propre valeur.
Dans le premier cas, le doublon est visible dans les paramètres. Dans le second, il faut comparer les valeurs, pas seulement compter les événements.
Comment vérifier qu'il s'agit bien d'un doublon et non d'un vrai second achat
La première étape ne se fait pas dans GA4, mais dans le back-office e-commerce. Relevez, sur une période courte et sur un canal donné, le nombre de commandes réellement enregistrées. Puis comparez au nombre d'achats du rapport Monétisation, en filtrant sur la même période.
Un écart constant d'environ 2 pour 1 sur une catégorie de commandes est un signal fort. Un écart irrégulier peut venir d'autres causes : commandes annulées, paiements en attente, ou différences de fuseau horaire entre la boutique et la propriété GA4.
Ensuite, ouvrez l'exploration des événements et regardez les transaction_id associés aux purchase. Deux cas se distinguent nettement :
- Même identifiant répété : le doublon est un problème d'envoi.
- Identifiants différents pour la même commande : le doublon est un problème de génération d'identifiant.
Cette distinction oriente tout le reste du diagnostic.
Le protocole en mode DEBUG, étape par étape
Le mode DEBUG permet de voir les événements au moment où ils partent, avant qu'ils ne se mélangent dans les rapports. La documentation Google recommande d'ailleurs d'activer le mode debug lors de l'implémentation e-commerce (Measure ecommerce).
- Activez le mode DEBUG sur votre environnement de test, via l'extension de navigateur ou le paramètre prévu à cet effet.
- Passez une commande de test sur la boutique, avec un moyen de paiement de test si disponible.
- Observez la séquence : combien de fois
purchaseapparaît, et avec quelstransaction_id. - Notez le moment exact de chaque envoi : à l'affichage de la page de confirmation, après un rechargement, ou après un retour depuis le prestataire de paiement.
- Reproduisez en rechargeant la page de confirmation, puis en revenant en arrière : c'est souvent là que le second envoi apparaît.
Si vous utilisez Google Tag Manager, vérifiez en parallèle le déclencheur associé à la balise purchase. Un déclencheur de type « vue de page » sur une URL de confirmation peut se déclencher à chaque rechargement. Un déclencheur basé sur un événement de dataLayer est généralement plus stable, mais dépend de la qualité de ce que le site pousse dans le dataLayer.
Exemple hypothétique
Prenons une boutique fictive. Le back-office affiche 120 commandes sur une semaine. GA4 affiche 190 achats. En exploration, on constate que 70 purchase portent le même transaction_id que 70 autres. Le diagnostic penche vers un double déclenchement sur la page de confirmation, probablement à cause d'un rechargement ou d'un trigger trop large. Les chiffres sont ici illustratifs et ne proviennent d'aucune mesure réelle.
Deux triggers, deux identifiants : le cas le plus difficile
Quand deux déclencheurs envoient purchase avec des transaction_id différents, le dédoublonnage devient impossible à faire de façon fiable côté interface. GA4 ne peut pas savoir que deux identifiants distincts désignent la même commande.
La méthode consiste à remonter à la source de chaque identifiant :
- Le premier vient-il du CMS, le second du module de paiement ?
- L'un est-il généré côté serveur, l'autre côté navigateur ?
- Le numéro de commande affiché au client correspond-il à l'un des deux ?
Tant que cette correspondance n'est pas établie, toute correction reste approximative. La bonne pratique est de faire produire transaction_id par une seule source de vérité, puis de vérifier que les autres envois réutilisent cette valeur.
Ce que l'API et les rapports ne garantissent pas
Il est tentant de chercher une option « dédoublonner » dans l'interface. La documentation officielle ne décrit pas de mécanisme général qui supprimerait automatiquement tous les doublons d'achat. Le transaction_id sert à rattacher les événements à une transaction, mais il ne remplace pas une vérification de votre implémentation.
Autrement dit : la responsabilité du dédoublonnage repose largement sur la collecte. Un contrôle côté interface peut aider à repérer un problème, pas à le corriger à la source.
Pour relier ce diagnostic à une lecture plus large de vos données, vous pouvez vous appuyer sur notre article consacré à l'analyse e-commerce et au suivi d'un problème jusqu'à la commande. Si le doublon accompagne des frictions de parcours, la lecture du tunnel de commande et de ses frictions visibles complète utilement le tableau.
Comment éviter que le doublon revienne après correction
Une correction ponctuelle ne suffit pas si la cause structurelle demeure. Trois vérifications récurrentes limitent les récidives :
- Un seul point d'envoi de
purchasepar commande, documenté dans le conteneur de balises. - Un identifiant stable, généré une fois, réutilisé partout.
- Un test de rechargement de la page de confirmation après chaque modification du tunnel.
En Belgique, en Suisse et en France, les boutiques qui utilisent plusieurs prestataires de paiement doivent aussi vérifier les retours de paiement : un retour depuis un prestataire peut déclencher un nouvel affichage de la page de confirmation.
Questions fréquentes
Le mode DEBUG suffit-il à confirmer un doublon ?
Il confirme qu'un événement part deux fois dans votre navigateur. Il ne prouve pas que tous vos visiteurs sont concernés. Pour cela, comparez les volumes agrégés au back-office sur une période représentative.
Peut-on corriger un doublon déjà enregistré dans GA4 ?
Les données déjà collectées ne se corrigent pas par une simple option. La démarche réaliste consiste à documenter la période concernée, à corriger la collecte, puis à interpréter les rapports de cette période avec prudence.
En résumé
Un achat compté deux fois dans GA4 se diagnostique en croisant trois sources : le back-office, les transaction_id visibles en exploration, et la séquence d'événements en mode DEBUG. La distinction entre identifiant répété et identifiants différents détermine la suite du travail. Aucune option d'interface ne remplace une collecte propre.