GA4 e-commerce : vérifier les achats et remboursements avant d’analyser les ventes

Les ventes affichées dans Google Analytics 4 ne correspondent pas toujours aux commandes enregistrées par votre boutique. Un achat peut ne pas avoir été mesuré, un remboursement peut manquer ou une valeur incorrecte peut fausser les revenus suivis.

Avant d’utiliser GA4 pour analyser vos performances e-commerce, vérifiez que les événements purchase et refund sont correctement envoyés, avec les bons identifiants, montants et produits. Comparez ensuite ces informations aux commandes réelles de votre boutique.

L’objectif n’est pas de forcer GA4 à afficher exactement les mêmes chiffres que votre outil de vente. Il est de distinguer les différences normales de mesure des erreurs de tracking qui peuvent conduire à de mauvaises décisions.

Voici une méthode pour contrôler les achats, les remboursements et les écarts de revenus avant d’utiliser ces données pour piloter votre activité.

Pourquoi les revenus GA4 peuvent-ils différer de ceux de votre boutique ?

Votre plateforme e-commerce et Google Analytics 4 ne remplissent pas exactement le même rôle.

La boutique enregistre les opérations commerciales : commandes, paiements, annulations, remboursements et articles vendus.

GA4 collecte des événements : consultation de produits, ajouts au panier, étapes du paiement, achats et remboursements, à condition que ces événements aient été correctement configurés.

Une commande peut donc exister dans votre système commercial sans avoir été enregistrée par GA4.

Cela peut notamment se produire lorsqu’un événement ne se déclenche pas, qu’un visiteur bloque la collecte ou qu’un parcours de paiement échappe à la configuration prévue.

Inversement, une mauvaise implémentation peut envoyer un événement d’achat alors que le paiement n’est pas encore confirmé.

Il faut également distinguer les métriques de revenus.

Dans GA4, les revenus issus des achats tiennent compte des achats mesurés et des remboursements enregistrés. Les métriques relatives aux produits excluent les taxes et les frais de livraison de la valeur des articles.

Les remboursements ne sont toutefois pris en compte correctement que si les événements correspondants sont transmis avec les informations nécessaires.

Google détaille les définitions dans sa documentation sur les dimensions et métriques Analytics.

La première question n’est donc pas « pourquoi les chiffres sont-ils différents ? », mais « comparons-nous réellement les mêmes opérations et les mêmes montants ? »

Vérifier que l’événement purchase correspond à un véritable achat

L’événement purchase indique à GA4 qu’un achat a été effectué.

Il ne doit pas être confondu avec begin_checkout, qui mesure le début du paiement, ni avec add_payment_info, qui renseigne une étape du processus de commande.

Ces événements répondent à des questions différentes.

Déclencher l’achat au bon moment

Commencez par examiner le fonctionnement de votre boutique.

Une commande peut être créée avant que son paiement soit définitivement accepté. Certaines méthodes de paiement redirigent l’acheteur vers un prestataire externe ; d’autres nécessitent une confirmation différée.

Vous devez donc définir précisément à quel moment une commande est considérée comme un achat à mesurer.

Pour une boutique qui ne comptabilise commercialement que les commandes payées, un événement purchase envoyé dès la création d’une commande encore impayée risque de surestimer les ventes mesurées.

À l’inverse, si l’événement dépend uniquement du chargement d’une page de confirmation que certains clients ne consultent pas, des achats peuvent manquer.

La configuration exacte dépend du CMS, du module de paiement et de la méthode de collecte utilisée.

Le principe reste le même : un événement d’achat doit correspondre à une opération commerciale clairement définie, et son identifiant doit permettre de la retrouver.

Contrôler les paramètres indispensables

Google recommande d’envoyer les informations de transaction et les articles achetés avec l’événement purchase.

Paramètre GA4	Fonction	Vérification
transaction_id	Identifier la transaction	Correspond-il à une commande unique de la boutique ?
value	Transmettre la valeur des produits achetés	Le montant est-il calculé correctement, après remises ?
currency	Définir la devise	Correspond-elle à la monnaie de la transaction ?
items	Décrire les articles achetés	Les produits et leurs quantités sont-ils exacts ?
item_id	Identifier une référence	Est-il cohérent avec la référence commerciale suivie ?
price et quantity	Calculer la valeur de chaque ligne	Les prix unitaires et les quantités correspondent-ils aux articles achetés ?
tax et shipping	Déclarer séparément taxes et livraison	Ces montants sont-ils exclus de value et correctement renseignés ?

La documentation officielle des événements e-commerce GA4 précise la structure recommandée.

Une valeur d’achat correctement transmise permet de mesurer les revenus des produits. Mais elle ne garantit pas, à elle seule, que toutes les opérations commerciales aient été collectées.

Contrôler les remises, la TVA et les frais de livraison

Une erreur fréquente consiste à transmettre le montant total payé par le client sans vérifier ce qu’il comprend.

Dans la configuration recommandée par Google, la valeur value d’un événement purchase correspond à :

Valeur de l’achat = somme des prix unitaires après remises × quantités achetées

Les taxes et la livraison sont déclarées séparément.

Prenons un exemple fictif : un client achète deux articles.

• Produit A : 80 € HT avant remise, avec une réduction de 10 €.
• Produit B : 50 € HT, sans remise.
• Les frais de livraison et la TVA sont renseignés séparément.

La valeur des produits à transmettre est :

(80 − 10) + 50 = 120 €

Le paramètre value doit donc représenter 120 €, et non 130 €.

Dans le tableau items, le prix du produit A sera de 70 € après remise, tandis que son paramètre discount pourra indiquer les 10 € de réduction.

Pourquoi cette distinction ?

Parce que GA4 ne soustrait pas automatiquement le paramètre discount du prix unitaire utilisé pour calculer le revenu des articles.

Si vous envoyez 80 € comme prix payé et 10 € comme réduction, en supposant que Google déduira automatiquement la remise, vous risquez de surestimer la valeur réellement vendue.

Google explique cette règle dans sa documentation sur l’application des remises aux événements e-commerce.

Une valeur erronée peut fausser vos analyses de revenus même lorsque le nombre d’achats enregistré est correct.

Vérifier les identifiants de transaction et éviter les doublons

Le paramètre transaction_id joue un rôle central dans la qualité du suivi e-commerce.

Il doit identifier une transaction de manière unique.

Par exemple, si votre boutique enregistre une commande sous la référence CMD-2026-0158, l’événement GA4 correspondant doit utiliser un identifiant permettant de retrouver cette même opération.

Une autre commande ne doit pas reprendre ce même identifiant.

Pourquoi les identifiants uniques sont-ils importants ?

Google Analytics utilise les identifiants de transaction pour dédupliquer les événements d’achat dans les flux Web.

Si deux événements purchase sont reçus avec le même identifiant, GA4 dispose d’un mécanisme permettant d’éviter de compter deux fois le même achat.

Cette protection comporte toutefois des limites.

Google précise notamment que la déduplication par identifiant concerne les données collectées via les flux Web et non les flux d’application.

Un identifiant manquant, incorrect ou réutilisé entre plusieurs commandes peut donc fausser les résultats.

Attention au cas particulier d’un identifiant vide : Google indique que les événements d’achat dont le paramètre transaction_id contient une chaîne vide peuvent être dédupliqués ensemble.

Le risque n’est alors plus seulement de compter trop d’achats, mais aussi de sous-estimer les transactions réelles.

Ces limites sont expliquées dans la documentation officielle sur la déduplication des achats GA4.

La déduplication ne remplace pas un déclenchement fiable

Même avec des identifiants uniques, vérifiez comment les événements sont envoyés.

Par exemple, un achat peut être transmis par un module e-commerce et par une balise Google Tag Manager configurée séparément.

Un rechargement de la page de confirmation peut également déclencher une nouvelle émission si le dispositif n’est pas suffisamment contrôlé.

La déduplication limite certains effets de ces situations, mais elle ne signifie pas que votre installation est correctement configurée.

L’objectif reste d’éviter les émissions inutiles et de disposer d’un seul événement d’achat logique par transaction, avec un identifiant stable.

Contrôler les remboursements avec l’événement refund

Un achat correctement enregistré ne garantit pas que les revenus GA4 resteront cohérents après un retour ou un remboursement.

Pour mesurer ces opérations, Google prévoit l’événement refund.

Il doit être associé à la transaction concernée et contenir les informations nécessaires pour représenter le montant remboursé.

Différencier remboursement total et partiel

Un remboursement total concerne l’ensemble des articles de la commande.

Un remboursement partiel peut concerner une seule référence ou une partie des montants initialement payés.

Dans les deux cas, la mesure doit conserver le bon transaction_id.

Google recommande également de transmettre les articles remboursés dans le tableau items, avec leurs identifiants et quantités, afin d’alimenter correctement les indicateurs de remboursement par produit.

Ces règles sont détaillées dans la documentation sur les événements purchase et refund.

Un remboursement ne doit pas être envoyé simplement parce qu’un client demande un retour. Il faut définir le fait commercial qui déclenche l’événement : par exemple, la confirmation effective du remboursement dans votre système.

Cette distinction permet d’éviter de déduire prématurément des montants qui pourraient encore évoluer.

Exemple fictif : une commande de 120 € puis un remboursement de 50 €

Reprenons une commande contenant deux produits, avec des montants nets HT après remises et hors livraison.

Opération	Produit A	Produit B	Total
Achat initial	70 €	50 €	120 €
Remboursement	0 €	50 €	50 €
Ventes produits conservées	70 €	0 €	70 €

La commande initiale est enregistrée avec un événement purchase de 120 €.

Le client retourne ensuite intégralement le produit B, qui représente 50 € de la commande.

Un événement refund de 50 € est envoyé pour la même transaction, avec les informations correspondant au produit remboursé.

Le montant net des produits conservés est :

120 € − 50 € = 70 €

Il s’agit d’un remboursement partiel de la commande, même si le produit B est entièrement remboursé.

Cet exemple suppose que les deux événements ont été correctement reçus, que les valeurs utilisent la même devise et que les taxes et frais de livraison sont traités séparément.

Le nombre d’achats initiaux ne devient pas automatiquement nul : une commande a bien été réalisée, puis une partie de son montant a été remboursée.

Les métriques doivent permettre de distinguer ces deux opérations.

Ne pas confondre la date de l’achat et celle du remboursement

Un client peut passer une commande en septembre et obtenir un remboursement en octobre.

Si vous examinez seulement les événements d’achat de septembre, vous ne regardez pas nécessairement les mêmes opérations qu’un état commercial recalculant les ventes de septembre après tous les remboursements ultérieurs.

Il faut donc distinguer deux lectures :

Lecture des opérations de la période : achats et remboursements enregistrés pendant les dates étudiées.

Lecture des commandes d’origine : montant finalement conservé sur les commandes passées pendant une période, y compris lorsque les remboursements arrivent plus tard.

Ces deux approches peuvent être utiles, mais elles ne doivent pas être mélangées.

Avant de comparer les ventes nettes de votre boutique aux revenus GA4, précisez la manière dont chaque outil traite la date des remboursements.

Comment tester les événements avec Tag Assistant et DebugView ?

Un rapport GA4 peut afficher des achats sans que leur configuration soit entièrement correcte.

Pour vérifier les informations envoyées, il faut observer les événements et leurs paramètres au moment où ils se déclenchent.

Étape 1 : préparer un parcours de test contrôlé

Choisissez une situation permettant de vérifier une commande identifiable.

Utilisez de préférence un environnement de test ou un mécanisme de commande de test qui ne perturbe pas les ventes réelles.

Définissez le résultat attendu : création de la commande, paiement validé, événement envoyé et montant exact.

Assurez-vous également que le dispositif de mesure respecte les conditions de consentement applicables à votre configuration.

Étape 2 : utiliser Tag Assistant ou le mode Aperçu

Si votre suivi utilise Google Tag Manager, le mode Aperçu permet d’inspecter les déclenchements.

Contrôlez le moment où purchase est envoyé et les paramètres associés.

Vérifiez notamment que la valeur envoyée correspond aux articles réellement achetés, que l’identifiant de transaction est correct et qu’aucun autre déclencheur ne produit inutilement un achat supplémentaire.

Le parcours exact dépend de votre configuration : balise Google, Google Tag Manager, module e-commerce ou autre méthode de collecte.

Étape 3 : consulter DebugView dans GA4

Dans Google Analytics, accédez à Administration → Affichage des données → DebugView, puis observez les événements provenant de votre appareil de test.

Sélectionnez purchase et examinez ses paramètres.

Vérifiez les valeurs de transaction_id, value, currency et les données du tableau items.

Le même contrôle doit être réalisé pour refund lorsqu’un remboursement est traité.

Google explique cette méthode dans ses guides sur DebugView et la validation du suivi e-commerce.

Attention : DebugView montre les événements reçus en mode débogage. Il ne prouve pas, à lui seul, que toutes les transactions de vos clients sont correctement enregistrées en production.

Certains événements peuvent notamment ne pas être visibles selon les paramètres de confidentialité ou le consentement du visiteur.

Étape 4 : contrôler ensuite les rapports standards

Une fois les tests effectués, vérifiez l’apparition des données dans les rapports GA4.

Le traitement des données peut nécessiter un délai. Google indique généralement une disponibilité des données e-commerce dans les rapports sous 24 à 48 heures.

Le rapport Achats d’e-commerce permet notamment d’examiner les produits vendus et leurs performances lorsque les événements et leurs paramètres ont été correctement configurés.

Ne confondez pas cette vue orientée produits avec une liste comptable exhaustive des commandes.

Pour rapprocher les transactions individuelles, une exploration utilisant les identifiants de transaction ou une extraction adaptée peut être plus pertinente.

La disponibilité des données et des dimensions peut dépendre de la configuration des rapports.

Les cas de test les plus utiles

Scénario	Résultat à vérifier
Achat payé normalement	Un achat logique correspondant à la bonne transaction
Paiement refusé ou abandonné	Aucun achat comptabilisé prématurément
Commande avec remise	Valeur correcte après remise
Rechargement de confirmation	Aucun double comptage commercial
Remboursement partiel	Événement refund lié à la bonne commande
Commande avec plusieurs articles	Identifiants et quantités cohérents pour chaque produit

Ce jeu de tests permet de couvrir plusieurs causes fréquentes d’écart sans devoir examiner immédiatement des centaines de commandes.

Rapprocher les transactions GA4 des commandes de la boutique

Après avoir validé les événements, l’étape suivante consiste à comparer les données sur un périmètre représentatif.

Pour cela, il est préférable de partir des commandes réelles et de rechercher leur correspondance dans les informations collectées.

Préparer deux jeux de données comparables

Depuis votre boutique, rassemblez les commandes du périmètre retenu, avec leur identifiant, leur date, leur statut, la devise, les montants des articles après remises et les éventuels remboursements.

Depuis GA4, récupérez les transactions mesurées sur le périmètre compatible, avec leurs identifiants et les valeurs associées.

Conservez les règles de sélection utilisées.

Une commande annulée avant paiement ne doit pas être comparée sans précaution à une transaction enregistrée comme achat.

De même, un test réalisé avec collecte autorisée ne représente pas nécessairement le comportement de tous les visiteurs du site.

Examiner les correspondances, pas seulement les totaux

Prenons un exemple fictif.

Vous disposez d’un ensemble de 100 commandes payées que vous souhaitez contrôler sur une période donnée.

Vous retrouvez 92 identifiants de transaction correspondants dans les données GA4 examinées.

La proportion de commandes retrouvées est :

92 ÷ 100 × 100 = 92 %

Cela signifie que 92 % des commandes de ce jeu de comparaison disposent d’une correspondance identifiée.

Ce résultat n’indique pas automatiquement que les huit autres commandes sont perdues à cause d’un défaut technique.

Il faut examiner les différences possibles de consentement, de collecte, de dates, de flux de paiement et de disponibilité des données.

De plus, retrouver un identifiant ne garantit pas que son montant soit exact.

Le rapprochement doit donc contrôler à la fois la présence des transactions et la cohérence des valeurs transmises.

Quelles erreurs rechercher selon le type d’écart ?

Écart observé	Première vérification
Achats GA4 manquants	Déclenchement, consentement, parcours de paiement et réception des événements
Trop d’achats apparents	Doublons, événements prématurés, commandes de test et identifiants
Nombre proche, revenus différents	Taxes, livraison, remises, quantités, devise et remboursements
Remboursements absents	Envoi de refund, identifiant de transaction et période d’observation
Produits mal renseignés	item_id, déclinaisons, price, quantity et tableau items
Écarts selon les jours	Fuseaux horaires, dates des opérations et délai de traitement

Ne cherchez pas à effacer artificiellement toutes les différences.

Une comparaison utile doit expliquer les écarts identifiés et reconnaître les limites de mesure qui subsistent.

Corriger le suivi avant d’utiliser les revenus pour décider

Une fois un problème confirmé, corrigez d’abord son origine.

Si les remises ne sont pas correctement affectées aux articles, il faut revoir la construction des données envoyées.

Si les achats sont déclenchés trop tôt, la logique de confirmation commerciale doit être examinée.

Si les remboursements ne sont pas transmis, il faut déterminer comment le système de vente peut les communiquer correctement à GA4.

Et si des identifiants produits changent selon les pages, vérifiez la cohérence des références dans le dispositif de collecte.

Après modification, recommencez les tests concernés.

Conservez également une trace de la date du changement.

Cela permettra de comprendre pourquoi certains rapports historiques ont des définitions ou une qualité de collecte différentes des nouveaux.

Ne pas confondre revenus GA4 et rentabilité

Même avec un suivi fiable, les revenus d’achat ne représentent pas automatiquement la contribution économique laissée par les commandes.

Il faut encore tenir compte des coûts produits, des autres coûts variables et, selon l’analyse, des dépenses publicitaires.

De même, les conversions attribuées par Google Ads ne sont pas simplement une copie du nombre total de commandes enregistrées dans la boutique.

Pour comprendre comment rapprocher commandes, produits, coûts, remboursements et données publicitaires, consultez notre article Relier les données PrestaShop pour piloter vos ventes et vos campagnes.

Une fois les données fiabilisées, elles peuvent alimenter des tableaux de bord et des décisions plus pertinentes. Notre guide Choisir les bons indicateurs pour mieux piloter votre boutique approfondit cette étape.

Mettre les indicateurs GA4 en perspective avec les données commerciales dans Vezoa

Vezoa dispose de vues consacrées aux ventes, au catalogue, aux paniers et à l’acquisition, notamment Google Ads.

Ces informations peuvent aider à rapprocher la lecture commerciale d’une boutique de ses performances publicitaires, selon les sources réellement connectées.

Pour interpréter un écart, il reste nécessaire de savoir quelles données ont été importées, quelles périodes sont couvertes et quels coûts sont inclus.

Les outils de vérification de Google Analytics demeurent indispensables pour contrôler les événements purchase et refund à leur source.

La présence de vues commerciales dans Vezoa ne doit pas être confondue avec une validation automatique du plan de marquage GA4.

L’objectif est d’utiliser des données suffisamment fiables pour comprendre les performances de la boutique, puis décider quelles analyses ou corrections méritent votre attention.

Questions fréquentes sur les achats et remboursements GA4

Pourquoi GA4 affiche-t-il moins d’achats que ma boutique ?

Plusieurs causes sont possibles : événement non déclenché, parcours de paiement mal couvert, consentement, blocage de collecte, identifiants incorrects ou différences de dates et de périmètre.

Commencez par vérifier quelques commandes individuelles.

Si les achats mesurés sont corrects sur vos tests, examinez ensuite les conditions de collecte et les écarts observés sur les transactions réelles.

Un nombre inférieur ne démontre pas automatiquement une panne.

GA4 déduit-il automatiquement les remboursements du chiffre d’affaires ?

GA4 dispose de métriques tenant compte des remboursements, mais encore faut-il que les événements refund correspondants soient correctement transmis.

Un remboursement effectué dans votre CMS ne devient pas automatiquement un événement GA4.

Vérifiez le montant, l’identifiant de transaction et les articles concernés. Distinguez également la date du remboursement de celle de la commande initiale.

Comment éviter de compter deux fois un achat ?

Utilisez un transaction_id unique et stable pour chaque commande.

Vérifiez également les déclencheurs, les éventuels modules qui envoient simultanément les mêmes événements et le comportement de la page de confirmation lorsqu’elle est rechargée.

La déduplication de GA4 pour les achats web constitue une protection utile, mais pas un remplacement de la validation technique.