Vérifié le 09/09/2026
Vérifier un signal et résoudre un problème Pixel ou CAPI
Vérifier une occurrence
- Ouvrez le diagnostic de mesure avec un compte disposant des accès adaptés. Choisissez le projet, la publication et l’environnement de l’essai ; notez leur version effective.
- Effectuez le geste indiqué dans la fiche du signal. Retrouvez le nom interne, l’heure et event_id. S’il manque, vérifiez d’abord producteur, consentement de collecte et état de session.
- Contrôlez la projection : nom standard/personnalisé exact, propriétés autorisées, identité conservée. Un événement marqué interne seulement n’attend aucun Meta.
- Pour Pixel, distinguez commande à la bibliothèque, requête réseau et reçu déclaré à Funnel Bolt. Avec un bloqueur, une commande peut rester sans réception. Contrôlez ensuite Browser dans les événements de test Meta si cet accès est disponible.
- Pour CAPI, contrôlez éligibilité, tentative, réponse Graph, nombre reçu et état durable. DELIVERED/GRAPH_ACCEPTED décrit une acceptation Graph enregistrée, pas une attribution. Contrôlez ensuite Server chez Meta.
- Pour la déduplication, rapprochez les deux canaux de la même occurrence, même destination, nom projeté et identifiant. Exigez une preuve adaptée chez Meta ; la simple égalité des UUID ou deux lignes locales ne suffit pas.
Rejeu serveur
Les outils de diagnostic et de rejeu relèvent des accès Développeur. Retrouvez la livraison en erreur avant de demander un rejeu autorisé. Corrigez d’abord le motif, puis vérifiez la nouvelle tentative de la même livraison : event_id, nom projeté, heure d’origine, destination et environnement doivent être conservés. Ne créez pas un nouvel achat pour réparer sa livraison.
Un refus marketing ne doit pas être contourné par un rejeu. Une réponse 429/503 ou un problème réseau peut être repris ; une projection invalide ou un rejet permanent nécessite une correction ciblée. Une tentative acceptée par l’outil n’est pas la preuve de sa livraison.
Dépannage par étape
| Motif / état | Interprétation | Action concrète |
|---|---|---|
| Producteur non retrouvé | Déclaration sans collecte établie | Garder la fiche de référence, faire qualifier le producteur ; aucune promesse de geste automatique |
| COLLECTION_DUPLICATE / COLLECTION_LIMIT:n | Refus local avant envoi | Vérifier clé et portée ; nouvelle vue/tentative uniquement si elle correspond à un vrai nouveau parcours |
| MARKETING_CONSENT_REQUIRED | Destination non autorisée | Vérifier consentement effectif ; conserver le non-envoi attendu |
| PIXEL_NOT_INITIALIZED | Pixel choisi/bibliothèque absents | Vérifier connexion, initialisation et bloqueur ; ne pas conclure à une panne CAPI |
| INVALID_META_PROJECTION | Schéma/nom/propriétés invalides | Comparer plan publié et contrat ; corriger la projection sans élargir les données |
| CLAIM_FAILED / INVALID_CLAIM | Prise en charge serveur échouée/invalide | Examiner diagnostic serveur et portée avant reprise |
| NETWORK_ERROR / GRAPH_RETRYABLE | Échec réseau ou réponse reprenable | Suivre la tentative suivante et garder la même identité |
| GRAPH_ACK_MISMATCH | Réponse HTTP correcte mais nombre reçu différent | Laisser en reprise ; ne pas marquer toutes les occurrences livrées |
| GRAPH_REJECTED / DEAD_LETTER | Rejet fournisseur | Corriger droits, destination ou charge selon erreur normalisée, puis rejeu autorisé |
| COMPLETION_NOT_RECORDED | Réponse fournisseur obtenue, état durable non confirmé | Réconcilier le journal avant de conclure au succès |
| Browser seul / Server seul | Un seul canal prouvé | Vérifier l’autre séparément ; déduplication non démontrée |
Le diagnostic ne nécessite pas d’exposer la saisie d’un formulaire. Joignez uniquement codes normalisés, version, environnement, horodatage et identifiants synthétiques dans la documentation. Si les événements de test Meta sont inaccessibles, inscrivez « réception externe non vérifiée » ; aucun test local ne remplace cette preuve.