Meta Ads CAPI
Guide technique pour les media buyers : le Full CAPI côté serveur, l'architecture sGTM, la déduplication, le consentement dans l'UE et le dépannage.
1Rôle et objectif
Meta CAPI (API Conversions) est la destination côté serveur qui remplace le pixel Meta du navigateur. Notre architecture est en Full CAPI : aucun pixel Meta ne tourne dans le navigateur.
Ce que cette configuration vous apporte :
- Un tracking 100 % côté serveur, via le sGTM
- Une conformité RGPD stricte (consentement demandé dans l'UE uniquement)
- Une attribution solide malgré les restrictions sur les cookies (ITP, bloqueurs de publicité)
- Une déduplication déterministe grâce à event_id
- Moins de dépendance aux pixels navigateur
- L'Advanced Matching (correspondance avancée) automatique, avec hachage SHA-256 côté serveur
Le système repose sur une source unique d'événements (le dataLayer de GTM Web), ce qui exclut tout doublon. Aucun événement ne part directement du navigateur vers Meta.
2Architecture à double envoi
L'architecture repose sur un double envoi (dual-send) : le navigateur pousse les événements dans le DataLayer, puis le serveur sGTM les transmet à Meta CAPI. Aucun pixel Meta ne tourne dans le navigateur : c'est du Full CAPI, 100 % serveur.
Flux de données complet
Navigateur (DataLayer)
|
GTM Web (Consent Mode + DataLayer)
|
Balise GA4 Config (transport technique)
|
Requête HTTP → domaine personnalisé du sGTM (first-party)
|
sGTM (serveur)
├── Client GA4 (reçoit la requête)
│ ├── GA4 Server Tag → Google Analytics 4
│ ├── META – CAPI – All Events → Meta Conversions API
│ └── GADS – Conv – purchase → Google Ads
│
└── Enrichissement côté serveur :
• Hachage SHA-256 automatique (e-mail, téléphone, adresse)
• Cookies d'attribution (fbp, fbc)
• event_id pour la déduplication
• Signaux Consent Mode v2 transmisPrincipes fondamentaux
- Aucun pixel Meta dans le navigateur : Full CAPI, 100 % serveur
- Jamais de double envoi client + serveur
- Une seule source : le dataLayer de GTM Web
- Consentement obligatoire avant tout tracking marketing
- GA4 sert uniquement de transport technique
- Cookies d'attribution conservés en first-party par Addingwell (cookie restore)
3Flux de données CAPI
Voici ce que Meta reçoit via CAPI, comparé à ce qu'enverrait normalement un pixel navigateur. En Full CAPI, tout passe par le serveur.
| Paramètre | Valeur |
|---|---|
| Mode | Full CAPI (serveur uniquement) |
| Balise sGTM | META – CAPI – All Events |
| Déduplication | event_id = transaction_id (purchase) |
| Cookies d'attribution | fbp + fbc (cookies first-party, conservés par le cookie restore) |
| Advanced Matching | SHA-256 automatique (e-mail, téléphone, adresse) |
| Transport du consentement | Signaux Consent Mode v2 transmis au serveur |
Données transmises par CAPI
Le serveur sGTM envoie à Meta :
- Nom de l'événement (PageView, ViewContent, AddToCart, InitiateCheckout, Purchase)
- ID de l'événement (pour la déduplication)
- Données utilisateur hachées : e-mail, téléphone, adresse (SHA-256)
- Attribution : fbp (identifiant du navigateur), fbc (identifiant de clic issu de fbclid)
- E-commerce : value, currency, content_ids, content_type, num_items
- URL serveur : action_source = "website"
Ce que CAPI ne reçoit PAS (par rapport à un pixel navigateur)
- Pas de cookie _fbp lu directement par le navigateur (GTM Web le lit et le transmet au serveur)
- Pas de PageView instantané au chargement (le serveur doit d'abord recevoir la requête GA4)
- Pas de retargeting dynamique via le pixel JS (utiliser les catalogues Meta à la place)
4Mise en garde sur le LPV (Landing Page View)
Limite du Full CAPI
Le taux de LPV (Landing Page Views / Link Clicks) est structurellement plus bas en Full CAPI : aucun pixel navigateur ne compte les vues de page à l'instant où elles ont lieu.
Le LPV ne reflète plus
Un vrai chargement de pixel dans le navigateur (il n'y a pas de pixel JS Meta)
Il reflète en revanche
Un signal estimé côté serveur (page_view via le sGTM)
Pourquoi le LPV est plus bas
Causes normales en Full CAPI :
- Navigation rapide (onglet fermé avant l'arrivée de la requête serveur)
- Consentement refusé (aucun événement envoyé)
- Bloqueurs de publicité (ils bloquent la requête de transport GA4)
- Départs rapides, avant la fin du chargement de la page
- Latence réseau entre le navigateur et le sGTM
Surveiller dans le Gestionnaire d'événements
Consultez Gestionnaire d'événements Meta > Diagnostics. Si le ratio LPV / Link Clicks passe sous 50 %, vérifiez que le transport sGTM répond bien en 200.
Ce que cela change pour les media buyers
Le taux de LPV ne doit pas servir à juger la qualité du trafic ni à optimiser les campagnes. Appuyez-vous plutôt sur les métriques de conversion (Purchase, ATC).
5EMQ (Event Match Quality)
L'Event Match Quality (EMQ) est le score qui indique à quel point les événements serveur correspondent bien à des utilisateurs Meta. Un score élevé est indispensable pour l'attribution et l'optimisation des campagnes.
| Score | Qualité | Conséquence |
|---|---|---|
| > 8/10 | Excellente | Attribution optimale, optimisation des campagnes fiable |
| 6-8/10 | Bonne | Attribution correcte, quelques signaux manquants |
| < 6/10 | Faible | Attribution dégradée, optimisation des campagnes compromise |
Ce qui fait varier l'EMQ
- Présence de _fbp (identifiant du navigateur) : cookie first-party conservé par le cookie restore
- Présence de _fbc (identifiant de clic) : généré à partir du paramètre fbclid
- Données utilisateur hachées (e-mail, téléphone, adresse) : hachage SHA-256 automatique côté serveur
- External ID (identifiant utilisateur stable)
- Adresse IP et user agent (transmis automatiquement par le sGTM)
Comment vérifier l'EMQ
Rendez-vous dans Gestionnaire d'événements Meta > Tester les événements. Chaque événement serveur y affiche son score EMQ. Objectif : > 6/10 sur tous les événements de conversion.
Améliorer l'EMQ
- 1Vérifier que le cookie restore d'Addingwell est actif (fbp et fbc conservés en first-party)
- 2Vérifier que l'Advanced Matching est configuré dans la balise sGTM Meta CAPI
- 3S'assurer que les user_data (e-mail, téléphone) sont présentes dans le DataLayer au moment de l'achat
- 4Vérifier que le domaine personnalisé du sGTM répond correctement (cookies écrits sous le bon domaine)
6Événements et paramètres
Source unique des événements
Tous les événements empruntent exclusivement ce chemin :
GTM Web → dataLayer → événement GA4 → sGTM → Meta CAPI
Aucun événement ne doit partir directement :
- Du thème Shopify
- D'un pixel Meta navigateur
- D'une application externe (app Facebook & Instagram)
- Du serveur, sans passer par le transport GA4
Tunnel e-commerce
| Action du visiteur | GA4 | Meta CAPI |
|---|---|---|
| Page chargée | page_view | PageView (facultatif) |
| Produit consulté | view_item | ViewContent |
| Ajout au panier | add_to_cart | AddToCart |
| Entrée dans le tunnel de paiement | begin_checkout | InitiateCheckout |
| Achat | purchase | Purchase |
Paramètres clés par événement
| Paramètre | GA4 | Meta CAPI | Description |
|---|---|---|---|
| ID de transaction | transaction_id | event_id | Identifiant unique pour la déduplication |
| Valeur | value | value | Montant total de la commande |
| Devise | currency | currency | Code ISO 4217 (EUR, USD) |
| Produits | items[] | contents[] | Tableau des produits |
| E-mail utilisateur | user_data.email | em (haché) | Haché en SHA-256 côté serveur |
7Logique de déduplication
Identifiant unique global
transaction_id = event_id Meta
Ce même identifiant sert pour :
- Le purchase GA4
- Le Purchase Meta
- Tous les événements serveur
Règles de déduplication
- Le dataLayer ne doit contenir qu'un seul purchase
- Aucun second envoi Meta côté client (il n'y a pas de pixel navigateur)
- Aucun purchase envoyé directement par Addingwell
- Aucun double mapping dans le sGTM
Full CAPI : pas de déduplication navigateur / serveur
En Full CAPI, aucun pixel Meta ne tourne dans le navigateur. La déduplication ne concerne donc que les doublons possibles côté DataLayer (un purchase qui se déclenche deux fois, par exemple).
8Identifiants d'attribution
Identifiants de clic Facebook
_fbp
- Cookie first-party
- Identifie le navigateur
- Sert à la correspondance probabiliste
- Conservé par le cookie restore d'Addingwell (contourne l'ITP de Safari)
_fbc
- Généré à partir du paramètre fbclid
- Permet d'attribuer une conversion au clic qui l'a précédée
- Conservé par le cookie restore d'Addingwell
Transmission vers CAPI
Les identifiants sont :
- 1Lus dans GTM Web (cookies first-party)
- 2Injectés dans les événements GA4 (transport)
- 3Transmis à Meta CAPI via le sGTM
- 4Enrichis par le hachage SHA-256 côté serveur (user_data)
9Consentement dans l'UE
Gestion du consentement
Le consentement est géré exclusivement par :
Cookiebot + Consent Mode v2 de GTM Web Signaux requis pour Meta CAPI : • ad_storage = granted • ad_user_data = granted Catégorie Cookiebot : Marketing
Le consentement n'est jamais géré dans :
- Le thème Shopify
- Le pixel personnalisé (Custom Pixel)
- Le serveur sGTM
Règles
Sans consentement marketing :
- Aucun événement Meta envoyé
- Aucun identifiant transmis
- Aucune correspondance possible
- Les signaux Consent Mode v2 parviennent quand même au serveur (mais la balise Meta ne se déclenche pas)
10Configuration
Balise sGTM : META -- CAPI -- All Events
| Paramètre | Valeur | Source |
|---|---|---|
| Pixel ID | Variable des Connecteurs | meta_pixel_id dans GTM |
| Access Token | Variable des Connecteurs | meta_access_token dans GTM |
| Event Name | Correspondance automatique | Événement GA4 → événement Meta |
| Event ID | transaction_id / event_id | DataLayer |
| User Data | Hachage SHA-256 automatique | Modèle Addingwell |
| Action Source | website | Valeur fixe |
Accès à récupérer
- 1Pixel ID : Gestionnaire d'événements Meta > Sources de données > Pixel > Paramètres
- 2Access Token : Gestionnaire d'événements Meta > Paramètres > Générer un jeton d'accès (utilisateur système)
Jeton d'accès (Access Token)
Le jeton d'accès doit être généré par un utilisateur système disposant des autorisations ads_management et ads_read. N'utilisez jamais un jeton personnel.
11Vérification
Vérification rapide
- 1Ouvrir Gestionnaire d'événements Meta > Tester les événements
- 2Naviguer sur le site après avoir accepté les cookies
- 3Vérifier que les événements apparaissent en « Serveur » (et non en « Navigateur »)
- 4Vérifier que le score EMQ dépasse 6/10 pour chaque événement
- 5Passer une commande test et vérifier l'événement Purchase
Phase 3 : checklist des destinations Meta
Points de contrôle propres à Meta CAPI, tirés du processus de recette complet (étape 5, « Verify »).
12Dépannage
Vérifier :
- 1Consentement marketing actif (ad_storage + ad_user_data = granted)
- 2purchase présent dans le rapport Temps réel de GA4
- 3Réception dans le sGTM (logs serveur)
- 4Envoi CAPI visible dans Tester les événements (Meta)
Vérifier :
- _fbp présent (cookie restore actif ?)
- _fbc présent (fbclid bien capté ?)
- user_data hachées présentes (e-mail, téléphone)
- Le domaine personnalisé du sGTM répond en 200
Vérifier :
- Jeton d'accès invalide : le régénérer dans Gestionnaire d'événements > Paramètres > Utilisateurs système
- Pixel ID incorrect : vérifier la variable dans GTM
- Consentement non accordé : vérifier que ad_storage et ad_user_data sont à granted
- Transport sGTM en erreur : vérifier les logs serveur d'Addingwell
Causes (comportement attendu en Full CAPI) :
- Sans pixel navigateur, tous les page_view ne sont pas captés
- Navigation rapide, onglets fermés avant la requête serveur
- Surveiller dans Gestionnaire d'événements > Diagnostics
- Si le ratio LPV / Link Clicks est inférieur à 50 %, vérifier que le transport sGTM répond en 200
Causes possibles :
- Consentement refusé (aucun identifiant transmis)
- Pas de fbclid dans l'URL (fbc jamais généré)
- Cookie restore désactivé dans Addingwell
- Trafic non qualifié (bots, scrapers)
Causes :
- purchase en double dans le dataLayer (page de remerciement rechargée)
- Double mapping dans le sGTM (deux balises Meta actives)
- event_id instable d'un envoi à l'autre
- App « Facebook & Instagram » encore active (pixel natif)
Vérifier :
- Cookie restore désactivé dans Addingwell > Settings
- Domaine personnalisé du sGTM non configuré (les cookies sont écrits par le domaine sGTM first-party)
- Contrôler dans DevTools > Application > Cookies, sur le domaine de la boutique
13Métriques fiables pour optimiser
Dans cette configuration Full CAPI, les KPI fiables sont :
- Volume d'achats (Purchase)
- Coût par achat
- ROAS
- Taux d'ajout au panier
- Taux de passage au paiement
Métriques à éviter
- Taux de LPV (Landing Page Views / Link Clicks) : structurellement bas en Full CAPI
- Couverture rapportée aux impressions, sans tenir compte du consentement
- Tout ratio fondé sur le pixel navigateur (qui n'existe pas ici)
14Matrice des responsabilités
- Intégrité du dataLayer
- Déclenchement des événements
- Gestion du consentement
- Persistance des identifiants (cookie restore)
- Déduplication
- Configuration du sGTM et des balises
- Optimisation des campagnes
- Choix des événements d'optimisation
- Analyse de l'attribution
- Lecture des performances
- Suivi de l'EMQ dans le Gestionnaire d'événements
- Diagnostic des écarts entre plateformes
- Validation des volumes
- Débogage entre outils
- Suivi du taux de LPV et de l'EMQ
15Checklist hebdomadaire du media buyer
Chaque semaine, vérifier :
Vérifiez la couche que vous venez d'installer
Scannez la boutique : 41 contrôles lisent ce qu'elle envoie maintenant à GA4, Meta et Google Ads.