La boutique enregistre une commande, mais les données Meta semblent raconter autre chose. Achat compté deux fois ? Valeur comprenant les frais de livraison ? Ou comparaison entre commandes réelles et ventes attribuées aux annonces ? Chaque question appelle un contrôle différent.
Partez de l’achat et suivez ses données. Le Pixel transmet des événements navigateur ; une intégration Conversions API, ou CAPI, peut aussi les envoyer côté serveur. Il faut vérifier le traitement des copies d’une même action, pas considérer chaque message reçu comme un nouvel achat. Meta aborde correspondance, qualité, déduplication et fraîcheur des données. [1]
1. Convenez du moment où la commande devient un achat
Avec le responsable boutique et le spécialiste tracking, précisez si l’événement part à la confirmation de commande ou après paiement. Sa valeur comprend-elle seulement les produits, ou aussi livraison et taxes ? Écrivez la définition avant d’examiner les chiffres.
Les équipes publicité et boutique peuvent donner le même nom à deux étapes différentes. Modifier cette définition entre deux périodes brouille la comparaison, même si l’envoi fonctionne comme prévu.
2. Testez des cas précis plutôt que de tout réinstaller
Préparez des commandes test dans un environnement adapté, sans données de paiement ou informations personnelles réelles. Notez horaire, valeur, devise et résultat attendu, puis vérifiez la réception avec les outils de votre configuration.
Contrôlez une commande finalisée, une tentative inachevée et la réouverture de la confirmation. Si Pixel et CAPI transmettent l’événement, vérifiez le traitement des deux copies. Les réglages et clés de déduplication viennent de la documentation de l’intégration, pas d’un autre projet copié sans revue.
Exemple : quatre cas pour orienter la vérification
Ces chiffres et identifiants sont fictifs, pas des résultats de boutique.
| Cas | Action dans la boutique | Question à vérifier |
|---|---|---|
| demo-001 | Achat de 120 USD | Valeur et devise correctes à réception ? |
| demo-002 | Un achat envoyé par navigateur et serveur | Traitement comme événement commun aux deux sources ? |
| demo-003 | Confirmation rouverte | Nouvel achat envoyé par erreur ? |
| demo-004 | Achat non finalisé | Fausse finalisation enregistrée ? |
Ajoutez une colonne de résultat et une d’action. Ne concluez pas « le tracking est bon » après un seul cas.
3. Séparez réception et attribution publicitaire
Le registre boutique, les événements reçus et les ventes attribuées aux campagnes sont trois lectures. Avant de réclamer une égalité chiffre pour chiffre, comparez période, fuseau horaire, définition des ventes et attribution, c’est-à-dire la manière de rattacher la conversion à la publicité.
Si la valeur des ventes change sans variation comparable des commandes, examinez définition de valeur, devise et sources d’envoi. Ce sont des pistes de contrôle, pas des explications acquises.
4. Corrigez le problème avant de baser vos décisions sur ce chiffre
Pour une valeur erronée ou un événement répété, notez correction, responsable, nouveau test et date du changement. L’équipe pourra ainsi comprendre la lecture de la période suivante.
Ne changez pas l’objectif pour masquer le problème. N’envoyez pas davantage de données uniquement pour améliorer un score de correspondance sans revoir vos droits de collecte et de partage. Le but est un chiffre compréhensible et utile à la décision, pas un tableau de bord plus flatteur.
Sources officielles
Documentation consultée le 16 octobre 2026. Fonctionnalités et conditions peuvent évoluer ; consultez les sources avant la mise en œuvre.
