Quand les chiffres de Meta ne correspondent pas à votre backend

Presque tout annonceur finit par le remarquer : le gestionnaire de publicités Meta rapporte un nombre d’achats et le backend de la boutique, Shopify, un CRM, un système de gestion de commandes, en rapporte un autre. Aucun des deux chiffres n’est faux. Ils mesurent des choses différentes par conception.

Pourquoi les deux chiffres divergent

Fenêtre d’attribution. Meta attribue une conversion à une publicité si elle a eu lieu dans une fenêtre définie après un clic ou une vue (souvent 7 jours pour le clic et 1 jour pour la vue par défaut, bien que configurable). Un système backend enregistre simplement la commande au moment où elle est passée, sans notion de quelle publicité en obtient le crédit. Une vente conclue neuf jours après un clic sur une publicité peut apparaître comme une commande backend tout en tombant entièrement hors de la fenêtre de Meta.

Crédit view-through et modélisation. Meta peut compter une conversion venant de quelqu’un qui a vu une publicité sans jamais cliquer dessus, sur la base d’une attribution modélisée. Un CRM n’a aucun moyen d’enregistrer qu’une personne a simplement vu une publicité. De même, quand Meta ne peut pas observer directement un événement côté navigateur, à cause des refus ATT ou des bloqueurs de publicité, il estime parfois les conversions statistiquement, et ces estimations apparaissent dans le total de la plateforme sans enregistrement backend correspondant.

Parcours multi-appareils. Quelqu’un clique sur une publicité depuis son téléphone et achète plus tard sur un ordinateur portable. Meta peut relier une partie de ce parcours via l’état de connexion, mais pas parfaitement, et un système backend lié à un schéma d’identifiant client différent peut ne pas connecter les deux événements de la même façon.

Déduplication et timing. Un backend compte une commande une seule fois. Un pixel et un événement Conversions API pour la même commande peuvent, sans déduplication correcte via un ID d’événement, être comptés deux fois côté plateforme. Séparément, le jour de reporting de Meta peut ne pas s’aligner avec le fuseau horaire de la boutique, décalant des conversions vers un jour adjacent lorsque les deux sont comparés.

Remboursements. Un total backend reflète généralement le revenu net après remboursements. Le nombre de conversions de Meta peut encore inclure une commande qui a ensuite été remboursée ou annulée.

Quel chiffre croire pour quoi

Utilisez le chiffre backend comme référence pour savoir combien de revenu est réellement entré et ce qui a été expédié. C’est le chiffre pour la finance, l’inventaire, et tout ce qui se réconcilie avec de l’argent réel.

Utilisez le chiffre plateforme, lu de façon cohérente dans le temps plutôt que comparé aux totaux backend, pour juger si une publicité donnée évolue mieux ou moins bien que la semaine dernière. C’est directionnel, pas absolu.

Utilisez le ROAS mixte ou MER, le revenu backend total sur la dépense publicitaire totale tous canaux confondus, quand la question est de savoir si le marketing fonctionne dans l’ensemble. Cela contourne le décalage en ne s’appuyant pas du tout sur l’attribution plateforme.

Comment réconcilier l’écart

Corrigez d’abord la déduplication : confirmez que le pixel et les événements Conversions API pour la même commande partagent un seul ID d’événement. Comparez les totaux sur une période, pas jour par jour, et laissez la fenêtre d’attribution s’écouler entièrement avant de comparer. Vérifiez si les conversions view-through gonflent le chiffre plateforme, et confirmez que les fuseaux horaires correspondent. Attendez-vous à ce qu’un écart subsiste même après tout cela : un écart faible et stable est normal, un écart large ou croissant pointe vers une rupture précise qui mérite d’être investiguée.

Erreurs courantes

Comparer les totaux plateforme et backend du même jour avant que la fenêtre d’attribution ne se soit refermée. Supposer que le chiffre plateforme est gonflé plutôt que de vérifier d’abord la déduplication et le comptage view-through. Couper la dépense sur une campagne parce que ses conversions rapportées ont chuté, alors que le revenu backend est resté stable, sans vérifier si la baisse est un artefact de mesure plutôt qu’une baisse de demande réelle.

Comment YieldBI aide

La couche d’attribution de YieldBI permet de définir explicitement le modèle d’attribution incrémentale et la fenêtre effective, et associe les données pixel aux Conversions API et à l’import de conversions hors ligne pour que les chiffres plateforme restent plus proches du backend. Les Contrôles de croissance rapportent la performance au niveau publicité par rapport à ce modèle configuré, ce qui ancre les décisions de scaling sur une vue cohérente et réconciliée.