Implémenter la Conversions API (CAPI) de Meta : le guide complet
Comment implémenter la Conversions API de Meta correctement : déduplication, paramètres hashés, score EMQ et pièges les plus fréquents.
Dans ce guide
Le Pixel Meta seul ne suffit plus à mesurer correctement vos conversions. Entre les bloqueurs de publicité, les restrictions navigateur (Safari ITP, Firefox ETP) et la fenêtre d'attribution réduite depuis iOS 14.5, une part croissante de vos conversions réelles n'est tout simplement jamais envoyée à Meta côté client. La Conversions API (CAPI) répond à ce problème en envoyant les événements directement depuis votre serveur, en complément du Pixel — pas à sa place.
Comprendre le principe avant de l'implémenter
CAPI n'est pas un remplacement du Pixel mais un canal parallèle. L'objectif est la redondance : si le Pixel ne capte pas un événement (adblocker, cookie bloqué, navigation privée), CAPI envoie le même événement depuis votre serveur, qui n'est pas soumis aux mêmes restrictions. Bien implémentée, cette redondance améliore la couverture des événements et la qualité de l'attribution, sans dupliquer les conversions comptées côté Meta — à condition de gérer correctement la déduplication.
La déduplication : l'étape que personne ne doit sauter
Chaque événement envoyé à la fois par le Pixel et par CAPI doit porter le même event_id, généré côté client et transmis aux deux canaux. Meta utilise cet identifiant pour reconnaître qu'il s'agit du même événement vu deux fois, et ne le compte qu'une fois dans le Gestionnaire d'événements. Sans cet identifiant partagé — ou avec un identifiant généré différemment côté client et côté serveur — vos conversions sont comptées en double, ce qui fausse le ROAS affiché et peut pousser l'algorithme publicitaire à sur-optimiser sur de faux signaux.
Les paramètres qui déterminent la qualité de l'attribution
CAPI attribue un événement grâce à un ensemble de paramètres de correspondance (matching parameters), à envoyer hashés en SHA-256 quand ils contiennent une donnée personnelle :
Identifiants publicitaires : fbp (cookie premier-parti posé par le Pixel) et fbc (paramètre issu du clic publicitaire, fbclid) — les plus déterminants pour l'attribution.
Données de contact hashées : email (em), téléphone (ph), prénom/nom (fn/ln) — toujours en minuscules et sans espaces avant hachage, sous peine de ne pas matcher.
external_id : votre identifiant utilisateur interne, utile pour relier les événements d'un même utilisateur entre plusieurs sessions.
Le Gestionnaire d'événements Meta affiche un score EMQ (Event Match Quality) de 0 à 10 par événement : c'est l'indicateur le plus direct pour savoir si vos paramètres sont suffisamment complets, avant même de regarder les résultats de campagne.
Implémenter via Google Tag Manager Server-Side
Le chemin le plus courant pour les sites qui ont déjà (ou envisagent) une architecture server-side passe par le tag "Conversions API" natif de GTM Server, disponible en template officiel. Le conteneur server reçoit l'événement du client (via GTM client-side ou directement), enrichit les paramètres disponibles côté serveur (adresse IP, user agent, cookies first-party), puis transmet à l'API Meta. C'est l'approche qui centralise le mieux la logique de déduplication, puisque le conteneur server peut garantir que le même event_id est utilisé pour les deux canaux.
Une alternative existe pour les sites qui n'ont pas encore de conteneur server-side : la Conversions API Gateway, un outil managé par Meta qui simplifie la configuration sans nécessiter d'infrastructure GTM server dédiée — au prix d'un contrôle plus limité sur l'enrichissement des paramètres.
Tester avant de faire confiance aux chiffres
L'outil "Test Events" du Gestionnaire d'événements permet de vérifier, événement par événement, que CAPI reçoit bien les données attendues avant la mise en production. Je recommande systématiquement une phase de recette dédiée : envoyer chaque type d'événement (vue de page, ajout au panier, achat, lead) et vérifier le score EMQ obtenu, plutôt que de découvrir un paramètre manquant plusieurs semaines après le déploiement, une fois que l'optimisation publicitaire a déjà tourné sur des données incomplètes.
Une implémentation plus complexe à discuter ?
Discuter de votre tracking
Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.
Cet enjeu mérite un accompagnement dédié.
Consultant web trackingArticles liés
Pour aller plus loin sur votre projet
Conversion API
Conversion API
Restaurez la qualité de vos conversions Meta et Google malgré le blocage navigateur et la perte de signal iOS / consentement.
Voir l'expertiseQuestions fréquemment posées
CAPI remplace-t-il le Pixel Meta ?
Non, CAPI fonctionne en complément du Pixel, pas à sa place. L'objectif est la redondance : capter les conversions que le Pixel seul manquerait à cause des bloqueurs ou des restrictions navigateur, tout en évitant le double comptage grâce à la déduplication par event_id.
Que se passe-t-il si je n'implémente pas la déduplication ?
Chaque événement capté à la fois par le Pixel et par CAPI sera compté deux fois dans le Gestionnaire d'événements. Le volume de conversions affiché sera surestimé, ce qui fausse le calcul du ROAS et peut inciter l'algorithme publicitaire à optimiser sur des signaux erronés.
Faut-il un conteneur GTM server-side pour utiliser CAPI ?
Ce n'est pas obligatoire — la Conversions API Gateway de Meta permet une implémentation sans infrastructure server-side dédiée — mais un conteneur GTM server offre un contrôle plus fin sur l'enrichissement des paramètres et centralise mieux la logique de déduplication avec les autres plateformes publicitaires.
Comment savoir si mon implémentation CAPI est de bonne qualité ?
Le score EMQ (Event Match Quality), affiché par événement dans le Gestionnaire d'événements Meta, est l'indicateur le plus direct. Un score bas signale des paramètres de correspondance manquants ou mal formatés (hachage incorrect, casse non uniformisée) plutôt qu'un problème d'algorithme publicitaire.