Consultant Meta CAPI : Conversions API server-side et matching premium

Meta Conversions API (CAPI) est l’endpoint serveur officiel pour envoyer les conversions à Meta — la voie qui ne dépend plus du cookie navigateur, donc qui survit à Safari ITP, aux bloqueurs, et au Consent Mode v2. Un déploiement CAPI propre demande trois choses : envoi des events depuis le serveur (idéalement via sGTM), hashing SHA-256 des données utilisateur (email, téléphone, nom), et dédup event_id stricte avec les conversions client-side du pixel Meta. Sans ces trois conditions, le matching reste médiocre et l’algo Meta apprend mal. Mon forfait Meta CAPI standalone : 3 800 € HT pour ~6 jours, ou inclus dans le forfait sGTM complet à 6 500 € HT.

Pourquoi le Meta Pixel seul ne suffit plus

Trois forces qui rendent le pixel Meta client-side de moins en moins fiable.

Safari ITP. Le navigateur le plus important sur mobile premium (iPhone) bloque les cookies tiers de Meta et raccourcit la durée des cookies first-party Meta. Sur un site dont 35 % du trafic est sur Safari iOS, c’est mécaniquement 10-15 % de conversions perdues côté Meta sans envoi server-side.

Bloqueurs publicitaires. uBlock, AdBlock Plus, Ghostery, Brave bloquent les requêtes vers facebook.com et connect.facebook.net. Selon le secteur (tech : 25 %+, généraliste : 5-8 %), le pixel client-side n’arrive pas chez Meta.

Consent Mode v2 et refus utilisateur. Quand l’utilisateur refuse les cookies marketing, le pixel Meta est bloqué et la conversion est perdue. Le CAPI server-side avec consentement aux données serveur (que l’utilisateur peut accepter même s’il refuse les cookies front) récupère une partie des conversions.

Les trois piliers d’un déploiement CAPI propre

Pilier 1 — Envoi server-side via sGTM

Le pixel Meta client continue d’exister (pour le retargeting cookies, l’attribution sur Safari quand consent accepté). Le CAPI server-side est ajouté en parallèle pour les events de conversion (Purchase, Lead, InitiateCheckout, AddToCart).

Architecture : le navigateur envoie l’event au sGTM (votre propre sous-domaine), le sGTM transforme et envoie au CAPI Meta. L’event part avec ses paramètres event_id, event_time, event_source_url, user_data (hashé), custom_data (valeur, currency, items).

Détails techniques dans la page consultant sGTM.

Pilier 2 — Hashing SHA-256 des PII

Meta exige que les données utilisateur (email, téléphone, prénom, nom, ville, code postal, pays) soient hachées en SHA-256 avant envoi. Le hashing doit se faire côté serveur, jamais côté client en clair — sinon les PII transitent en clair sur le réseau et c’est une violation RGPD.

Implémentation : le navigateur envoie le hash déjà calculé au sGTM, OU le sGTM reçoit l’email en clair via une connexion HTTPS et hache lui-même avant transmission à Meta. La seconde option est généralement plus simple et permet aussi le re-hash si Meta change ses spec.

Champs à hasher : em (email), ph (téléphone E.164), fn (prénom), ln (nom), ct (ville), st (région/département), zp (code postal), country. Plus le external_id si vous avez un identifiant utilisateur stable (user_id de votre app).

Pilier 3 — Dédup event_id stricte

L’event Purchase est envoyé deux fois (par le pixel client ET par le CAPI server). Sans event_id commun, Meta compte deux fois. La dédup repose sur un event_id unique par transaction, partagé entre client et serveur.

Implémentation type : le transaction_id métier (ID commande Shopify, ID lead HubSpot) sert d’event_id. Il est poussé dans le dataLayer côté client, lu par le pixel Meta client (paramètre eventID), et lu par le sGTM pour le push CAPI (paramètre event_id). Meta dédoublonne automatiquement quand les deux events ont le même event_id.

Validation : dans Business Manager Meta → Events Manager → votre pixel → Test events. Vous devez voir l’event arriver une fois “Browser” + une fois “Server”, marqué “Deduplicated”. Si c’est marqué comme deux events séparés, la dédup ne marche pas.

Comment mesurer la qualité du CAPI

Meta fournit un indicateur Event Match Quality (EMQ) dans Events Manager — un score de 1 à 10 par event. Objectif : EMQ supérieur à 8/10 pour avoir une bonne qualité de matching et que l’algo optimise correctement.

EMQ	Interprétation	Action
9-10	Excellent	Maintenir, surveiller la stabilité
7-8	Good	OK pour la majorité des cas, possibilité d’optimiser
5-6	Fair	Anormal, audit nécessaire
1-4	Poor	Critique, le CAPI est mal câblé

Sur les missions que je livre, la cible est EMQ entre 8 et 10. Si l’audit en cours de mission révèle un EMQ Fair ou Poor sur un site qui pensait être OK, c’est souvent un de ces trois problèmes : (a) hashing manquant ou mal fait, (b) dédup absente, (c) fbc/fbp non transmis du client au serveur.

Cas concret

E-commerce Shopify ~10 M€ de CA (mode/lifestyle). Pixel Meta client-side seul, EMQ 4/10 (Fair). Mission : déploiement CAPI server-side via Stape, hashing SHA-256 côté serveur sur 6 champs (em, ph, fn, ln, ct, zp), dédup event_id basée sur le transaction_id Shopify, push des events ViewContent, AddToCart, InitiateCheckout, Purchase. Effort 6 jours sur 3 semaines.

Résultat 30 jours après livraison : EMQ passé de 4 à 9/10. +19 % de conversions Meta remontées et attribuées. ROAS Meta modélisé qui repasse au-dessus du seuil de rentabilité, autorisation budgétaire d’augmenter la dépense Meta de 40 % validée par la direction.

Foire aux questions

CAPI est-il obligatoire ?

Non au sens légal, mais c’est devenu indispensable au sens opérationnel. Sans CAPI, vous perdez 15 à 30 % de conversions sur Meta dans la majorité des secteurs. L’algo Meta n’arrive plus à optimiser correctement, le CPA mesuré explose, le budget se réduit, vous perdez du business.

Faut-il garder le pixel Meta client-side en parallèle ?

Oui — pour deux raisons : (a) le pixel client envoie le fbc (Facebook Click ID) au sGTM qui le transmet au CAPI pour le matching, (b) le pixel client gère le retargeting Custom Audiences qui ne peut pas être exclusivement server-side. Pixel client + CAPI server est la combinaison standard, pas l’un OU l’autre.

Le RGPD permet-il d’envoyer ces données à Meta ?

Oui, sous condition de consentement explicite de l’utilisateur (catégorie marketing) et avec hashing des PII. Le DPA Meta (Data Processing Agreement) doit être signé. Sur les sites européens, je recommande aussi d’auditer les transferts internationaux (Meta est un sous-traitant US) avec votre DPO.

Et les autres plateformes (TikTok, Pinterest, LinkedIn, Microsoft) ?

Toutes ont leur Conversions API server. TikTok Events API, Pinterest Conversions API, LinkedIn Conversions API, Microsoft UET server-side. La méthode est similaire : envoi server-side via sGTM, hashing PII, dédup avec les pixels client. Sur les missions e-commerce, je déploie généralement Meta CAPI + Google Enhanced Conversions ; sur les missions lead gen B2B, j’ajoute LinkedIn CAPI ; sur TikTok et Pinterest, dépend du mix campagne.