Votre propriété GA4 indique 4 180 achats le mois dernier. Votre tableau de commandes en affiche 4 690. La réponse honnête est : aucune des deux, tant que vous n’aurez pas identifié les 510 commandes manquantes. Il ne s’agit pas d’un simple problème de clarté. Chaque résultat d’expérience et chaque score de priorisation que vous générez sont calculés à partir d’une donnée erronée, dont l’ampleur et la nature sont inconnues.
Google considère comme normale une large part non mesurée : la modélisation comportementale pour le mode consentement ne s’active que lorsqu’une propriété est enregistrée. au moins 1 000 événements par jour avec analytics_storage='denied' pendant au moins 7 joursEn dessous de ce seuil, les données manquantes restent manquantes.
Ce guide s'adresse aux responsables de l'analyse ou de l'optimisation du taux de conversion au sein d'une équipe e-commerce. À la fin, vous disposerez d'un tableau de rapprochement, d'une décomposition de votre écart en causes identifiées avec un test pour chacune, et d'un seuil de tolérance justifiable.
Ce que mesure réellement un rapprochement des achats
Une réconciliation ne consiste pas à « faire correspondre les chiffres ». Ils ne correspondront jamais, et une équipe qui s'y oppose a généralement commis une erreur plus grave que de laisser l'écart tel quel. Elle permet de répondre à trois questions : quelle est l'ampleur de l'écart ? Quels mécanismes identifiés le produisent ? Et quelle part est récupérable, à quel prix ? Nous la réalisons avant toute expérimentation, car un test basé sur un événement de conversion qui entraîne la perte silencieuse d'une part inconnue de commandes n'est pas une expérimentation.
Étape 1 : extraire deux tables pouvant être jointes sur l’ID de commande
Il vous faut une ligne par commande, provenant des deux systèmes, pour la même période calendaire, avec une clé présente des deux côtés.
- Backend: ID de la commande, horodatage de création dans le fuseau horaire de reporting de l'établissement, valeur de la commande sur la même base de taxes et d'expédition que celle configurée dans GA4, mode de paiement, appareil, pays, statut.
- GA4 : L'exportation BigQuery, pas l'interface utilisateur. Requête
purchaseévénements avececommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, catégorie d'appareil et source du trafic.
Utilisez BigQuery de manière délibérée. Les données modélisées issues du mode consentement apparaissent dans les rapports standard de GA4 et dans certaines explorations, mais Google indique qu'il s'agit de données non officielles. pas Dans l'export BigQuery, les audiences, l'explorateur d'utilisateurs, les explorations de cohortes ou de rétention, ou les métriques prédictives. Comparez l'interface utilisateur à votre tableau de commandes : vous comparez alors une estimation à une réalité.
Ensuite, effectuez une jointure externe complète sur l'ID de commande. Vous obtenez alors trois compartiments : un dans les deux bases de données, un uniquement dans le backend et un uniquement dans GA4. Le troisième est plus petit, mais plus informatif.
Étape 2 : exprimer l’écart de trois manières différentes, et non d’une seule.
Un seul pourcentage mensuel masque tout. Calculez les trois :
- Écart du nombre de commandes : (Commandes back-end moins achats GA4 correspondants) / commandes back-end. Ceci permet d'isoler les pertes de suivi.
- Écart de revenus : Le même calcul s'applique à la valeur. Si l'écart de comptage est de 3 % et l'écart de chiffre d'affaires de 11 %, il ne s'agit pas d'un problème de suivi, mais d'un problème de définition de la valeur (taxes, frais de port, remises, devises, cartes cadeaux).
- Variation quotidienne de l'écart : Graphique représentant l'écart quotidien du nombre de commandes. Une ligne plate indique un problème structurel, comme un blocage ou un problème de consentement. Des pics indiquent des déploiements, des pics de campagne ou un incident chez un prestataire de paiement.
Étape 3 : décomposer l’écart en causes nommées
Parcourez ce tableau. Chaque cause possède un test permettant de la confirmer ou de l'infirmer en moins d'une heure.
| Causes | Comment le tester | Signature dans les données |
|---|---|---|
| Consentement refusé, la balise ne se déclenche jamais. | Comparez le journal d'état de consentement de votre CMP aux sessions GA4 pour la même période. | Pourcentage quotidien stable ; concentré dans le trafic de l'UE et de la Turquie |
| bloqueurs de publicités et de traqueurs | Comptez les requêtes du journal serveur pour l'URL de confirmation et comparez-les aux événements d'achat de Google Analytics sur cette URL. | Biais pour les navigateurs de bureau, Firefox et les navigateurs axés sur la confidentialité ; stable dans le temps |
| La page de confirmation ne se charge jamais. | Compter dans les journaux du serveur les commandes exécutées uniquement via le backend dont l'URL de confirmation n'a jamais été demandée. | Axé sur les méthodes de paiement par virement bancaire et 3DS |
| Événements d'achat en double | Compter les événements d'achat GA4 par transaction_id | GA4 dépasse le backend certains jours ; pages très sollicitées par le rafraîchissement et le bouton retour |
| Lien interdomaine rompu | Vérifier si _gl survit au voyage de retour du prestataire de paiement | Les achats effectués dans de nouvelles sessions sont attribués au domaine de paiement en tant que parrainage. |
| Réinitialisation de la durée de vie des cookies | Taux de nouveaux utilisateurs segmenté par navigateur | Augmentation artificielle du nombre de nouveaux utilisateurs et du trafic direct sur Safari et iOS |
| Modélisé versus brut | Comparez les totaux de l'interface utilisateur de GA4 à ceux de BigQuery pour une plage de dates identique. | Les deux chiffres de Google divergent avant même que vous n'ouvriez le tableau des commandes. |
| Définition de la valeur | Recalculer les revenus back-end avec et sans taxes, frais de port et remises | Les comptes correspondent, mais pas les revenus. |
| Limite du fuseau horaire | Regrouper en semaines complètes | L'écart se réduit à zéro à une granularité hebdomadaire |
Deux d'entre eux méritent une attention particulière. transaction_id La déduplication fonctionne uniquement sur les flux web, et non sur les flux d'applications. Google avertit par ailleurs que l'envoi d'une chaîne vide entraîne la déduplication par Analytics. chaque achat événement transport transaction_id=''Ce simple bug peut vous faire perdre presque toute une journée. Par ailleurs, la liste des sites référents indésirables est limitée à 50 domaines par flux de données, ce qui pose problème si vous utilisez plusieurs acquéreurs, portefeuilles et pages bancaires.
[DONNÉES INTERNES NÉCESSAIRES : la répartition observée de ces neuf causes dans les différents projets de réconciliation de Switas, afin que les lecteurs puissent voir lesquelles prédominent généralement.]
Étape 4 : définissez une tolérance que vous pouvez défendre
Google ne publie aucun seuil de tolérance, et l'affirmation souvent citée « 5 % c'est acceptable » n'apparaît dans aucune documentation Google consultée. Définissez votre propre seuil, en fonction de la décomposition plutôt que du seul chiffre.
| Écart mensuel du nombre de commandes | Lecture | Action |
|---|---|---|
| Jusqu’à 2 % | limites de fuseaux horaires et déduplication normale | Consignez les causes et vérifiez-les trimestriellement. |
| 2% à 5% | Acceptable uniquement si chaque point est attribué à une cause nommée | Documentez, puis procédez à l'expérimentation. |
| 5% à 10% | Au moins une cause structurelle demeure non résolue. | Corrigez avant de faire confiance aux nombres de conversion absolus |
| Au-dessus de 10% | Ne convient pas à l'expérimentation | Cessez d'utiliser les achats GA4 comme principal indicateur d'expérimentation jusqu'à ce que le problème soit résolu. |
Il s'agit de nos seuils opérationnels, et non d'une norme sectorielle. Cette précision est essentielle : un taux inexpliqué de 3 % est pire qu'un taux expliqué de 8 %.
Étape 5 : fixer l’ordre de traitement qui permet de récupérer le plus de commandes par heure de travail.
- Définition de la valeur et fuseau horaire. Configuration, pas ingénierie, et généralement un après-midi.
- Identifiants de transaction en double et vides. Une correction pour la couche de données.
- Références interdomaines et indésirables. Configurez les deux, puis testez à nouveau le chemin de retour des paiements en production, et non en environnement de test.
- Événement d'achat côté serveur. Envoyez la commande depuis votre système de gestion des commandes avec le protocole de mesure, en utilisant le
client_idVotre balise Web a été générée. Google exige que ces événements soient enregistrés dans les 48 heures suivant l'horodatage de l'événement côté client d'origine, sans quoi l'attribution risque de ne pas se dérouler correctement. C'est ce qui permet de récupérer les commandes perdues à cause de blocages ou de pages de confirmation qui ne se sont jamais affichées. - Architecture du consentement. La plus lente et la plus politique. Considérez le reste comme une lacune connue, dimensionnée et documentée.
Qu’est-ce qui change si vous vendez en Turquie ou dans l’UE ?
Deux facteurs régionaux font varier les chiffres.
Le consentement est également optionnel en Turquie, mais sans le filet de sécurité de Google. L'autorité turque de protection des données a infligé une amende de 300 000 TL à un exploitant de site web (décision 2022/1358 du 23 décembre 2022) pour avoir utilisé des cookies publicitaires et marketing sans base légale, et a exigé un consentement explicite pour les cookies non essentiels. De nombreux sites turcs ont réagi en affichant une bannière bloquant purement et simplement la balise Google, au lieu d'une bannière envoyant des signaux de consentement. Cette distinction est coûteuse : la modélisation nécessite… analytics_storage='denied' Des événements peuvent exister. Une bannière qui ne s'affiche pas ne fournit aucune donnée à Google pour ses modèles ; les données sont donc perdues plutôt qu'estimées.
Les 3DS turques sont renvoyées à l'acheteur par la poste. Avec iyzico, le commerçant affiche une page 3DS décodée et, après confirmation du code OTP, iyzico redirige vers le site du commerçant. callbackUrl au status, paymentId et mdStatusUn retour généré par une requête POST correspond précisément à ce que Google appelle une rupture de la mesure inter-domaines, car les redirections peuvent entraîner des erreurs. _gl Avant même que la page de destination ne se charge. Si votre écart se situe au niveau des paiements par carte et qu'il est quasi nul pour le paiement à la livraison, c'est pour cette raison.
Deux affirmations largement répétées que nous n'avons pas pu vérifier.
« Safari limite la durée de vie des cookies internes à 7 jours. » Imprécis. La documentation de WebKit indique que l'ITP supprime les cookies JavaScript et autres données de stockage modifiables par script après 7 jours. aucune interaction avec l'utilisateurPar ailleurs, la durée de vie des cookies JavaScript est limitée à 24 heures lorsque la page d'accueil est accessible via un lien depuis un domaine d'annonces classées. Les tests de Simo Ahava ont révélé que ce délai est calculé en jours d'utilisation du navigateur, et non en jours calendaires ; un client régulier peut donc conserver un identifiant pendant plus d'une semaine.
« Un écart de 5 % est acceptable. » Nous n'avons trouvé aucune source Google pour ce chiffre. Il circule sur les blogs de fournisseurs et dans les réponses aux forums. Considérez-le comme une information courante, et non comme un critère absolu.
Là où cette méthode échoue
Il ne couvre pas les flux d'applications, où transaction_id La déduplication ne s'applique pas, ni aux modèles d'abonnement et de livraison partielle, où une commande ne correspond pas à un événement unique. L'outil ne permet pas de retrouver l'identité d'un utilisateur ayant refusé son consentement, mais seulement d'estimer le volume. Il ne résout pas l'attribution des canaux, un problème distinct et plus complexe. Enfin, il suppose que votre table de commandes est irréprochable : si les commandes annulées et bloquées pour fraude sont comptabilisées de manière incohérente de part et d'autre, vous risquez de rechercher une lacune qui n'existe que dans votre requête.
Foire aux questions
À quelle fréquence devrions-nous exécuter cette opération ? Effectuez une décomposition complète une première fois, puis un graphique d'écart quotidien. Relancez la décomposition complète après toute modification apportée à la page de paiement, à la plateforme de gestion des paiements, au fournisseur de paiement ou au gestionnaire de balises.
Pourquoi ne pas utiliser l'interface GA4 au lieu de BigQuery ? L'interface peut inclure des utilisateurs et des sessions modélisés que l'exportation ne prend pas en compte, ce qui explique la divergence entre les deux chiffres de Google. Toute comparaison avec une estimation rend cet écart impossible à analyser.
Le balisage côté serveur permettra-t-il de combler complètement l'écart ? Non. Ce service récupère les commandes bloquées par des bloqueurs ou dont les pages de confirmation ne se sont jamais affichées. Il ne récupère pas les commandes des utilisateurs ayant refusé leur consentement.
GA4 a un taux de rafraîchissement supérieur à celui de notre serveur. Est-ce possible ? Oui. Généralement, les événements d'achat dupliqués proviennent des actualisations de page, d'une page vide ou réutilisée. transaction_id, ou des ordres de mise en scène déclenchés dans la propriété de production.
Le mode de consentement permet-il de combler le déficit de consentement en Turquie ? Partiellement. Les signaux bloqués permettent la modélisation, sous réserve des seuils de volume de Google. Cela ne remplace pas une bannière publicitaire conforme à la réglementation turque.
Qu'est-ce qui constitue un bon écart ? Un système où chaque point de pourcentage a une explication. Un taux de 8 % justifié vaut mieux qu'un taux de 3 % inexpliqué.
Devrions-nous reformuler les rapports historiques après avoir corrigé cela ? Non. Indiquez la date de fixation et traitez les périodes comme des séries distinctes. La réinitialisation des conversions suivies détruit la piste d'audit.
Peut-on réaliser des tests A/B alors que l'écart est supérieur à 10 % ? Utilisez des indicateurs relatifs mesurés dans l'outil de test, mais ne communiquez pas l'impact absolu sur les revenus de GA4 tant que l'écart n'est pas décomposé.
Effectuez ce rapprochement sur votre propre magasin ce mois-ci, ou Laissez notre équipe d'analystes s'en charger avec vous. et vous fournir la décomposition, la tolérance et l'ordre de correction.
Références
- [GA4] Modélisation comportementale pour le mode de consentement, Aide Google Analytics
- [GA4] Minimiser les événements clés dupliqués avec les ID de transaction, Aide de Google Analytics
- [GA4] Redirections indésirables, Aide Google Analytics
- [GA4] Mesure inter-domaines, Aide Google Analytics
- Envoyer les événements du protocole de mesure à Google Analytics, Google pour les développeurs
- Paramètres du mode de consentement, documentation de Google Tag Platform
- Prévention du suivi dans WebKit
- Suppression de la limite de durée de vie des cookies JavaScript dans les navigateurs WebKit, Simo Ahava
- KVKK Kurul karari 2022/1358, 23 décembre 2022
- Implémentation 3DS, documentation pour développeurs d'iyzico
