GA4 e-commerce : la checklist de l'événement purchase bien mesuré

Configurer GA4 e-commerce, c'est déclarer le moment de la vente sous la forme d'un seul événement purchase, avec quatre paramètres obligatoires (value, currency, transaction_id, items) et un déclencheur incapable de compter deux fois la même commande. Le travail ne s'arrête pas au premier envoi. Il s'arrête quand DebugView affiche exactement un événement, quand le chiffre d'affaires du rapport rejoint les commandes du back-office 24 à 48 heures plus tard, et quand la répartition par canal raconte la même histoire que vos plateformes publicitaires. La liste ci-dessous teste ces trois seuils.

Qu'est-ce que la mesure GA4 e-commerce, précisément ?

La mesure GA4 e-commerce consiste à déclarer chaque étape du parcours d'achat avec des noms d'événement et des paramètres normalisés. Voyez-la comme un contrat plutôt que comme une balise : les rapports GA4 attendent exactement ces noms. Si la nomenclature dévie, l'événement arrive quand même, mais les rapports de chiffre d'affaires, de produits et de conversions restent vides.

• view_item : une fiche produit a été consultée. Mesure l'intérêt produit.
• add_to_cart : ajout au panier. C'est là que naît le dénominateur de l'abandon de panier.
• begin_checkout : entrée dans le tunnel de paiement. La perte à l'intérieur du tunnel devient visible ici.
• purchase : commande finalisée. Seule source du chiffre d'affaires, du ROAS et de la répartition par canal.

Les quatre comptent, mais seul le dernier pilote l'arbitrage publicitaire. Si le temps manque, rendez d'abord purchase irréprochable et complétez le reste ensuite.

Quels paramètres sont obligatoires sur l'événement purchase ?

Quatre paramètres portent tout l'événement : value (montant de la commande), currency (code ISO), transaction_id (identifiant unique de commande) et items (tableau produits). S'il en manque un, GA4 enregistre l'événement mais le rapport correspondant reste vide : sans currency pas de calcul de CA, sans transaction_id pas de déduplication, sans items aucune performance produit.

• value : le montant total. Décidez si la TVA et la livraison sont incluses, puis gardez ce choix identique à celui du back-office, sinon chaque comparaison tourne au débat.
• currency : code ISO 4217 (EUR, USD, CHF), envoyé au niveau de l'événement. En boutique multidevise, chaque événement porte son propre code.
• transaction_id : unique par commande. Jamais aléatoire : dérivez-le du numéro de commande du back-office pour rendre la réconciliation possible.
• items : au minimum item_id et item_name par produit. price, quantity, catégorie et variante sont recommandés et donnent leur profondeur aux rapports produits.

Pourquoi la même commande est-elle comptée deux fois ?

Les doublons viennent du fait d'accrocher l'événement d'achat à la page de remerciement. Un rafraîchissement, un retour arrière ou un lien de confirmation partagé le redéclenchent. GA4 écarte un second événement portant le même transaction_id dans une fenêtre de 24 heures, mais cette protection s'effondre si l'identifiant est généré aléatoirement à chaque envoi, et le chiffre d'affaires gonfle.

1. Dérivez transaction_id du numéro de commande du back-office. Ni nombre aléatoire, ni horodatage, ni identifiant de session.
2. Déclenchez l'événement uniquement sur paiement confirmé, depuis un seul point. Rattachez-le à l'état de la commande, pas au chargement de la page.
3. Stockez l'identifiant envoyé dans le stockage de session du navigateur et bloquez le second envoi. C'est l'assurance la moins chère contre les rafraîchissements.
4. Si le navigateur et le serveur envoient tous les deux, coupez-en un ou assurez-vous qu'ils utilisent le même transaction_id. Sinon, deux enregistrements ressemblent à deux commandes.

Comment les remboursements et annulations touchent-ils le chiffre d'affaires ?

GA4 ne déduit pas les remboursements tout seul. Quand une commande est remboursée ou annulée, il faut envoyer en plus un événement refund. Sans cela, le CA GA4 s'éloigne progressivement du net du back-office et tout calcul de ROAS bâti dessus devient optimiste. Dans les catégories à fort taux de retour, comme le prêt-à-porter et la chaussure, cet écart change directement les arbitrages.

• Remboursement total : même transaction_id que la commande d'origine, montant remboursé en value positif, plus currency. N'envoyez pas de valeurs négatives.
• Remboursement partiel : même transaction_id accompagné d'un tableau items ne contenant que les produits et quantités retournés. GA4 ne retire que ces lignes.
• Annulation : une annulation avant expédition qui annule le revenu se traite comme un remboursement. La comptabilité peut les distinguer, la mesure non.
• Décalage : les retours arrivent plusieurs jours après la vente. Le ROAS d'hier et celui du mois dernier n'ont donc pas la même maturité : comparez des périodes avec le même décalage.

Comment aligner la répartition par canal sur les décisions publicitaires ?

Compter le bon nombre d'achats au bon montant ne suffit pas. Chaque achat doit aussi être attribué au bon canal. Quand la répartition casse, le total du chiffre d'affaires paraît juste alors que la distribution est fausse, et le budget part vers le mauvais canal. La cause la plus fréquente : un prestataire de paiement qui coupe la session et s'attribue la conversion.

• Exclusion de référents : ajoutez les prestataires de paiement et les domaines d'authentification 3-D Secure à la liste des référents indésirables. Vous pouvez définir jusqu'à 50 domaines par flux de données.
• Mesure inter-domaines : si le panier, le paiement et la confirmation vivent sur des domaines différents, déclarez-les comme un seul parcours. Sinon chaque saut crée une session et une source nouvelles.
• Discipline UTM : activez le marquage automatique sur les canaux payants et, là où vous taguez à la main, choisissez utm_source et utm_medium dans un vocabulaire figé. L'écriture libre pulvérise la répartition.
• Ce que direct veut dire : direct signifie rarement qu'un internaute a tapé votre adresse. C'est le plus souvent une information manquante. Une part de direct anormalement élevée est le premier signal d'un problème de configuration.

Même une fois la répartition corrigée, GA4 et la plateforme publicitaire ne coïncideront pas à l'unité près : modèles d'attribution, fenêtres de conversion et définitions du clic diffèrent. Nous détaillons l'origine de cet écart dans l'écart de conversions entre GA4 et Google Ads. Pour le versant technique de la perte de signal, voyez le suivi côté serveur.

Que validez-vous, étape par étape, une fois la configuration terminée ?

Validez en trois couches : au moment de l'événement dans DebugView, après traitement à 24 ou 48 heures, puis au niveau des canaux. Ne sautez pas l'ordre, car une configuration parfaite dans DebugView peut rester fausse dans la couche rapports à cause de remboursements absents ou d'une source cassée. Déroulez ces six étapes dans l'ordre.

1. DebugView : passez une vraie commande de test et vérifiez que vous voyez exactement un événement purchase. Ouvrez-le et contrôlez que value, currency, transaction_id et items sont renseignés.
2. Correspondance d'identifiant : le transaction_id de l'événement est-il caractère pour caractère le numéro de commande du back-office ? Corrigez tout de suite les préfixes ou différences de format.
3. Test de rafraîchissement : rechargez la page de confirmation et revenez-y avec le bouton retour. Aucun second événement purchase ne doit partir.
4. Test de remboursement : remboursez partiellement la commande de test et vérifiez que l'événement refund porte les bons produits.
5. Rapprochement des rapports : attendez 24 à 48 heures, puis comparez le nombre de transactions et le chiffre d'affaires aux commandes du back-office sur la même période. En pratique, quelques points d'écart sont normaux ; un écart durable et croissant relève d'un problème d'implémentation.
6. Contrôle des canaux : examinez la source et le support des sessions ayant acheté. Si un prestataire de paiement apparaît comme source, votre liste d'exclusions est incomplète.

Comment des données GA4 propres deviennent-elles des décisions ?

À ce stade, vous disposez d'un tableau fiable du chiffre d'affaires et des canaux, mais les décisions restent manuelles. C'est là qu'intervient Ads Sensor : les données de trafic, de conversion et de répartition par canal issues de GA4 sont réunies avec les dépenses Meta Ads, Google Ads, TikTok Ads et Criteo dans un seul panneau, les campagnes sont lues par intelligence artificielle et des actions priorisées, argumentées, sont produites. Soyons francs : Ads Sensor ne configure pas votre GA4, il lit le GA4 déjà en place. La configuration, c'est cette checklist qui la termine.

• Tableau unifié : dépenses plateformes à côté du chiffre d'affaires et de la répartition par canal GA4, sur un seul écran.
• Analyse par IA : risques et opportunités par campagne, chaque recommandation avec son raisonnement.
• Valider et appliquer : les recommandations acceptées sont appliquées via les API des plateformes, l'avant et l'après sont suivis automatiquement.
• Surveillance des anomalies : écarts de dépense, de conversions et de chiffre d'affaires suivis en continu, avec des seuils réglables.
• Mode rapport : rapport mensuel présentable au client, pour les agences.

Une fois la checklist bouclée, l'étape suivante est de faire produire des décisions à la donnée. Vous pouvez rejoindre la bêta, connecter vos comptes et découvrir la première analyse.