Pourquoi GA4 ne concorde pas avec vos commandes et quelle part de l'écart se récupère

Vous ouvrez le rapport d'achats de GA4, vous ouvrez la liste des commandes de PrestaShop, et les chiffres ne concordent pas. Presque toujours, GA4 en compte moins. Parfois plus. Et sur les plateformes publicitaires, l'écart est encore plus grand.

Première idée à avoir en tête : ils ne coïncideront jamais à cent pour cent, et ils ne le doivent pas. L'analytics mesure ce que voit le navigateur du visiteur ; le back-office enregistre ce qui s'est réellement passé. L'utile est de savoir d'où vient chaque part de l'écart, laquelle est légitime et laquelle est une erreur qu'on peut corriger.

Cause 1 : le consentement

Si votre bandeau de cookies fonctionne comme il se doit, le visiteur qui refuse l'analytics n'envoie pas de données complètes. Avec Consent Mode v2, Google reçoit des signaux sans cookies et peut estimer une partie de ces conversions, mais c'est un modèle, pas un comptage.

Cet écart est légitime : c'est le prix de la conformité. Aucune technique ne devrait le contourner. Si quelqu'un vous promet de « récupérer » les achats de ceux qui ont refusé le suivi en les envoyant quand même avec leurs données, il vous propose un problème juridique.

Cause 2 : bloqueurs et navigateurs restrictifs

Les bloqueurs de publicité empêchent le chargement des balises d'analytics et de publicité, même si le visiteur a accepté les cookies. Certains navigateurs réduisent en outre la durée de vie des cookies posés par le navigateur, si bien qu'un visiteur qui revient quelques jours plus tard semble nouveau et que son achat est mal attribué.

Cette part peut être améliorée tout en respectant le consentement : en envoyant la conversion depuis votre serveur, que le bloqueur ne voit pas, et en conservant les identifiants de campagne dans un cookie posé par le serveur.

Cause 3 : le client ne revient pas de la passerelle

Dans beaucoup de boutiques, l'événement d'achat se déclenche sur la page de confirmation. Mais certains clients paient sur la passerelle ou dans l'application de leur banque et ne reviennent jamais sur la boutique : ils ferment l'onglet, le mobile change d'application, la redirection échoue. La commande existe, car la passerelle a prévenu le serveur, mais GA4 n'en sait rien.

C'est l'une des causes les plus importantes et les moins connues. Elle touche surtout les moyens de paiement avec authentification hors de la page (carte validée dans l'application bancaire, paiements depuis le mobile). On ne la corrige qu'en envoyant l'achat quand le serveur sait que la commande est encaissée, et non quand le navigateur arrive sur une page.

Cause 4 : des achats en trop

Quand GA4 compte plus que le back-office, regardez :

• Les rechargements de la page de confirmation qui déclenchent à nouveau l'achat.
• Deux modules ou une balise de Tag Manager qui envoient le même événement.
• Les commandes au paiement échoué comptées à leur création alors qu'elles ne sont jamais encaissées.
• Le navigateur et le serveur qui envoient le même achat sans identifiant commun permettant à la plateforme de dédoublonner.

Cause 5 : vous ne comparez pas la même chose

Avant de chercher des erreurs techniques, vérifiez que vous comparez des chiffres équivalents :

Et les remboursements : si vous ne les envoyez pas à GA4, son chiffre d'affaires reste gonflé alors que le back-office les a déjà déduits.

Comment faire la comparaison, étape par étape

Pour savoir ce que vous perdez réellement, faites cette vérification sur une période close, par exemple le mois précédent :

1. Exportez de PrestaShop les commandes encaissées de la période, sans les annulées ni les remboursées, avec leur référence ou leur identifiant.
2. Exportez de GA4 les transactions de la même période avec leur identifiant de transaction. Si votre balisage n'envoie pas l'identifiant de la commande comme identifiant de transaction, c'est la première chose à corriger.
3. Croisez par identifiant, pas par totaux. Les totaux masquent les compensations : dix achats perdus et dix en double donnent un écart nul.
4. Regroupez les commandes manquantes par moyen de paiement et par appareil. Si presque toutes viennent d'un moyen précis ou du mobile, vous savez où chercher.
5. Regroupez celles en trop selon le nombre de fois où elles apparaissent : les doublons pointent vers des rechargements ou des balises en double.

Refaites la vérification après chaque modification du balisage ou des modules de paiement. Une mise à jour d'un module de passerelle qui change la page de retour peut casser la mesure sans que personne ne s'en aperçoive.

Ce qu'apporte le server side, et ce qu'il n'apporte pas

Envoyer les conversions depuis le serveur de la boutique (ou depuis un serveur intermédiaire) vers GA4, Meta ou Google Ads :

• Récupère les achats perdus à cause des bloqueurs et des clients qui ne reviennent pas de la passerelle.
• Permet d'envoyer l'achat à l'encaissement, et non à l'affichage d'une page.
• Envoie aussi les remboursements et les annulations, que le navigateur ne voit jamais.
• Ne récupère pas ce que le visiteur n'a pas accepté. Le serveur doit respecter la même décision que le bandeau.
• Ne corrige pas un mauvais balisage : si le navigateur envoie l'achat deux fois sans identifiant commun, le serveur n'en ajoute qu'un troisième.

Comment le résoudre dans PrestaShop

RKR API Conversions Pro envoie les conversions depuis votre serveur vers Meta, GA4, Google Ads, TikTok et d'autres plateformes, avec le même identifiant d'événement que le navigateur pour qu'elles ne soient pas comptées deux fois. Les achats peuvent être envoyés à l'encaissement de la commande (le réglage par défaut des nouvelles installations), et les remboursements partiels, les annulations et les commandes créées depuis le back-office sont aussi transmis. Il applique Consent Mode v2 avec le consentement restauré avant le chargement des balises, conserve les identifiants de clic dans un cookie propre posé depuis le serveur, et propose des indicateurs de santé par plateforme ainsi qu'un rapprochement quotidien des commandes. Si vous ne voulez ni installer ni maintenir le serveur, RKR Relay (offres Esencial et Profesional) reçoit les événements signés par le module et les livre à chaque plateforme depuis notre serveur, avec file d'attente, relances, identifiants chiffrés, données personnelles hachées et l'état de chaque livraison visible dans la boutique.