L’API de conversions est le canal serveur d’envoi d’événements vers Meta, à côté du pixel installé dans le navigateur. Ce guide reprend ce que la documentation Meta décrit précisément : le rôle de l’API, la façon dont les événements serveur sont traités, les deux méthodes de déduplication avec le pixel, les prérequis de mise en place et les paramètres d’un événement. Pour le contexte plus large de la plateforme, voir notre rubrique Meta Ads et nos guides tracking et mesure.

Le rôle de l’API de conversions selon Meta

Meta définit l’API de conversions comme une connexion entre les données marketing d’un annonceur et les systèmes Meta. Les données peuvent provenir du serveur de l’annonceur, de sa plateforme de site web, de son application mobile ou de son CRM. Cette connexion sert trois objectifs énoncés par Meta : optimiser le ciblage publicitaire, réduire le coût par résultat et mesurer les résultats (Meta).

Second élément mis en avant par la documentation : la mutualisation. Un annonceur peut utiliser l’API de conversions pour envoyer plusieurs types d’événements et réduire le nombre d’intégrations séparées à maintenir (Meta).

Analyse de Trafic Manager : pour une équipe qui gère plusieurs sources de conversion (site, application, appels, ventes CRM), cette mutualisation réduit la surface à documenter et à monitorer : une intégration au lieu d’une par canal.

Comment les événements serveur sont traités

Les événements serveur sont rattachés à un dataset ID. Meta indique qu’ils sont ensuite traités de la même manière que les événements envoyés via le Meta Pixel, le SDK Facebook pour iOS ou Android, un SDK de partenaire de mesure mobile, un offline event set ou un import CSV (Meta).

La documentation précise également que ces événements serveur peuvent être utilisés pour la mesure, le reporting ou l’optimisation, de façon similaire aux autres canaux de connexion (Meta).

Analyse de Trafic Manager : un événement envoyé par le serveur alimente donc le même circuit que le pixel, y compris pour l’optimisation. La qualité de sa charge utile (nommage, horodatage, paramètres) mérite la même rigueur que celle du tracking navigateur.

Déduplication : deux méthodes, une fenêtre de 48 heures

Quand le pixel et l’API envoient le même événement, Meta documente deux méthodes de déduplication.

Méthode event_id et event_name

Pour des événements correspondants, l’eventID du Meta Pixel doit correspondre à l’event_id de l’API de conversions, et l’event du pixel doit correspondre à l’event_name de l’API de conversions (Meta). Côté navigateur, l’eventID est le quatrième argument de l’appel fbq track (Meta).

La fenêtre est explicite : si Meta retrouve la même combinaison serveur (event_id et event_name) et la même combinaison navigateur (eventID et event) envoyées au même Pixel ID dans un intervalle de 48 heures, les événements suivants sont écartés (Meta).

Quand l’événement serveur et l’événement navigateur ne diffèrent pas significativement dans leur contenu, Meta privilégie généralement celui reçu en premier (Meta).

Méthode event_name avec fbp et/ou external_id

Une seconde méthode repose sur event_name associé à fbp et/ou external_id, utilisés de façon cohérente entre les événements navigateur et serveur. Meta signale une limite de ce mécanisme : un événement serveur n’est pas écarté si aucun événement navigateur n’a été reçu dans les 48 heures précédentes, même si un événement navigateur identique arrive après l’événement serveur (Meta).

Analyse de Trafic Manager : cette asymétrie a une conséquence directe sur l’ordre d’envoi. Si votre implémentation déclenche systématiquement l’événement serveur avant l’événement navigateur, la méthode fbp/external_id ne vous protège pas du doublon. Renseigner un event_id partagé entre les deux canaux reste la voie la plus contrôlable, puisque c’est la seule clé que vous définissez vous-même de bout en bout. Notez aussi que la documentation décrit le rejet des doublons dans une fenêtre de 48 heures et ne dit rien du traitement au-delà : un rejeu plus ancien sort de ce cadre.

Prérequis avant la mise en place

Deux prérequis sont énoncés par Meta. Un Pixel ID est obligatoire pour utiliser l’API de conversions (Meta). Un compte Meta Business Suite est également nécessaire (Meta).

Analyse de Trafic Manager : si un pixel est déjà en place sur le site, utilisez le même identifiant pour les événements navigateur et pour les événements serveur. La règle de déduplication documentée par Meta s’applique aux événements envoyés au même Pixel ID : deux identifiants distincts placent mécaniquement les deux canaux hors du périmètre de déduplication.

Si votre architecture de collecte passe par un conteneur serveur, la logique d’envoi côté serveur est traitée dans notre guide GTM server-side.

Générer le jeton d’accès

Meta décrit la méthode recommandée de génération du jeton : ouvrir l’onglet Paramètres du pixel concerné dans Events Manager, repérer la section API de conversions, puis utiliser le lien de génération de jeton d’accès sous « Set up manually » (Meta).

La documentation signale aussi ce qui se produit depuis l’onglet Overview : cliquer sur « Manage » à côté de l’API de conversions crée automatiquement une application API de conversions et un utilisateur système dédié à l’API de conversions (Meta).

Analyse de Trafic Manager : notez cette création automatique dans votre documentation interne. L’application et l’utilisateur système apparaissent dans les paramètres du Business Manager sans avoir été créés à la main, et un audit d’accès ultérieur doit pouvoir les rattacher à cette action.

Les paramètres d’un événement serveur

Parmi les paramètres documentés, cinq sont à cadrer en priorité.

event_name est requis. Il s’agit d’un nom d’événement standard ou personnalisé, et ce champ sert à dédupliquer les événements envoyés à la fois par le web et par l’application (Meta).

event_time est requis. C’est un timestamp Unix en secondes indiquant le moment où l’événement s’est réellement produit. La documentation fixe un âge maximum de 7 jours avant l’envoi (Meta).

action_source est requis. Ce champ permet de préciser où la conversion a eu lieu, avec les valeurs email, website, app, phone_call, chat, physical_store, system_generated, business_messaging et other (Meta).

event_id est marqué optionnel dans la documentation, mais Meta le recommande pour la déduplication des événements. Il peut s’agir de n’importe quelle chaîne unique choisie par l’annonceur, par exemple un numéro de commande ou un identifiant de transaction (Meta).

event_source_url est listé comme optionnel dans le tableau de référence, mais la documentation précise qu’il est requis pour les événements de site web partagés via l’API de conversions, et que l’URL doit correspondre au domaine vérifié (Meta).

Checklist de mise en place

  1. Récupérer le Pixel ID existant et l’utiliser pour les événements navigateur et serveur.
  2. Vérifier l’accès à Meta Business Suite.
  3. Générer le jeton d’accès depuis l’onglet Paramètres du pixel dans Events Manager, section API de conversions.
  4. Définir la convention de nommage des événements, en alignant event_name côté serveur et event côté pixel.
  5. Générer un identifiant unique par événement métier et l’envoyer en event_id côté serveur et en eventID côté pixel.
  6. Renseigner event_time en timestamp Unix en secondes, au moment réel de l’événement, et rester sous les 7 jours d’ancienneté.
  7. Renseigner action_source avec la valeur correspondant à l’origine réelle de la conversion.
  8. Pour les événements web, renseigner event_source_url avec une URL du domaine vérifié.
  9. Contrôler que les deux canaux envoient bien vers le même identifiant, puisque la déduplication s’appuie sur le même Pixel ID dans une fenêtre de 48 heures.