Un achat validé sur votre site n’apparaît pas dans les rapports Meta, alors que les autres événements (PageView, AddToCart) remontent bien via Conversions API. Dans la majorité des cas, l’origine du blocage se situe dans la chaîne technique entre le back-end, le consentement utilisateur et la configuration Meta. Supposer que l’API remonte systématiquement tous les achats dès lors qu’elle est branchée conduit souvent à ignorer des points de contrôle essentiels.
Après lecture, vous saurez vérifier chaque étape critique du flux d’achat côté Meta CAPI, diagnostiquer si le problème provient d’un access token expiré, d’une mauvaise gestion du consent mode, d’un domaine non validé ou d’un event mal structuré. Vous identifierez les points de friction spécifiques à l’environnement e-commerce français, y compris les contraintes CNIL sur le consentement et la mesure d’audience.
Comprendre le flux d’un achat côté Meta CAPI
Lorsqu’un utilisateur finalise un achat sur votre boutique, l’événement Purchase peut être transmis à Meta via deux canaux distincts : côté client (Pixel) et côté serveur (CAPI). Le Pixel injecté dans le navigateur déclenche l’event, mais pour contourner les limites liées aux bloqueurs ou aux refus de consentement, la tendance est d’ajouter une transmission côté serveur, souvent via un conteneur GTM Server ou un proxy dédié.
Le Pixel côté client collecte immédiatement les données disponibles dans le navigateur (produits, valeur, devise, user agent, cookies Meta). Cet event est visible dans Events Manager presque en temps réel si le consentement cookies a été donné. La transmission côté serveur intervient après traitement sur votre backend ou via un middleware (GTM Server, proxy maison). Le serveur récupère les informations de la commande depuis le data layer ou la base de données, puis génère un appel HTTP vers l’API CAPI de Meta.
Le data layer joue un rôle central : il structure les données transactionnelles (ID de commande, montant total, liste des produits, currency, email hashé si disponible). Ce data layer doit être accessible côté serveur pour alimenter l’event envoyé à Meta. Un data layer incomplet ou inaccessible au moment du trigger côté serveur bloque la remontée d’achats.
La déduplication empêche la double remontée du même achat si vous activez à la fois Pixel et CAPI. Meta attend que chaque event Purchase dispose d’un identifiant unique (event_id) partagé entre client et serveur. Si ce paramètre diverge ou manque, Meta peut ignorer l’event serveur ou le marquer comme dupliqué. Vérifiez dans Events Manager si les events serveur apparaissent en « dédupliqué » ou « ignoré » : l’interface affiche la source et le statut de chaque event reçu.
Vérifier le scope et la validité de l’access token Meta
L’access token utilisé pour envoyer des events server-to-server via Meta CAPI doit disposer des scopes ads_management et business_management. Sans ces permissions, aucun event ne sera accepté côté Meta. Pour générer ou régénérer un token, connectez-vous à Meta Business Suite, ouvrez le menu « Paramètres d’entreprise », puis accédez à « Intégrations » > « API Meta pour les conversions ». Vérifiez le token associé à votre pixel ; si besoin, cliquez sur « Générer un access token ».
Un token expiré ou révoqué empêche toute transmission d’event. La durée de validité dépend du mode d’émission (long-lived ou non). Si les events n’apparaissent plus dans Events Manager, vérifiez dans le tableau de bord Meta si le token est marqué comme inactif ou si un message d’erreur s’affiche lors de l’appel API. Une erreur courante : code 190 « Invalid OAuth 2.0 Access Token ».
Pour tester rapidement la validité du token, envoyez un event Purchase via l’API Graph Explorer ou Postman. Utilisez l’endpoint /v{version}//events. Le payload minimal doit inclure event_name, event_time, action_source et custom_data avec currency et value. Exemple de requête JSON :
{
"data": [
{
"event_name": "Purchase",
"event_time": 1717000000,
"action_source": "website",
"custom_data": {
"currency": "EUR",
"value": 120.00
}
}
]
}
Dans Graph Explorer, sélectionnez l’application liée à votre Business Manager, insérez l’access token, et vérifiez la réponse. Un code 200 avec { "events_received": 1 } indique que le token et le scope sont valides. Les erreurs d’authentification ou de permission signalent un problème de scope ou de validité.
En production, surveillez la colonne « Statut » dans Events Manager : une absence d’events server-side malgré des events client-side implique souvent un problème avec l’access token ou ses scopes.
Contrôler la vérification du domaine côté Meta et côté site
Meta exige qu’un domaine soit vérifié pour que les événements server-side envoyés via CAPI soient correctement attribués et pris en compte dans les rapports et le suivi des conversions. Un domaine non vérifié entraîne généralement l’absence de remontée ou d’attribution des achats dans Events Manager, même si les requêtes CAPI sont techniquement valides.
La vérification du domaine s’effectue dans le Business Manager, section « Brand Safety » puis « Domains ». Trois méthodes sont acceptées :
- Ajout d’une balise
<meta name="facebook-domain-verification" content="..." />dans le<head>de la page d’accueil du domaine principal. - Ajout d’un enregistrement TXT dans la zone DNS du domaine.
- Upload d’un fichier de vérification à la racine du domaine.
Le piège classique : placer la balise ou le fichier sur un sous-domaine (par exemple shop.exemple.fr) alors que le domaine vérifié dans Meta est exemple.fr, ou l’inverse. Meta ne considère pas automatiquement tous les sous-domaines comme vérifiés même si le domaine principal l’est. Vérifiez que la balise ou le fichier est accessible sur le domaine exact utilisé dans l’URL de finalisation de commande.
Pour auditer, rendez-vous dans Events Manager, cliquez sur le pixel concerné, puis sur l’onglet « Domaines » : le domaine utilisé pour envoyer les events doit s’afficher comme « Vérifié ». Si ce n’est pas le cas, aucun event CAPI, y compris Purchase, ne sera attribué à ce domaine.
En environnement de test ou de préproduction (preprod.exemple.fr), la vérification est rarement mise en place. Les events envoyés depuis ces environnements ne seront donc pas attribués, ce qui fausse les tests. Utilisez toujours un domaine vérifié pour valider la chaîne complète.
En cas de doute sur la prise en compte, testez la présence de la balise facebook-domain-verification dans le code source ou vérifiez la propagation DNS depuis un outil tiers. Un écart entre le domaine de vérification déclaré côté Meta et le domaine réel côté site bloque l’attribution des achats.
Analyser la configuration du consentement utilisateur et du consent mode
La CNIL impose une distinction claire entre la mesure d’audience strictement nécessaire au fonctionnement du site (exempte de consentement sous conditions) et la publicité personnalisée, qui requiert toujours un consentement explicite. L’envoi d’événements Purchase à Meta via CAPI relève systématiquement de la publicité ciblée selon la doctrine CNIL : le consentement préalable de l’utilisateur est donc obligatoire.
Si l’utilisateur refuse le dépôt de cookies publicitaires, le déclenchement côté client des tags Meta Pixel doit être bloqué. Côté server-side, le conteneur GTM doit vérifier l’état du consentement avant d’émettre l’event Purchase vers Meta. Un paramétrage incorrect du consent mode peut entraîner l’absence totale de remontée d’achats, même si le reste de la chaîne fonctionne.
Dans GTM client-side, le consent mode Google s’active via la balise gtag('consent', ...). Côté server-side, le signal de consentement est généralement transmis au conteneur via le data layer ou un header HTTP personnalisé. Vérifiez que ce signal est bien reçu et traité dans le serveur, et que la balise Meta CAPI n’est déclenchée que si le consentement publicité est présent.
Pour diagnostiquer, commencez par inspecter les logs du conteneur server-side (GTM ou alternative). Recherchez la présence d’un paramètre de consentement (ad_storage ou équivalent) dans les requêtes reçues. Si ce paramètre indique un refus, l’event ne doit pas être envoyé. Si le consentement est accordé mais que l’event n’apparaît pas dans l’Event Manager Meta, poursuivez la vérification sur la configuration du tag et la transmission des données.
Pour les sites qui souhaitent remonter des achats sans cookie, la CNIL ne le permet pas pour la publicité : aucun event Purchase ne doit être transmis à Meta sans consentement valide. Toute tentative de contournement expose l’éditeur à un risque de sanction.
Inspecter la structure et le contenu de l’event Purchase envoyé à Meta
Un event Purchase envoyé à Meta via CAPI doit inclure certains champs pour être pris en compte. Les champs obligatoires sont event_name (valeur : Purchase), event_time (timestamp Unix en secondes), event_id (identifiant unique de la transaction, utile pour la déduplication), user_data (informations utilisateur hashées) et custom_data contenant au minimum value (montant total, décimal ou entier) et currency (code ISO 4217, ex : EUR).
Pour user_data, Meta attend des valeurs hashées en SHA256 et normalisées avant hashage : emails en minuscules, sans espaces, numéros de téléphone sans séparateurs, prénoms et noms sans accent ni majuscule. Si vous envoyez des données non hashées ou mal normalisées, l’event peut être rejeté silencieusement. Vérifiez que, côté serveur, le hashage s’effectue avant l’envoi et que les clés attendues sont bien transmises (par exemple em, ph, fn, ln).
Utilisez Meta Events Manager pour vérifier si l’event est reçu et accepté. Si l’event apparaît mais n’est pas traité, inspectez les détails pour repérer des erreurs de format ou de données manquantes. Chrome DevTools permet de vérifier les events côté client, mais pour CAPI, consultez les logs serveur : contrôlez le payload JSON envoyé à l’API Meta, l’URL utilisée (/vXX.X/{pixel_id}/events, version à vérifier dans la documentation actuelle), et la réponse HTTP. Un code 200 ne garantit pas la prise en compte de l’event : analysez le corps de la réponse pour des erreurs de validation.
Meta peut ignorer un event si des champs sont manquants, mal formatés ou incohérents. Par exemple, un value absent ou non numérique, une currency vide, ou un user_data incomplet. Si l’event n’apparaît pas du tout dans le Events Manager, vérifiez le mapping des champs et le format exact des données transmises.
Points de friction courants dans la chaîne de transmission
Une configuration incorrecte du conteneur GTM server-side empêche souvent la transmission des achats à Meta. Vérifiez d’abord l’URL de l’endpoint utilisé dans vos tags client-side : il doit pointer vers votre sous-domaine (exemple : https://ssgtm.votredomaine.fr) et non vers le domaine par défaut de Google. Contrôlez aussi que le tag “Meta Conversion API” est bien actif dans le conteneur server-side, et que l’access token utilisé correspond bien au Business Manager attendu.
Les autorisations de l’access token côté Meta ne suffisent pas : le conteneur GTM server-side doit lui-même pouvoir envoyer des requêtes sortantes vers les endpoints Meta. Si votre hébergement impose un proxy ou un firewall (fréquent sur des serveurs en France pour respecter la localisation des données), vérifiez que les requêtes HTTP sortantes vers graph.facebook.com sont autorisées. Un blocage typique se détecte par des erreurs 403 ou 502 dans les logs du conteneur server-side ou dans les rapports d’erreurs du GTM.
Meta impose des limites de fréquence sur les événements CAPI ; un dépassement conduit à des erreurs 429 (Too Many Requests) ou 400 (Bad Request). Surveillez le dashboard Events Manager pour la remontée de ces statuts. Un volume anormalement élevé de tentatives d’achats en test, ou une boucle de retry mal configurée dans le tag server-side, déclenche rapidement ces limites.
La synchronisation des horodatages event_time est critique. Un écart trop important entre l’heure d’envoi du serveur et la valeur de event_time (plusieurs minutes d’écart) peut entraîner le rejet silencieux de l’événement. Vérifiez que le serveur GTM est synchronisé via NTP. Pour éviter les doublons, Meta recommande de passer un identifiant unique d’achat dans le paramètre event_id ; en cas de doublons, seuls les premiers événements sont pris en compte, les suivants sont ignorés sans message explicite côté dashboard.
Frequently asked questions
Meta CAPI peut-il fonctionner sans cookies sur le site ?
Oui, mais la qualité de l’attribution et du matching d’audience dépendra de la quantité et de la qualité des user_data envoyées. La conformité CNIL impose de ne pas déposer de cookies marketing sans consentement, ce qui limite la collecte côté client.
Comment tester rapidement si un event Purchase est reçu par Meta ?
Utiliser l’outil de test d’événements dans Events Manager, ou envoyer un event manuellement via Postman/Graph Explorer avec l’access token et vérifier la réception en temps réel.
Not sure your tracking is telling you the truth?
Propulse Agency audits e-commerce tracking setups — server-side tagging, Meta CAPI, GA4 and consent — and fixes what is quietly costing you conversions.
Prioriser vos vérifications et documenter chaque étape
Commencez par isoler la source du blocage : vérifiez d’abord la réception de l’événement côté serveur Meta (section Événements du Gestionnaire d’événements). Si aucun Purchase n’apparaît, examinez le consentement utilisateur transmis au moment de l’appel CAPI, puis la structure de la requête POST envoyée vers l’API Meta.
Documentez systématiquement chaque test, en notant la configuration du consent mode et la présence effective du paramètre event_id. La plupart des implémentations échouent à cause d’une discordance entre le consentement effectivement collecté (ou son absence) et ce qui est transmis à Meta. Sans documentation précise, les erreurs se répètent à chaque évolution du site ou du cadre légal.
