Forwarder les conversions vers Meta CAPI via les liens courts Elido

Le propre guide de Meta, publié sur la page de démarrage de l'API Conversions (consultée le 2026-05-12), présente le pixel navigateur comme un complément à CAPI, pas l'inverse. Ce changement s'est produit autour d'iOS 14.5 : App Tracking Transparency a coupé la qualité du signal de Meta, ITP en a mangé une autre tranche, et les installations d'ad-blockers ont continué à grimper. D'ici 2026, les équipes faisant tourner des pubs Meta contre des audiences fortement iOS voient régulièrement disparaître 30-40 % des événements de conversion avant qu'ils n'atteignent le reporting.

CAPI est le canal côté serveur qui contourne tout cela. Votre serveur parle directement à l'API graph de Meta. ITP ne s'applique pas. Les ad-blockers n'interceptent pas. Le taux de correspondance monte parce que vous pouvez envoyer email et téléphone hachés à côté de l'identifiant de clic ; comme les événements navigateur et serveur partagent une clé de dedup, Meta compte la conversion une seule fois même quand les deux chemins se déclenchent.

Ceci est le pas-à-pas pour câbler CAPI via les liens courts d'Elido. L'aperçu du tracking de conversion côté serveur couvre l'architecture plus large (GA4, TikTok, Mixpanel, sémantique de retry). Le tutoriel UTM de bout en bout vaut la peine d'être lu d'abord si votre étiquetage de campagne est encore informel.

TL;DR#

• Meta Pixel perd 30-40 % des événements de conversion sur le trafic fortement iOS à cause d'ITP et des ad-blockers ; CAPI envoie ces événements directement depuis votre serveur, récupérant la majeure partie de l'écart.
• La clé de déduplication - event_id - doit être identique entre votre pixel côté navigateur et votre événement CAPI. Manquer cela cause un double-comptage, ce qui casse l'allocation budgétaire d'optimisation de Meta.
• Une densité plus élevée de clés de correspondance (email haché, téléphone, ID de clic fbc, cookie fbp) améliore directement le taux de correspondance d'attribution ; Elido capture fbclid au moment du clic et l'associe à chaque conversion en aval.
• La validation prend environ 10 minutes : Meta Events Manager a un panneau Test Events qui montre les événements CAPI arrivant dans les 30 secondes, bien avant que le dashboard de taux de correspondance à 24 heures ne se remplisse.

Ce dont vous avez besoin avant de commencer#

Trois choses, toutes depuis Meta Business Manager.

ID du pixel. Chaque compte publicitaire Meta a au moins un pixel. Trouvez-le dans Events Manager sous Data Sources. La chaîne numérique - quelque chose comme 1234567890 - est ce que vous collerez dans les paramètres d'intégration d'Elido.

Token d'accès System User. C'est l'identifiant qui autorise Elido à écrire des événements vers votre pixel. Naviguez vers Business Settings, puis Users, puis System Users. Créez un system user avec accès Standard, assignez-le au pixel (Manage permissions), et générez un token avec les scopes ads_management et business_management. Le token est à longue durée de vie ; tournez-le quand vous tournez d'autres identifiants de service, pas sur un planning. Stockez-le comme secret de workspace - pas dans le code source, pas dans une feuille de calcul.

Pattern d'URL source d'événement. Chaque événement CAPI porte un event_source_url qui dit à Meta sur quelle page la conversion s'est produite. Pour les événements d'achat, c'est typiquement votre URL de confirmation de checkout. Pour les événements de lead, c'est la page de soumission du formulaire. Vous ne hardcodez pas ceux-ci ; ils viennent de votre webhook de commande ou du contexte de requête de votre backend au moment de la conversion.

Les clés de correspondance : pourquoi la densité compte#

Meta déduplique et fait correspondre les événements serveur aux sessions navigateur en utilisant un ensemble de paramètres d'information client. Plus vous en envoyez, plus le taux de correspondance est élevé. Un taux de correspondance plus élevé signifie plus de conversions attribuées à vos campagnes, ce qui signifie que l'algorithme d'optimisation a un meilleur signal, ce qui signifie un meilleur ROAS. La relation est directe.

Les quatre clés qui comptent le plus :

em (email haché SHA-256). Le signal de plus haute valeur. Si vous avez l'email du client au moment de la conversion (vous l'avez presque toujours pour l'ecommerce), envoyez-le. La référence des paramètres d'information client Meta (consultée le 2026-05-12) spécifie les règles de normalisation : minuscules, trim des espaces de début/fin, pas de modifications au domaine. Hachez la chaîne normalisée. Envoyer [email protected] haché directement produit la mauvaise valeur ; [email protected] est ce qu'il faut hacher.

ph (téléphone haché SHA-256). Même discipline de normalisation. Format E.164 : indicatif pays, pas d'espaces, pas de tirets, pas de parenthèses. +4915123456789 se hache vers quelque chose que Meta peut faire correspondre ; 015123456789 non.

fbc (Facebook click ID). Quand un utilisateur clique sur une pub Meta, l'URL de destination reçoit un paramètre de requête fbclid. Votre landing page ou le handler de redirection Elido le lit et le stocke. Le champ fbc est construit à partir de cela : fb.{version}.{creationTime}.{fbclid}, où la version est 1 et le temps de création est le timestamp Unix en millisecondes. Elido capture le fbclid depuis l'URL de redirection au moment du clic et le stocke contre l'enregistrement de clic. Quand vous POSTez une conversion avec un click_id, la valeur fbc est déjà attachée et est forwardée automatiquement.

fbp (cookie Facebook browser pixel). C'est le cookie _fbp que le JS Meta Pixel pose sur votre domaine. C'est un cookie first-party du point de vue de votre domaine. Votre serveur le lit dans les en-têtes de requête au moment du checkout et l'inclut dans la charge utile de conversion. Sans lui, le taux de correspondance de Meta pour le chemin de repli côté navigateur se dégrade.

L'ordre de priorité pratique : em d'abord (presque toujours disponible), fbc ensuite (Elido le fournit pour les conversions provenant de clics), fbp troisième (lu depuis le cookie sur la page de confirmation), ph en dernier (souvent non capturé). Une charge utile avec em + fbc correspondra significativement mieux qu'une sans rien.

Câblage dans Elido#

L'intégration vit dans Workspace Settings, sous /integrations, puis Meta CAPI.

Collez votre ID de pixel et token d'accès System User. Elido valide le token contre l'API graph de Meta immédiatement - un 400 ici signifie que le token est mal formé ou manque des scopes requis ; vérifiez les permissions du system user avant de continuer. Une fois validée, l'intégration est active pour le workspace. Tous les liens trackés du workspace participent ; il n'y a pas de bascule par lien.

Quand un lien tracké est cliqué, le handler edge d'Elido lit le fbclid depuis la query string (si présent) et l'écrit dans l'enregistrement de clic. Cela se produit à la couche de redirection, avant que l'utilisateur n'atteigne votre site, donc la capture est fiable indépendamment de si le JavaScript de votre site de destination tourne.

Quand un événement de conversion se déclenche, POSTez-le à /v1/conversions :

curl -X POST \
  https://api.elido.app/v1/conversions \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -d '{
    "click_id":   "clk_01HYZ7T8WV6KQX3M",
    "event_name": "Purchase",
    "event_id":   "ord_98231",
    "value":      89.50,
    "currency":   "EUR",
    "user": {
      "email":  "[email protected]",
      "phone":  "+4915123456789"
    }
  }'

À la réception, Elido cherche l'enregistrement de clic, lit le fbclid stocké pour construire fbc, normalise et hache email et phone, assemble la charge utile CAPI complète, et POSTe à https://graph.facebook.com/v21.0/{pixel_id}/events. L'appel API retourne un ID de conversion immédiatement ; le fan-out vers Meta est en arrière-plan et observable via GET /v1/conversions/{id}.

La charge utile CAPI brute qu'Elido construit ressemble à ceci :

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1747047600,
      "event_id": "ord_98231",
      "action_source": "website",
      "event_source_url": "https://shop.example.com/checkout/thanks?order=98231",
      "user_data": {
        "em": ["a3b6e2f4...sha256 of [email protected]"],
        "ph": ["c7d9f1a3...sha256 of +4915123456789"],
        "fbc": "fb.1.1747040000.AbCdEfGhIj",
        "fbp": "fb.1.1747040000.987654321",
        "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 ...)",
        "client_ip_address": "203.0.113.42"
      },
      "custom_data": {
        "currency": "EUR",
        "value": 89.5,
        "content_ids": ["sku-spring-jeans-32-blue"],
        "content_type": "product",
        "num_items": 1
      }
    }
  ],
  "access_token": "EAAxxxxxxx"
}

Les champs event_source_url et action_source sont dérivés de l'URL de destination de l'enregistrement de clic et du paramètre source de la requête de conversion (par défaut website). Si vous forwardez des conversions côté app, passez "source": "app" dans le corps POST.

Discipline de déduplication#

Lisez la documentation Meta sur la déduplication des événements (consultée le 2026-05-12) avant de toucher au trafic de production. La version courte est celle-ci : Meta fait correspondre les événements pixel navigateur et les événements CAPI en utilisant event_id + event_name dans une fenêtre de 48 heures. Si les deux événements portent la même paire, le second est silencieusement écarté.

L'exigence opérationnelle qui suit : l'événement Purchase de votre pixel côté navigateur et votre événement CAPI côté serveur doivent partager le même event_id. Le choix le plus fiable est votre ID de commande : les deux côtés le voient, il est stable, il n'est pas regénéré à la nouvelle tentative.

Là où cela casse en pratique : le serveur génère un UUID au moment du forward au lieu d'utiliser l'ID de commande. Ou le pixel navigateur utilise un schéma d'ID (ord_98231) et le backend en utilise un autre (order-98231). Les deux événements sont ingérés. Aucun n'est dédupé. Vos conversions rapportées doublent. L'algorithme de Meta sur-alloue le budget à la campagne en se basant sur des chiffres gonflés. La revue de budget trois semaines plus tard révèle « notre ROAS est étrangement à 2,5× notre revenu réel » et les forensiques sont désagréables.

Le diagramme de séquence ci-dessous montre comment l'event_id traverse le système :

L'appel pixel côté navigateur se produit côté client quand la page de confirmation se charge. Le forward CAPI côté serveur se produit quand votre webhook de commande se déclenche. Les deux doivent émettre event_id: ord_98231 (ou quel que soit votre identifiant de commande). L'écart de timing entre les deux est sans importance tant que les deux arrivent dans 48 heures.

Si vous ne faites pas tourner de pixel côté navigateur (retiré pour des raisons de consentement RGPD, ou parce que votre audience est entièrement ad-blocker-lourde), la déduplication est sans objet. Envoyez CAPI seul. Mais la plupart des équipes font tourner les deux ; le pixel navigateur fournit un signal de repli pour les utilisateurs où les événements CAPI ne peuvent pas porter de clés de correspondance (pas d'email capturé, pas de fbclid).

Validation#

La boucle de validation est courte et devrait se produire avant que tout trafic de production ne circule.

Étape un : définissez un code d'événement de test. Dans les paramètres de l'intégration Meta CAPI d'Elido, il y a un champ de code d'événement de test. Obtenez un code depuis Meta Events Manager sous Test Events. Collez-le. Tant que ce code est défini, chaque événement CAPI qu'Elido envoie est routé vers le panneau de test - il n'entre jamais dans le reporting de production.

Étape deux : déclenchez une conversion de test. Cliquez sur l'un de vos liens trackés depuis un navigateur (cela capture le fbclid si l'URL du lien venait d'une pub Meta, ou d'un lien avec fbclid ajouté manuellement pour les tests). POSTez une conversion contre ce click_id avec un ID de commande réaliste, une valeur et une adresse email.

Étape trois : vérifiez Test Events. Dans Meta Events Manager, l'événement de test devrait apparaître dans les 30 secondes. Vérifiez que event_name correspond à ce que votre pixel navigateur envoie. Vérifiez que event_id est l'ID de commande, pas un UUID. Vérifiez que em, fbc, ou fbp apparaissent dans la section user_data - au moins une clé de correspondance devrait être présente.

Étape quatre : retirez le code d'événement de test. Une fois validé, videz le champ de code d'événement de test et enregistrez. Les événements de production commencent à circuler. Le dashboard de taux de correspondance dans Events Manager prend 24 heures à se remplir avec des données significatives.

Ce qu'il faut chercher à 24 heures : un taux de correspondance au-dessus de 60 % est fonctionnel ; au-dessus de 75 % est bon ; au-dessus de 85 % signifie que votre densité de clés de correspondance est élevée et l'attribution sera fiable. Si vous êtes en-dessous de 60 %, la cause la plus probable est l'absence de fbc (le fbclid n'était pas sur l'URL de landing) ou une erreur de normalisation du hachage.

Modes de panne courants#

event_source_url manquant. Les événements CAPI sans ce champ sont acceptés mais pénalisés dans la logique de correspondance de Meta. Le champ doit être l'URL de la page où la conversion s'est produite - votre URL de confirmation de checkout, votre page de landing de formulaire de lead, l'équivalent de votre app. Elido le dérive de l'URL de destination de l'enregistrement de clic quand non surchargé ; passez-le explicitement dans le POST de conversion si votre URL de confirmation diffère de la destination de redirection.

Clé hachée pas en minuscules-trim. [email protected] et [email protected] produisent des valeurs SHA-256 différentes. Les serveurs Meta hachent la forme canonique stockée dans leur graphe utilisateur. Si votre hash ne correspond pas, l'événement atterrit non-apparié. L'exigence de normalisation s'applique aussi aux numéros de téléphone : retirez les variations de formatage d'indicatif pays, forcez E.164. Router via l'endpoint /v1/conversions d'Elido signifie que la normalisation est gérée pour vous ; vous passez l'email et le téléphone bruts, Elido hache selon la spec.

Discordance action_source. Les conversions originant du web utilisent "action_source": "website". Les conversions mobile app utilisent "app". Si vous forwardez un achat qui s'est produit dans votre app iOS mais envoyez action_source: "website", le modèle d'attribution de Meta peut dégrader le signal. Passez "source": "app" dans le POST de conversion Elido pour les événements côté app.

fbc absent parce que fbclid n'était pas sur l'URL. Cela se produit quand l'URL de destination de la pub n'inclut pas fbclid - soit parce que la campagne n'a pas « Auto-advanced matching » activé, soit parce que l'URL a été construite à la main sans, soit parce que l'utilisateur est arrivé via un chemin de retargeting qui ne portait pas le paramètre. Quand fbc est manquant, la conversion forwarde quand même, mais le taux de correspondance descend à email/téléphone seulement. Vérifiez les paramètres de campagne dans Meta Ads Manager ; fbclid devrait apparaître sur les URL de destination pour les campagnes de trafic standard.

Schémas event_id doubles. Le pixel navigateur et l'événement CAPI utilisent des formats différents pour le même ID de commande. Cela arrive presque toujours quand différentes équipes possèdent la configuration tag manager du frontend et l'intégration webhook de commande du backend. Convenez d'un format canonique avant le lancement. ID de commande sous forme de chaîne (ord_98231) fonctionne. Numérique seulement aussi. Le pixel émettant "ord_98231" et le serveur émettant "98231" sont traités comme des événements différents : aucun n'est dédupé.

Un résultat élaboré#

Une marque ecommerce basée UE faisant tourner des pubs Meta vers l'Allemagne et l'Autriche a rapporté un taux de correspondance de 38 % avec le tracking pixel seul. Safari sur iOS représentait environ 45 % du trafic du site ; les taux d'opt-out ATT dans la démographie 25-44 tournaient autour de 72 %.

Après le câblage de CAPI via Elido avec em + fbc comme clés de correspondance primaires, le taux de correspondance a grimpé à 76 % dans la première semaine. fbc était maintenant présent sur chaque conversion provenant d'un clic de pub Meta (Elido capture fbclid à la couche de redirection, pas au niveau navigateur), et le forwarding d'email haché fournissait un second chemin de correspondance pour les conversions où le cookie _fbp avait expiré.

Le CPA a baissé de 18 % sur les quatre semaines suivantes. Le ROAS rapporté est passé de 2,1 à 2,6. La réduction de CPA de 18 % reflète une meilleure attribution, pas une meilleure performance de campagne : les campagnes performaient toujours à 2,6 ROAS ; le pixel seul sous-rapportait.

Où cela se situe dans le pipeline d'attribution#

CAPI est un canal dans une configuration plus large de forwarding côté serveur. L'aperçu du tracking de conversion côté serveur couvre GA4 Measurement Protocol et TikTok Events API avec la même profondeur que ce billet applique à Meta. L'attribution sans cookies expliquée vaut la peine d'être lue si vous voulez le pourquoi sous-jacent - ITP, link tracking protection, et les changements du modèle d'attribution qui ont suivi.

Pour la surface produit : les fonctionnalités de tracking de conversion documentent l'API complète, y compris les événements de remboursement, les modes d'attribution multi-touch, et la sémantique retry/backoff. Solutions pour les marketeurs montre comment les pièces s'assemblent dans un flux de campagne.

La configuration décrite ci-dessus est réalisable en une matinée. L'investissement principal est en temps à la validation - 30 minutes dans Meta Test Events avant de basculer le trafic de production. Ces 30 minutes en valent la peine ; l'alternative est de découvrir une mauvaise configuration trois jours plus tard quand l'algorithme a déjà agi sur les mauvais chiffres.

Sources

• Meta Conversions API: Getting Started. developers.facebook.com/docs/marketing-api/conversions-api/get-started/ (consultée le 2026-05-12)
• Meta Conversions API: Deduplicate Pixel and Server Events. developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/ (consultée le 2026-05-12)
• Meta Conversions API: Customer Information Parameters. developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/ (consultée le 2026-05-12)