La rédaction en direct
Base de connaissances14 min de lecture

Meta CAPI pour affiliés : configuration et déduplication

Comment fonctionne la Meta Conversions API quand la conversion a lieu sur le site d'un opérateur : postback vers la CAPI, pièges de déduplication par event_id, qualité de match et configuration.

Two identical blue badges on felt, tweezers lifting one away

La Meta Conversions API (CAPI) est le canal serveur à serveur de Meta pour les événements de conversion. Votre tracker ou votre serveur envoie une inscription ou un dépôt directement à Meta, si bien que l'optimisation ne dépend pas du déclenchement d'un pixel navigateur sur une page que vous contrôlez. Pour les affiliés, dont les conversions ont lieu sur le site d'un opérateur, c'est souvent le seul moyen de les remonter.

Ce guide couvre ce cas : vous possédez la publicité et la landing page, l'opérateur possède l'inscription et la caisse, et la conversion vous parvient sous forme de postback.

Qu'est-ce que la Meta Conversions API

Meta décrit la Conversions API comme une connexion entre les données marketing d'un annonceur et les systèmes de Meta. Les données peuvent provenir d'un serveur, d'une plateforme de site web, d'une application mobile ou d'un CRM, et couvrir des événements de site web, des événements d'application, des événements de messagerie professionnelle et des conversions hors ligne.

Elle s'appelait auparavant Facebook Conversions API, et avant cela Server-Side API. « Facebook conversion API », « conversion API Meta » et « CAPI » désignent tous le même endpoint de la Marketing API de Meta.

Deux termes comptent pour la configuration :

  • Dataset. Les événements serveur sont rattachés à un ID de dataset dans Events Manager. Le dataset contient aussi votre Meta Pixel, et Meta vous demande d'utiliser le même Pixel ID pour les événements navigateur et serveur.

  • Événements hors ligne. Meta range les conversions hors ligne parmi les données que transporte la Conversions API ; la « Meta offline conversions API » est donc documentée au même endroit.

Comment fonctionne la CAPI pour les affiliés

Un funnel d'affiliation traverse deux domaines, dont un seul vous appartient ; votre tracker relaie donc chaque conversion vers Meta :

  1. Clic. Un utilisateur clique sur votre publicité. Meta ajoute un paramètre fbclid à l'URL de la landing page.

  2. Le tracker enregistre le clic. Il stocke son propre click ID avec le fbclid, l'adresse IP du visiteur, son user agent et l'horodatage, puis transmet le click ID au lien de l'opérateur comme sub-ID.

  3. Conversion sur le site de l'opérateur. Le joueur s'inscrit et effectue un premier dépôt. L'opérateur enregistre les deux sous votre sub-ID.

  4. Postback. Le système de l'opérateur appelle votre tracker avec le sub-ID et le type d'événement. Notre guide du tracking par postback explique comment cet appel est construit.

  5. Le tracker appelle Meta. Le tracker retrouve le clic stocké, convertit le fbclid en la valeur fbc attendue par Meta (un préfixe fb., un index de sous-domaine, un horodatage de création et le fbclid, séparés par des points) et envoie l'événement avec son nom, son heure, son ID et les données utilisateur.

  6. Meta tente le matching. Meta cherche la personne qui a vu la publicité ou cliqué dessus ; les conversions matchées apparaissent dans les rapports et alimentent la diffusion.

Le point faible, c'est l'étape 2. Meta accepte toujours un événement issu d'un clic enregistré sans son fbclid, mais n'a pas grand-chose pour le matcher, sauf si vous envoyez aussi des données de contact.

Meta Pixel vs Conversions API

Le Pixel s'exécute dans le navigateur du visiteur et remonte ce qui se passe sur cette page. La CAPI est une requête que votre propre système envoie dès qu'il a connaissance d'une conversion, où qu'elle ait eu lieu.

Meta PixelConversions API
Se déclenche depuisLe navigateur, sur une page que vous contrôlezVotre tracker ou serveur
Principal point de défaillanceBloqueurs de publicité, limites de confidentialité du navigateur, choix de consentementClick IDs perdus ou données incomplètes que vous envoyez
Inscriptions et dépôts sur le site de l'opérateurInvisiblesRemontés via le postback
Données du visiteurCookies, IP et user agent ajoutés automatiquementUniquement ce que vous envoyez, IP et user agent compris
Ce qu'il vous fautDu code ou une balise sur vos pagesUne intégration au tracker et un access token, ou l'option en un clic de Meta pour les événements web
DéduplicationInutile s'il est seulNécessaire quand les deux remontent le même événement

La page de bonnes pratiques de Meta recommande d'utiliser la Conversions API en plus du Pixel et de partager les mêmes événements par les deux. Les affiliés doivent adapter ce conseil, car le Pixel ne voit pas les événements qui rapportent.

Meta Pixel ou Conversions API : de quoi avez-vous besoin ?

La plupart des affiliés iGaming ont besoin des deux : le Pixel pour le comportement sur la page, la CAPI pour les inscriptions et les dépôts. La question décisive est de savoir où la conversion est enregistrée.

  • Sur le site de l'opérateur. C'est le cas de la majeure partie du trafic d'affiliation casino et paris sportifs. Le Pixel ne voit que vos pages ; sans la CAPI, vous optimisez donc sur les clics sortants, et Meta apprend à trouver des gens qui cliquent plutôt que des gens qui déposent.

  • Trafic surtout iPhone et Safari. Les limites de confidentialité du navigateur réduisent la durée de vie des cookies et ce qu'un pixel peut remonter ; le signal serveur pèse donc davantage.

  • Volume élevé. Chaque événement manquant est un signal que le système de diffusion ne reçoit jamais, et la diffusion s'appuie sur ce signal, comme l'explique notre guide sur Meta Andromeda.

  • Un petit test sur un formulaire qui vous appartient. Si le lead est capté en une seule étape sur votre propre page, le Pixel seul suffit pour démarrer. Ajoutez la CAPI une fois que le test a mérité un budget.

Un media buyer qui diffuse des offres iGaming sur Meta tombe presque toujours dans le premier groupe.

Comment configurer la Conversions API avec un tracker

La configuration avec un tracker se fait en quatre étapes : dataset, méthode de connexion, événements et token, puis réglages du tracker et événement de test. Les écrans d'Events Manager changent ; vérifiez-les au fur et à mesure.

1. Choisissez ou créez le dataset

Il vous faut une Meta Business Suite et un Pixel ID. Dans Events Manager, connectez une source de données web ou réutilisez le dataset qui contient déjà votre Pixel. Connectez à ce dataset chaque compte publicitaire qui optimisera sur ces événements.

2. Choisissez la méthode de connexion

Le centre d'aide de Meta liste trois voies : une intégration partenaire, une option activée par Meta pour les événements web, et la configuration manuelle. Meta propose aussi une Conversions API Gateway, et certaines équipes utilisent le tagging côté serveur, par exemple un conteneur Google Tag Manager côté serveur.

Pour un tracker qui reçoit des postbacks d'opérateur, la configuration manuelle convient : les événements partent des postbacks, le tracker construit donc lui-même les requêtes. La Gateway, hébergée dans un compte cloud qui vous appartient, reçoit ses événements des navigateurs via le Pixel, pas du postback d'un opérateur. Un conteneur de balises côté serveur pourrait les accepter, mais il ferait double emploi avec le tracker.

3. Événements et access token

Sélectionnez uniquement les événements que vos postbacks peuvent réellement remonter. Un mapping courant est CompleteRegistration pour une inscription et Purchase pour un premier dépôt.

Générez l'access token dans Events Manager, dans la configuration manuelle. Seules les personnes disposant de privilèges de développeur dans l'entreprise voient ce lien. Meta crée alors pour vous une app et un utilisateur système Conversions API, sans App Review. Si vous utilisez déjà votre propre app, attribuez le Pixel à un utilisateur système existant dans Business Suite et générez le token à cet endroit.

Toute personne détenant le token peut envoyer des événements dans votre dataset. Conservez-le dans les réglages du tracker, jamais dans le code d'une page ni dans un tableur partagé, et remplacez-le quand une personne qui y avait accès s'en va.

4. Côté tracker et événements de test

Saisissez le Pixel ID et le token dans l'intégration Meta du tracker et associez chaque statut de postback à un nom d'événement. Vérifiez que le tracker stocke fbclid, IP et user agent au moment du clic, et qu'il envoie ces valeurs plutôt que l'IP de son propre serveur.

Chaque événement a aussi besoin de action_source, que Meta marque comme obligatoire ; pour un funnel web, la valeur habituelle est website. En utilisant l'API, vous acceptez que la valeur soit exacte à votre connaissance.

Pour les événements de site web, renseignez votre propre landing page dans event_source_url : Meta l'exige et indique que la valeur doit correspondre à votre domaine vérifié ; l'URL de l'opérateur n'a donc rien à y faire. Envoyez ensuite une conversion de test et vérifiez dans Events Manager qu'elle arrive, qu'elle est dédupliquée et qu'elle est matchée.

Déduplication : comment éviter les événements comptés deux fois

Meta compte un événement navigateur et un événement serveur comme une seule conversion quand l'eventID du Pixel est égal à l'event_id du serveur et que l'événement du Pixel est égal à event_name. Autour de cette correspondance :

  • Fenêtre de 48 heures. Meta ne déduplique que les événements reçus dans un délai de 48 heures ; une copie plus tardive avec le même ID est comptée à nouveau.

  • Le premier reçu l'emporte. Quand les deux copies ne diffèrent pas de manière significative, Meta conserve généralement celle qu'il a reçue en premier.

  • Une seconde méthode. Meta fait aussi correspondre sur event_name plus fbp et/ou external_id, utilisés de façon cohérente des deux côtés. En général, cela ne fonctionne que si l'événement navigateur est envoyé en premier ; un événement serveur sans événement navigateur dans les 48 heures précédentes est conservé.

  • Une seule source, pas de dédup. Meta ne déduplique pas un flux uniquement navigateur ou uniquement serveur. Deux événements serveur identiques sont conservés tous les deux.

Là où les configurations d'affiliés cassent :

  1. Un nom, deux actions. Le Pixel déclenche Lead quand un visiteur clique vers l'opérateur, et le tracker envoie Lead pour les inscriptions. Meta apprend désormais de deux actions différentes sous une même étiquette. Donnez à chaque action son propre nom.

  2. Des ID qui ne se rencontrent jamais. La page crée un event_id et le tracker un autre. La dédup exige le même nom d'événement et le même ID des deux côtés ; un écart sur l'un ou l'autre laisse deux événements. Si une action se déclenche vraiment aux deux endroits, générez l'ID une seule fois, au clic ou sur la page, et transmettez exactement cette valeur au Pixel et au postback.

  3. Postbacks tardifs. Les dépôts sont souvent confirmés plusieurs jours après le clic. Un postback qui arrive après 48 heures ne peut plus fusionner avec un événement navigateur antérieur ; les deux sont donc comptés. Gardez les événements de niveau dépôt uniquement côté serveur.

  4. Postbacks répétés. Les opérateurs renvoient des postbacks ou envoient des mises à jour de statut pour le même joueur. Les doublons uniquement serveur sont conservés ; le tracker doit donc envoyer chaque type d'événement une seule fois par clic.

  5. Événements périmés. event_time peut dater d'au plus sept jours. Si un événement d'une requête est plus ancien, Meta renvoie une erreur pour toute la requête et n'en traite rien ; envoyez donc les événements à mesure qu'ils arrivent au lieu de regrouper un arriéré en lots.

Ads Manager compte les conversions selon votre paramètre d'attribution ; il ne correspondra donc jamais exactement à un décompte de postbacks. En tenant compte de cela, comparez inscriptions et dépôts par campagne sur les mêmes quelques jours : un excédent persistant côté Meta signale des doublons, un déficit persistant des événements rejetés ou non matchés. Des événements gonflés ou inventés faussent l'optimisation et mettent le compte publicitaire en danger, et les opérateurs recherchent les mêmes schémas, comme l'explique notre guide sur la fraude à l'affiliation iGaming.

La CAPI en un clic de Meta et les postbacks du tracker

La documentation de Meta indique que, si vous avez un Pixel, vous pouvez configurer la Conversions API avec Meta pour les événements de site web en un clic, sans code, sans configuration et sans frais de mise en place. Elle repose sur votre Pixel et ne couvre que les événements de site web. Pour une boutique avec son propre checkout, c'est tout le funnel ; pour un affilié, c'est la landing page, et les inscriptions et dépôts sur le domaine de l'opérateur ne proviennent toujours que des postbacks du tracker.

Le risque, c'est le chevauchement. Meta ne fusionne les événements que selon les règles ci-dessus ; un événement du tracker avec son propre event_id ne fusionnera donc pas avec une copie basée sur le Pixel de la même action. Avant de l'activer à côté d'une intégration de tracker, donnez à chaque action un seul nom et un ID partagé, puis comparez le tracker avec Ads Manager pendant quelques jours.

Event Match Quality

L'Event Match Quality (EMQ) est un score sur 10 que Meta affiche par événement dans Events Manager. Il indique à quel point les informations client de vos événements serveur sont utiles pour le matching, et il ne couvre actuellement que les événements web. Selon Meta, envoyer davantage de paramètres d'informations client peut l'augmenter ; Meta cite en exemple l'e-mail, l'adresse IP, le nom et le numéro de téléphone.

Pour un affilié, les paramètres exploitables sont :

  • fbc, construit à partir du fbclid stocké. La clé la plus directement liée au clic sur la publicité.

  • fbp, le cookie navigateur du Pixel, si votre landing page le dépose et que le tracker le capte.

  • Adresse IP et user agent issus du clic. Le user agent est obligatoire pour les événements de site web.

  • E-mail et téléphone, uniquement si l'opérateur les transmet et que vos conditions le permettent.

La page de Meta sur les paramètres d'informations client fixe les règles de traitement. Normalisez les données de contact (e-mail sans espaces superflus et en minuscules, téléphone en chiffres avec l'indicatif du pays), puis hachez-les en SHA-256. IP, user agent, fbc et fbp sont envoyés non hachés. Les données de contact hachées restent des données personnelles ; n'envoyez donc que ce que votre politique de confidentialité et les conditions du programme vous autorisent à partager.

Publicités de jeux d'argent : ce que la CAPI ne change pas

La politique Online Gambling and Games de Meta n'autorise les publicités de jeux d'argent et de jeux qu'une fois que le compte publicitaire a obtenu l'autorisation de Meta. Cela inclut les publicités dont les landing pages font la promotion des jeux d'argent sans en proposer, et la politique cite en exemple les sites d'affiliation et les agrégateurs.

Les annonceurs demandent l'autorisation dans l'onglet Authorizations and Verifications de Meta Business Suite, avec la preuve que l'activité est sous licence ou légale à un autre titre là où ils veulent cibler. Avant de cibler pour la première fois une nouvelle juridiction, ils doivent déclarer cette intention. Les publicités autorisées ne peuvent pas cibler les moins de 18 ans ni les marchés que Meta liste comme non pris en charge. Pour les campagnes aux États-Unis, la légalité varie selon l'État, comme le montre notre panorama des jeux d'argent en ligne aux États-Unis.

Le tracking côté serveur mesure les résultats ; il n'autorise pas les publicités. Ceci est un résumé de la politique publiée par Meta en octobre 2026, et non un avis juridique.

Checklist avant lancement

Avant le lancement, vérifiez que chaque événement atteint Meta une seule fois, avec les données du clic, son propre nom et un ID partagé :

  • Chaque compte publicitaire qui optimise est connecté au dataset.

  • Le token se trouve uniquement dans le tracker.

  • Chaque événement transporte fbc, IP et user agent issus du clic, ainsi que action_source.

  • Chaque action a son propre nom d'événement. Là où le Pixel et le tracker la remontent tous les deux, ils envoient le même nom et le même event_id.

  • Le tracker envoie un événement par type et par clic, en temps réel.

  • event_source_url pointe vers votre domaine de landing page.

  • Un événement de test est arrivé et a été matché, et une comparaison régulière entre le tracker et Ads Manager est planifiée.

Questions fréquentes

Qu'est-ce que la Meta Conversions API (CAPI) ?

La Conversions API est l'API de Meta qui sert à envoyer des événements de conversion depuis vos propres systèmes, comme un serveur, un tracker ou un CRM, directement à Meta. La Facebook Conversions API est le même produit sous son ancien nom.

Comment suivre les conversions des publicités Meta sans pixel sur l'offre ?

Votre tracker stocke le fbclid de chaque clic publicitaire, transmet votre click ID à l'opérateur comme sub-ID et relaie le postback de l'opérateur vers la Conversions API avec les données de clic stockées.

Puis-je utiliser uniquement la CAPI, sans le Pixel ?

La CAPI fonctionne sans le Pixel, et pour les événements côté opérateur, c'est de toute façon ce que vous faites. Gardez tout de même le Pixel sur votre landing page : sans lui, il n'y a pas de cookie fbp que vos événements serveur puissent transporter comme clé de matching, et Meta conseille d'utiliser les deux.

Meta a-t-il une API, et la Conversions API est-elle gratuite ?

Oui : la Conversions API fait partie de la Marketing API de Meta. Meta présente l'option en un clic comme sans frais de mise en place. Une intégration directe coûte ce que coûte votre tracker, votre serveur ou votre outil partenaire.

Que se passe-t-il si j'active la CAPI en un clic en plus des postbacks du tracker ?

La CAPI en un clic couvre les événements de site web liés à votre Pixel, pas les conversions sur le site de l'opérateur. Le double comptage apparaît quand le Pixel et le tracker remontent la même action sous des ID ou des noms différents ; alignez-les d'abord, puis comparez le tracker avec Ads Manager.

Qu'est-ce que l'Event Match Quality et pourquoi est-ce important ?

L'Event Match Quality est le score sur 10 de Meta qui mesure dans quelle mesure les données client de vos événements serveur peuvent être associées à des personnes. Les événements impossibles à associer pèsent peu dans les rapports et l'optimisation.

Sources