Pourquoi vos chiffres de commandes GA4 et PrestaShop ne correspondent pas (et comment y remédier)
Si Google Analytics 4 rapporte moins d'achats que votre back-office PrestaShop, vous n'imaginez rien. Voici ce qui cause l'écart et comment le combler.
Presque tous les marchands PrestaShop qui regardent de près constatent la même chose : le nombre de commandes dans GA4 est inférieur à celui du back-office. Parfois l'écart n'est que de quelques pour cent. Souvent l'écart est bien plus grand. Dans tous les cas, cela fausse discrètement chaque décision que vous prenez à partir de ces données — attribution, budgets publicitaires, taux de conversion et le chiffre d'affaires que vous vous rapportez à vous-même.
Le back-office est la source de vérité. Il enregistre chaque commande réellement payée. GA4, en revanche, dépend d'une balise qui se déclenche dans le navigateur du client au moment exact. Quand cette balise ne se déclenche pas, la commande a tout de même lieu — GA4 n'en entend simplement jamais parler.
Une fois que vous comprenez la poignée de mécanismes derrière cet écart, la solution devient simple. Passons-les en revue, puis voyons comment combler l'écart pour de bon.
Le navigateur est un endroit hostile pour compter l'argent
Le tracking GA4 classique est côté client : un extrait JavaScript s'exécute dans le navigateur de l'acheteur et envoie l'événement purchase à Google. Cela paraît fiable jusqu'à ce que vous vous souveniez de tout ce qui peut mal tourner entre la page de confirmation de commande et les serveurs de Google.
L'acheteur ferme l'onglet avant que la page ne soit entièrement chargée. Sa connexion mobile coupe en pleine redirection. Une erreur de script ailleurs sur la page interrompt l'exécution avant que votre balise ne se lance. La page de confirmation redirige trop vite pour que la balise parte. Chacun de ces cas vous est invisible, et chacun est un événement purchase perdu.
Sur les pages de paiement — la page la plus importante de votre boutique — ces échecs se concentrent, car c'est précisément là que se rejoignent les redirections de paiement tierces, les réseaux lents et les acheteurs impatients. Les événements qui vous importent le plus sont ceux que le navigateur est le moins susceptible de livrer.
Les bloqueurs de publicités et l'ITP dévorent vos conversions
Une grande part des acheteurs utilisent des bloqueurs de publicités ou des extensions de confidentialité qui bloquent purement et simplement Google Analytics. Pour ces visiteurs, l'achat ne s'enregistre tout simplement jamais — la requête vers Google est annulée avant de quitter le navigateur. Environ 3 internautes sur 10 utilisent un bloqueur de publicités (GWI, 2025), et l'adoption est nettement plus élevée dans les segments technophiles ou plus jeunes.
L'Intelligent Tracking Prevention (ITP) d'Apple ajoute une autre couche. Sur Safari et iOS, les cookies posés par le JavaScript côté client sont supprimés après 7 jours sans nouvelle visite — et plafonnés à 24 heures quand le visiteur arrive par un lien décoré de paramètres de tracking (la politique WebKit d'Apple elle-même). Un visiteur qui clique sur une publicité aujourd'hui et achète la semaine prochaine ressemble à une session toute neuve, non attribuée. La commande peut tout de même arriver dans GA4, mais dépouillée de la campagne qui l'a générée.
Safari porte une grande part de la navigation mobile — StatCounter la suit mois par mois — ce n'est donc pas un cas marginal ; pour bien des boutiques, cela décrit une large tranche des acheteurs mobiles. Notre glossaire explique l'ITP et les termes associés en langage clair.
L'inflation des sessions aggrave encore l'apparence de l'écart
Tandis que les bloqueurs de publicités et l'ITP réduisent vos conversions, un problème distinct gonfle vos sessions. Quand les cookies expirent prématurément, une même personne sur plusieurs visites est comptée comme plusieurs utilisateurs différents dans plusieurs sessions différentes. Votre dénominateur (les sessions) augmente tandis que votre numérateur (les achats) diminue.
Le résultat est un taux de conversion qui paraît bien pire que la réalité — non pas parce que quoi que ce soit a changé sur le site, mais parce que les mêmes acheteurs sont répartis sur davantage de sessions tandis que leurs achats disparaissent discrètement.
Les marchands « optimisent » alors contre un chiffre qui n'a jamais été exact, coupant des campagnes en réalité rentables et remettant en question un tunnel de commande qui fonctionne très bien. Le problème de données devient un problème commercial.
La TVA et les ID de transaction faussent aussi le chiffre d'affaires
Même quand une commande est suivie, le chiffre d'affaires peut être faux. Beaucoup de configurations envoient le sous-total hors taxes au lieu du montant réellement payé par le client. PrestaSignal envoie le chiffre d'affaires TVA incluse (le vrai total_paid_tax_incl) pour que GA4 corresponde à l'argent qui a atterri sur votre compte, ce qui compte dès l'instant où vous calculez le ROAS ou alimentez les enchères avec des valeurs de conversion.
L'autre tueur silencieux, ce sont les ID de transaction dupliqués ou aléatoires. Si l'événement purchase peut se déclencher deux fois — une fois à la confirmation, une fois lors d'un rechargement de page ou d'un clic sur le bouton retour — et que chaque déclenchement utilise un nouvel ID aléatoire, GA4 compte deux commandes pour une seule vente. Vous avez alors une sous-estimation due aux événements perdus et une surestimation due aux doublons, superposées l'une à l'autre, rendant le vrai chiffre presque impossible à raisonner.
La solution est un transaction_id construit à partir de la commande elle-même — jamais aléatoire — afin que les rechargements et les nouvelles tentatives se réduisent à une seule commande, à chaque fois.
La solution côté serveur
Le tracking côté serveur sort entièrement l'événement purchase du navigateur fragile. Quand PrestaShop confirme une commande, votre back-office rapporte la vente de serveur à serveur — via un serveur de suivi géré que nous opérons pour vous — sur une route qui ne passe pas du tout par le navigateur. La vente est enregistrée exactement une fois, et les remboursements suivent avec le transaction_id correspondant pour que GA4 reverse le chiffre d'affaires correctement.
Comme l'événement provient de la commande elle-même, il porte le montant réellement payé et un transaction_id stable. Il n'y a pas de course contre une redirection, aucune dépendance à ce que l'acheteur garde l'onglet ouvert, aucune extension pour annuler la requête.
Les événements du quotidien ont leur propre correctif. PrestaSignal enregistre les pages vues, les vues produit et les événements de panier via un petit connecteur sur votre propre adresse web, et sert aussi les bibliothèques de balises Google depuis votre domaine. Les listes de filtres des bloqueurs de publicités actuels ciblent les domaines de Google — sans domaine d'analyse tiers sur la page, il ne reste rien sur ces listes à faire correspondre. Et pour le versant ITP de l'écart, un vrai cookie first-party posé par le serveur (conservé deux ans) préserve l'identité d'un acheteur Safari qui revient : la suppression au bout de 7 jours d'Apple s'applique aux cookies posés par JavaScript, pas aux cookies posés par le serveur. Voyez côté serveur vs côté client pour la comparaison complète, ou lisez comment ça marche spécifiquement sur PrestaShop.
À quoi s'attendre après la correction
Une fois le tracking d'achat côté serveur en place, l'écart se réduit généralement de façon spectaculaire. Vous n'atteindrez pas toujours une correspondance parfaite au 1:1 — quelques différences sont légitimes, comme les commandes annulées ou frauduleuses filtrées, ou les commandes de test exclues de l'analyse — mais la sous-estimation structurelle disparaît.
Ce sont les effets en cascade que les marchands remarquent le plus. Le taux de conversion revient à un chiffre crédible. Le ROAS des campagnes cesse de paraître artificiellement médiocre, vous arrêtez donc de couper celles qui gagnent. Le chiffre d'affaires dans GA4 s'aligne sur celui de votre banque, ce qui rend chaque rapport en aval — et chaque conversation avec une agence ou une marketplace — bien plus digne de confiance.
Si vous voulez voir votre propre écart mesuré face à vos vraies commandes PrestaShop, réservez un audit et nous quantifierons exactement combien GA4 manque actuellement.
Questions rapides
Quelle est généralement l'ampleur de l'écart entre GA4 et PrestaShop ?+
Cela varie selon l'audience et la configuration — il n'existe aucune moyenne sectorielle vérifiable. Environ 3 internautes sur 10 utilisent un bloqueur de publicités (GWI, 2025), et les boutiques uniquement côté client en subissent l'effet en premier. Les audiences très mobiles et soucieuses de leur vie privée tendent vers le haut de la fourchette.
Le tracking côté serveur fera-t-il correspondre GA4 exactement à mon back-office ?+
Il vous en rapproche beaucoup. Les événements côté serveur captent les commandes que les balises côté client manquent, si bien que la différence restante est généralement faible et explicable plutôt qu'une sous-estimation structurelle.
Pourquoi GA4 affiche-t-il parfois plus de chiffre d'affaires que prévu ?+
Habituellement à cause d'événements purchase dupliqués avec des ID de transaction aléatoires qui comptent une vente deux fois. Un transaction_id construit à partir de la commande elle-même supprime les doublons.
Cela nécessite-t-il de changer ma propriété GA4 ?+
Non. Vous gardez la même propriété GA4 et le même measurement_id. Le tracking côté serveur change la façon dont les événements atteignent GA4, pas l'endroit où ils atterrissent.
Puis-je conserver aussi mes balises GA4 côté client ?+
Oui — les événements comportementaux continuent d'affluer depuis le navigateur, enregistrés via un connecteur sur votre propre adresse web, pendant que vos ventes empruntent une seconde route sans navigateur depuis le back-office. Les deux partagent un event_id, donc rien n'est compté deux fois.