Le pixel Facebook ne suit plus les achats ? Checklist de diagnostic

Quand le pixel cesse d’enregistrer Purchase, le dashboard peut donner l’impression que les campagnes se sont effondrées alors que la boutique continue de vendre. C’est l’un des problèmes les plus coûteux à mal diagnostiquer, car il pousse facilement à couper de bonnes campagnes sur la base de conversions simplement absentes du reporting.

La règle est simple : prouvez d’abord que Purchase traverse correctement tout le parcours, puis jugez le ROAS.

Cette checklist part du point le plus concret — une transaction réelle — puis remonte vers configuration, déduplication et matching.

1. Comparez immédiatement commandes réelles et Purchase Meta

Prenez une fenêtre courte mais significative, par exemple les 3 à 7 derniers jours, et comparez :

• les commandes terminées dans le backend ;
• les événements Purchase dans Events Manager ;
• les Purchase attribués dans Ads Manager ;
• le chiffre d’affaires réel et Purchase value.

N’attendez pas une correspondance parfaite 1:1 entre Ads Manager et le backend : attribution, consentement et fenêtres temporelles créent des différences. Mais si le backend contient des commandes et Events Manager presque aucun Purchase, vous avez d’abord un problème de tracking, pas encore un problème publicitaire.

2. Effectuez un achat dans Test Events

Ouvrez Events Manager > Test Events et parcourez le funnel comme un utilisateur réel.

Vérifiez que les événements apparaissent dans l’ordre attendu :

• PageView ;
• ViewContent lorsque pertinent ;
• AddToCart ;
• InitiateCheckout ;
• Purchase uniquement après le vrai paiement ou la confirmation de commande.

Purchase doit apparaître une seule fois par transaction. S’il apparaît avant confirmation, lors d’un refresh, dans le panier ou deux fois, le setup est incorrect même si l’événement « arrive ».

3. Vérifiez value et currency

Un Purchase avec une mauvaise valeur peut casser le reporting ROAS alors même que le nombre de conversions semble normal.

Dans le payload, vérifiez que :

• value est numérique ;
• value représente le vrai total de commande selon votre logique métier ;
• currency utilise un code ISO comme EUR ;
• en multi-devise, la devise réellement utilisée pour la transaction est transmise.

Envoyer 0, null, une chaîne non interprétable ou la mauvaise devise peut laisser le nombre de Purchase correct tout en rendant Purchase ROAS faux.

4. Avec Pixel et CAPI, contrôlez la déduplication

Pixel navigateur et Conversions API doivent fonctionner ensemble, pas se concurrencer.

Pour une même transaction, ils doivent envoyer :

• le même event_name : Purchase ;
• le même event_id ;
• des données d’événement cohérentes ;
• des timestamps raisonnablement proches.

L’event_id doit être créé une seule fois par commande et réutilisé côté Browser et Server. Ne générez pas deux UUID indépendants.

Dans Events Manager, vérifiez le comportement de déduplication. Si Browser et Server apparaissent comme deux Purchase distincts, le ROAS est gonflé. Si une seule source arrive alors que les deux devraient être présentes, vous perdez de la couverture.

5. Cherchez des Pixels ou déclenchements en double

Une cause étonnamment fréquente est la coexistence de plusieurs intégrations : Pixel dans le thème, Google Tag Manager, plugin e-commerce et app Meta envoyant tous le même événement.

Avec Meta Pixel Helper et le code, cherchez :

• plusieurs codes de base Pixel ;
• plusieurs appels fbq('track', 'Purchase') ;
• des listeners dupliqués ;
• un ancien script de checkout encore actif ;
• des apps envoyant Purchase en plus de l’intégration officielle.

Une commande doit créer un seul événement logique, éventuellement reçu par Browser et Server puis dédupliqué.

6. Confirmez le bon dataset

Les comptes avec plusieurs Pixels, anciens datasets ou setups de test peuvent envoyer correctement l’événement au mauvais endroit.

Contrôlez :

• le Pixel/Dataset ID utilisé par le site ;
• le dataset choisi dans l’ad set ;
• le dataset ouvert dans Events Manager ;
• le business propriétaire ;
• les anciens Pixels encore connectés.

Si les campagnes optimisent sur le dataset A alors que le site envoie Purchase au dataset B, Meta reçoit des données mais l’algorithme de campagne reste privé du bon signal.

7. Vérifiez Conversions API côté serveur

Pour CAPI, contrôlez au minimum :

• une réponse de succès de l’endpoint ;
• le bon event_name ;
• un event_time récent et réaliste ;
• action_source: website ;
• event_source_url lorsque pertinent ;
• un event_id partagé avec Browser ;
• des user_data correctement normalisées et hachées lorsque nécessaire.

Une erreur serveur peut être invisible côté frontend. Consultez les logs et la réponse Graph API et ne considérez pas l’événement comme envoyé tant que Meta ne l’a pas accepté.

8. Améliorez Event Match Quality sans casser la confidentialité

Une fois Purchase fiable, améliorez le matching.

Lorsque la loi et le consentement le permettent, CAPI peut transmettre :

• e-mail normalisé et SHA-256 ;
• téléphone normalisé et SHA-256 ;
• external_id ;
• IP et user agent ;
• _fbp ;
• _fbc, y compris dérivé de fbclid.

Hasher deux fois, utiliser un mauvais format ou oublier la normalisation peut dégrader le matching. _fbp, _fbc et event_id ne doivent pas être hachés.

9. Vérifiez consentement et blocages navigateur

En Europe et dans d’autres contextes réglementés, le Pixel peut être légitimement bloqué avant consentement Marketing. Cela ne signifie pas que le setup est cassé.

Testez deux parcours séparés :

1. nouveau navigateur ou incognito sans consentement : aucun événement marketing avant l’opt-in ;
2. acceptez Marketing : les événements suivants doivent partir correctement.

La solution n’est pas de contourner le consentement. Pixel et CAPI doivent suivre exactement l’état de l’utilisateur et la mesure doit fonctionner réellement après l’opt-in.

10. Si le Pixel est sain mais Ads Manager affiche moins d’achats

Le problème peut alors être l’attribution plutôt que le firing. Vérifiez :

• l’attribution setting des ad sets ;
• 1-day par rapport à 7-day click ;
• le délai d’attribution ;
• iOS et événements modélisés ;
• les achats hors fenêtre ;
• le cross-device et les conversions non associables.

Events Manager répond à « l’événement est-il arrivé ? ». Ads Manager répond à « cet événement est-il attribué à cette publicité ? ». Ce sont deux questions différentes.

Checklist finale avant de fermer le problème

Un setup sain remplit tous ces points :

• une commande réelle crée un seul Purchase logique ;
• Purchase arrive dans Test Events ;
• value et currency sont corrects ;
• Browser et Server partagent event_id ;
• les événements sont dédupliqués ;
• le dataset du site et celui de la campagne correspondent ;
• CAPI ne renvoie pas d’erreur ;
• le consentement est respecté ;
• le nombre d’événements reste plausible par rapport au backend.

Seulement ensuite revenez au ciblage, à la création et au budget. Si le tracking est sain mais les annonces obtiennent des clics sans convertir, poursuivez avec l’arbre de diagnostic du funnel.

FixAds contrôle ces signaux avec le reste du compte et sépare les problèmes de mesure des problèmes de performance. Connectez votre compte Meta et lancez le diagnostic gratuit avant de couper une campagne parce que Purchase semble manquer.