Votre GA4 affiche le mauvais chiffre d'affaires (et personne ne vous a prévenu)

Le problème que personne ne cherche

Quand un CMO ouvre GA4 le lundi matin, il regarde le chiffre d'affaires du week-end. Si le nombre correspond à peu près à ce qu'il attend, il passe au ROAS par canal. Si le ROAS est bon, il augmente le budget. Si le ROAS est mauvais, il coupe.

Le problème : le chiffre d'affaires affiché dans GA4 est faux sur une majorité de sites e-commerce. Pas faux de 1 ou 2 %. Faux de 10 à 30 %. Et les décisions de budget prises sur cette base sont donc fausses aussi.

Les 5 erreurs les plus courantes

Voici les erreurs que l'on retrouve systématiquement sur les implémentations WooCommerce et PrestaShop. Elles sont silencieuses : GA4 ne les signale pas, le dataLayer ne plante pas, aucune erreur JavaScript n'apparaît.

Cinq erreurs. Zéro alerte dans GA4.

Erreur 1 : TTC au lieu de HT

C'est l'erreur la plus répandue. Les plugins WooCommerce envoient par défaut le montant TTC dans le champ value de l'événement purchase. Le CMO compare ce montant avec le CA HT du back-office et constate un écart de 20 % (TVA à 20 %). Souvent, il met l'écart sur le compte des "différences entre outils" et n'investigue pas.

Impact concret : sur 100 000 € de CA mensuel HT, GA4 affiche 120 000 €. Le ROAS calculé est 20 % trop optimiste. Les budgets sont augmentés sur des campagnes qui ne performent pas autant qu'on le croit.

Erreur 2 : le paramètre currency manquant

Google Analytics 4 exige un paramètre currency dans chaque événement purchase. Sans ce paramètre, GA4 accepte l'événement mais n'attribue aucun revenu. L'événement apparaît comme une conversion, mais avec une valeur à zéro.

Le piège : le rapport "Conversions" montre le bon nombre de transactions. Le rapport "Revenu" montre zéro. Si personne ne compare les deux, le problème passe inaperçu pendant des semaines.

Sur PrestaShop, le module GA4 officiel omet parfois le currency quand la devise par défaut n'est pas configurée dans les paramètres du module. Sur WooCommerce, certains thèmes personnalisés écrasent le dataLayer avant que le plugin GA4 ne s'exécute.

Erreur 3 : le double déclenchement

Le scénario classique : l'utilisateur arrive sur la page de confirmation. L'événement purchase se déclenche. L'utilisateur rafraîchit la page (ou clique sur "retour" puis revient). L'événement se déclenche une seconde fois.

Sans transaction_id unique et sans logique de déduplication côté GTM, chaque rechargement crée une nouvelle transaction dans GA4. Sur un site avec 5 000 transactions/mois, si 8 % des utilisateurs rechargent la page de confirmation, cela représente 400 transactions fantômes et un CA gonflé de 8 %.

Erreur 4 : les frais de livraison dans la valeur

Beaucoup de plugins e-commerce incluent les frais de livraison dans le champ value. C'est techniquement correct selon la documentation Google — mais cela crée un écart systématique avec le CA produit du back-office.

Avec un frais de livraison moyen de 6,90 € et un panier moyen de 85 €, le revenu GA4 est gonflé de 8,1 %. Sur 500 000 € de CA annuel, cela représente 40 500 € d'écart.

L'effet cascade sur le Smart Bidding

Le revenu faux dans GA4 ne reste pas dans GA4. Il alimente directement les stratégies d'enchères :

1. Le ROAS cible est calculé sur un revenu gonflé
2. Google Ads pense que les campagnes performent mieux qu'en réalité
3. Les enchères montent, le CPC augmente
4. Le vrai ROAS baisse, mais le ROAS reporté reste stable
5. Le budget est maintenu ou augmenté sur des campagnes qui perdent de l'argent

Pour un budget paid de 50 000 €/mois avec un revenu gonflé de 20 %, l'excès de dépense estimé est de 8 000 à 12 000 €/mois — du budget alloué à des campagnes dont le vrai ROAS ne justifie pas l'investissement.

Comment détecter ces erreurs

GA4 ne vous préviendra pas. Voici les signaux à surveiller :

Signal 1 : écart persistant avec le back-office. Si GA4 affiche systématiquement 15-25 % de plus que votre ERP, c'est probablement du TTC vs HT ou des frais de livraison inclus.

Signal 2 : conversions sans revenu. Dans le rapport d'exploration GA4, comparez le nombre d'événements purchase avec le revenu total. Si le revenu est zéro ou anormalement bas, le paramètre currency ou value est probablement absent.

Signal 3 : transaction_id dupliqués. Exportez vos événements purchase via BigQuery et comptez les transaction_id en double. Au-delà de 2 %, il y a un problème de déduplication.

Korvus automatise cette détection. L'alerte checkout_zero se déclenche quand des événements purchase remontent avec une valeur à 0 ou nulle. Korvus compare également les montants aux baselines historiques pour détecter les anomalies dans les deux sens : inflation soudaine (doublon probable) ou effondrement (paramètre manquant).

Le plan de correction

Immédiat (jour 1) : Vérifiez le paramètre currency dans votre dataLayer. Ouvrez la console, déclenchez un achat test, inspectez l'événement purchase. Si currency est absent, corrigez en priorité.

Court terme (semaine 1) : Comparez le revenu GA4 avec votre ERP sur les 30 derniers jours. Un écart supérieur à 5 % justifie un audit du dataLayer. Vérifiez TTC vs HT et l'inclusion des frais de livraison.

Moyen terme (mois 1) : Implémentez une logique de déduplication sur la page de confirmation (cookie ou sessionStorage avec le transaction_id). Activez l'export BigQuery pour auditer régulièrement les doublons.

Points clés

• Le revenu GA4 est gonflé de 10 à 30 % sur la majorité des sites WooCommerce et PrestaShop
• Les 3 erreurs principales : TTC au lieu de HT, currency manquant, double déclenchement
• GA4 ne signale aucune de ces erreurs — il faut les chercher activement
• L'impact cascade sur le Smart Bidding peut coûter 8 000 à 12 000 €/mois en budget mal alloué
• Un monitoring des montants de conversion en temps réel est le seul moyen d'attraper les régressions dès le premier événement anormal