Votre analytics dit que le site a fait 42 180 le mois dernier. Votre base de commandes dit 39 650. Quelqu'un demande lequel a raison, et la réponse honnête est en général ni l'un ni l'autre, pour des raisons individuellement ennuyeuses et collectivement coûteuses.
Voici les cinq causes, à peu près dans l'ordre de la fréquence à laquelle chacune se révèle être la bonne, avec un moyen de les distinguer.
1. La page de confirmation se déclenche plus d'une fois
C'est de loin la cause la plus fréquente, et elle gonfle toujours.
L'événement d'achat vit d'habitude sur la page de confirmation de commande. Cette page est rechargée chaque fois que quelqu'un la rafraîchit, revient en arrière puis en avant, l'ouvre depuis son courriel, ou se la fait restaurer par un navigateur qui rouvre les onglets au démarrage. Chacun de ces cas redéclenche l'événement avec la même valeur.
Vous la reconnaissez à la forme de l'écart : l'analytics est plus haute que la base de commandes, l'écart est un multiple net sur une poignée de grosses commandes, et l'effet est pire sur mobile, où la navigation arrière est plus fréquente.
La solution est un identifiant de transaction. Envoyez le numéro de commande avec l'événement d'achat et laissez l'analytics dédoublonner dessus. Dans GA4 le champ s'appelle transaction_id ; la plupart des outils reprennent ce nom parce que la convention GA l'a emporté. Si le modèle de votre gestionnaire de balises a un champ pour cela et que vous l'avez laissé vide, c'est votre bug.
Il vaut la peine d'être direct sur ce que coûte une erreur ici. Une page de confirmation qui se redéclenche et compte une seule vente quatre fois n'a pas l'air d'une erreur dans un tableau de bord. Elle a l'air d'un bon mois.
2. Deux devises additionnées
Si vous vendez dans plus d'une devise et que votre analytics rapporte un total de revenu unique, découvrez ce qu'elle fait avant de lui faire confiance.
Certains outils convertissent vers une devise de reporting à un taux figé à l'arrivée des données. Certains convertissent au taux du jour où vous regardez, ce qui veut dire qu'un mois terminé change de valeur selon le moment où vous l'ouvrez. Certains additionnent simplement les nombres et mettent un symbole devant, produisant un chiffre qui n'est de l'argent dans aucune devise.
Le signe qui trahit, c'est un total qui se situe entre le chiffre correctement converti et la somme naïve, ou un total qui bouge quand vous rouvrez un rapport pour un mois clos depuis longtemps.
Le dispositif le plus sûr est que la devise soit estampillée sur l'événement au moment où il est enregistré et que l'outil ne convertisse jamais. Un rapport multidevise se découpe alors par devise, ou refuse de donner un total unique, et les deux sont plus utiles qu'un chiffre faux énoncé avec assurance.
3. Remboursements, annulations et encaissements échoués
Votre base de commandes est un registre vivant. Elle sait que la commande 8814 a été remboursée le 14. Votre analytics a enregistré l'achat le 2 et, à moins que vous ne lui ayez envoyé un événement de remboursement, y croit toujours.
Sur un mois avec des taux de retour normaux, cela seul peut représenter plusieurs pour cent, et c'est la cause qui fait paraître l'analytics haute face à un rapport financier plutôt que face à une table de commandes.
Apparenté, et plus facile à manquer : une commande créée mais jamais encaissée. Si l'événement se déclenche sur la page de confirmation et que le paiement échoue ensuite, ou que la commande reste impayée et est annulée par expiration, l'analytics a une vente que votre grand livre n'a jamais eue.
4. Événements bloqués, perdus et jamais envoyés
Celle-ci dégonfle toujours, et c'est pourquoi l'analytics est en général plus basse que la table de commandes quand elle n'est pas gonflée par les causes ci-dessus.
Les bloqueurs de contenu arrêtent la requête. Certains réseaux d'entreprise aussi, certains filtres au niveau DNS, et certains navigateurs axés sur la vie privée par défaut. Si votre analytics exige un consentement, tous ceux qui ont refusé manquent aussi. Et un événement d'achat qui se déclenche au chargement de la page fait la course avec le visiteur qui ferme l'onglet, ce qu'il fait très souvent à l'instant où la commande est confirmée.
La taille de la fraction bloquée varie énormément selon le public (un site d'outils pour développeurs perd infiniment plus qu'un fleuriste), si bien que tout pourcentage publié est sans valeur pour votre cas. Mesurez le vôtre : comptez les commandes que votre base a enregistrées face aux événements d'achat que l'analytics a enregistrés, appariés sur l'identifiant de commande, pour une seule semaine propre.
Si vous ne pouvez pas apparier sur l'identifiant de commande, c'est de nouveau la cause numéro 1.
5. Les deux systèmes comptent des moments différents
Enfin, l'ennuyeuse, celle qui explique le petit résidu qui reste après avoir corrigé tout le reste.
L'analytics horodate l'événement dans la session du visiteur, dans le fuseau horaire sur lequel le rapport est réglé. Votre base de commandes horodate la ligne au moment où le prestataire de paiement a confirmé, en UTC, peut-être quelques minutes plus tard et parfois de l'autre côté de minuit. Une frontière de mois transforme cela en différence réelle : toujours dans le même sens, toujours petite.
L'attribution s'y ajoute. L'analytics affecte le revenu à la session qui a converti (ou à une session antérieure, selon le modèle d'attribution) tandis que votre table de commandes ne l'affecte à rien du tout. Comparer un total de revenu au dernier clic à un total brut de commandes, c'est comparer les réponses à deux questions différentes.
Un rapprochement que vous pouvez vraiment faire tourner
- Choisissez une semaine close.
- Exportez les commandes : identifiant, horodatage en UTC, devise, valeur nette après remboursements.
- Exportez les événements d'achat avec les mêmes champs.
- Faites la jointure sur l'identifiant de commande.
Les quatre paniers qui en tombent sont le diagnostic. Les événements sans commande sont des doubles déclenchements ou du trafic de test. Les commandes sans événement sont du blocage ou une balise cassée. Les paires appariées avec des valeurs différentes sont un problème de devise, ou un décalage entre montants taxe comprise et taxe exclue. Les paires appariées à des jours différents sont un problème de fuseau horaire.
Faites cela une fois, notez le résidu en pourcentage, et vous avez quelque chose de bien plus précieux qu'un total qui correspond : une différence connue et stable. Deux systèmes qui divergent d'un 4 % constant sont tous deux utilisables. Deux systèmes qui s'accordent par coïncidence ne le sont pas.
Où Skomi se situe
Skomi lit l'identifiant de commande depuis order_id, et aussi depuis le transaction_id de GA : un site déjà étiqueté pour GA4 n'a donc rien à changer. Un événement portant un identifiant qu'il a déjà vu n'est pas compté de nouveau.
Le revenu est estampillé avec sa devise au moment où il est enregistré, et Skomi ne convertit jamais entre devises : un rapport couvrant deux devises montre deux chiffres, parce que le chiffre unique serait une fiction. Il y en a davantage sur la page Analytics, et installer l'extrait couvre l'envoi de l'événement.
Deux définitions font l'essentiel du travail ici : le revenu est attribué à la visite qui l'a gagné plutôt qu'à la page sur laquelle il a été payé, et la devise du revenu est estampillée à l'ingestion et jamais convertie.