La Conversion API de Meta (CAPI) envoie vos conversions à Meta depuis votre serveur, et plus seulement depuis le navigateur via le pixel. L'objectif : une mesure plus complète et plus stable, à l'heure où les navigateurs et les bloqueurs font perdre une partie des événements côté client. Ce n'est ni une option magique ni un moyen de contourner le consentement. Voici à quoi elle sert vraiment, quand elle se justifie, et comment la poser proprement, sans compter deux fois vos conversions.
La CAPI revient dans toutes les conversations tracking depuis que le pixel seul montre ses limites. Bien posée, elle fiabilise la mesure de vos campagnes Meta. Mal posée, elle double vos conversions ou suit des gens qui n'ont rien accepté. La différence tient à quelques principes.
L'essentiel
- La CAPI envoie les conversions à Meta côté serveur, en complément du pixel navigateur.
- Ce n'est pas pixel ou CAPI, c'est pixel et CAPI, avec déduplication des événements.
- La déduplication repose sur un identifiant d'événement partagé (event_id) entre le navigateur et le serveur. Sans lui, vous comptez deux fois.
- La CAPI ne contourne pas le consentement : le RGPD et ePrivacy s'appliquent comme pour le pixel.
- Elle se justifie surtout si vous dépensez sur Meta et que vos conversions remontent mal.
C'est quoi la Conversion API de Meta, concrètement ?
Le pixel Meta se déclenche dans le navigateur du visiteur et envoie les événements (page vue, ajout au panier, achat) à Meta. La Conversion API fait la même chose, mais depuis votre serveur : votre système envoie directement les événements à Meta, sans dépendre uniquement du navigateur.
C'est un cas d'usage concret du server-side tracking. Plutôt que de tout confier au navigateur, vous faites passer une partie de la mesure par un canal que vous contrôlez. Le pixel et la CAPI cohabitent : le premier capte ce qui se passe côté client, la seconde sécurise l'envoi côté serveur.
Pourquoi le pixel seul ne suffit-il plus ?
Parce que le navigateur est devenu un terrain instable. Depuis mars 2020, Safari bloque par défaut tous les cookies tiers et supprime le stockage écrit côté client après 7 jours sans interaction (source : WebKit, « Full Third-Party Cookie Blocking and More », 24 mars 2020). En parallèle, près de 30 % des internautes utilisent un bloqueur de publicité, qui empêche une partie des tags de se déclencher (source : GWI via DataReportal, données 2025).
Résultat : une part des conversions ne remonte plus au pixel. Meta optimise alors sur des données incomplètes, et vos campagnes apprennent moins bien. La CAPI sert à recoller une partie de ce signal perdu, côté serveur.
Qu'est-ce que la CAPI change, et qu'est-ce qu'elle ne change pas ?
Ce qu'elle change : une mesure plus complète et plus stable, donc un meilleur signal envoyé à l'algorithme de Meta, et des décisions de campagne mieux informées.
Ce qu'elle ne change pas : vos obligations de consentement. Si un visiteur refuse le suivi publicitaire, vous ne devez pas lui envoyer d'événement, que ce soit par le pixel ou par la CAPI. Elle ne récupère pas non plus 100 % de ce qui est perdu, et elle ne se met pas en place toute seule proprement.
Pixel ou Conversion API : faut-il choisir ?
Non, et c'est le malentendu le plus fréquent. Meta recommande d'utiliser le pixel et la Conversion API ensemble, en envoyant les mêmes événements par les deux canaux, puis en les dédupliquant. Le pixel garde la finesse du navigateur, la CAPI apporte la résilience du serveur. La vraie question n'est pas de choisir un canal, c'est de bien dédupliquer pour ne pas compter deux fois.
Comment la mettre en place proprement ?
Trois points non négociables.
- La déduplication.
Quand le pixel et la CAPI envoient le même événement, Meta doit comprendre qu'il s'agit du même. Pour ça, chaque événement doit porter un identifiant partagé (event_id) identique côté navigateur et côté serveur, en plus d'un nom d'événement cohérent. Meta rapproche alors les deux et n'en garde qu'un (source : Meta for Developers, Conversions API, déduplication des événements pixel et serveur).
- Le consentement.
La CAPI doit respecter votre bandeau. On n'envoie d'événement, par quelque canal que ce soit, que pour les visiteurs qui ont accepté le suivi.
- La qualité des données.
Plus les paramètres envoyés sont complets et propres, mieux Meta rapproche les événements. Une CAPI alimentée avec des données pauvres apporte peu.
Côté mise en oeuvre, trois voies courantes : l'intégration directe (votre serveur appelle l'API de Meta), un conteneur Google Tag Manager côté serveur, ou un connecteur fourni par votre CMS ou votre plateforme. Le bon choix dépend de votre stack, pas d'un principe.
Quelles erreurs éviter ?
- Pas de déduplication. Sans event_id partagé, chaque conversion remonte deux fois, ce qui gonfle vos chiffres et fausse l'optimisation (source : Meta for Developers).
- Suivre sans consentement. La CAPI n'est pas une porte dérobée au RGPD. Toute promesse de tout récupérer malgré le refus est un drapeau rouge.
- Des données de mauvaise qualité envoyées au serveur, qui n'améliorent pas le rapprochement.
- Poser la CAPI sans cadrer la mesure d'abord. Si votre plan de mesure est flou, la CAPI ne le réparera pas.
Notre recommandation
Chez Skyrocket, on traite la CAPI comme ce qu'elle est : un cas d'usage du server-side tracking, pas un projet à part. Si vous dépensez sérieusement sur Meta et que vos conversions remontent mal, le couple pixel plus CAPI bien dédupliqué en vaut la peine, à condition de respecter le consentement et de soigner la qualité des données. Si votre mesure n'est pas encore cadrée, commencez par là : un audit dit ce qui manque vraiment, et la CAPI vient ensuite, à sa place. Le but n'est pas d'envoyer plus d'événements, c'est d'envoyer les bons, proprement.
Vous voulez fiabiliser votre mesure Meta ?
On commence par un audit de tracking qui dit où vous perdez du signal et ce qu'il faut corriger en priorité, CAPI comprise.