Meta Ads CAPI

Série Tracking · Full CAPI · environ 15 min de lecture.

Identifiants nécessaires pour ce guide :

Rô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

Architecture à 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 transmis

Principes 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)

Flux 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.

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)

Mise en garde sur le LPV (Landing Page View)

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

EMQ (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.

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)

Améliorer l'EMQ

1. Vérifier que le cookie restore d'Addingwell est actif (fbp et fbc conservés en first-party)
2. Vérifier que l'Advanced Matching est configuré dans la balise sGTM Meta CAPI
3. S'assurer que les user_data (e-mail, téléphone) sont présentes dans le DataLayer au moment de l'achat
4. Vérifier que le domaine personnalisé du sGTM répond correctement (cookies écrits sous le bon domaine)

É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

Tunnel e-commerce

Paramètres clés par événement

Logique 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

Identifiants d'attribution

Identifiants de clic Facebook

Transmission vers CAPI

Les identifiants sont :

1. Lus dans GTM Web (cookies first-party)
2. Injectés dans les événements GA4 (transport)
3. Transmis à Meta CAPI via le sGTM
4. Enrichis par le hachage SHA-256 côté serveur (user_data)

Consentement 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

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)

Configuration

Balise sGTM : META -- CAPI -- All Events

Accès à récupérer

1. Pixel ID : Gestionnaire d'événements Meta > Sources de données > Pixel > Paramètres
2. Access Token : Gestionnaire d'événements Meta > Paramètres > Générer un jeton d'accès (utilisateur système)

Vérification

Vérification rapide

1. Ouvrir Gestionnaire d'événements Meta > Tester les événements
2. Naviguer sur le site après avoir accepté les cookies
3. Vérifier que les événements apparaissent en « Serveur » (et non en « Navigateur »)
4. Vérifier que le score EMQ dépasse 6/10 pour chaque événement
5. Passer 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 »).

Meta CAPI (Full CAPI)

• Événements visibles dans Tester les événements (Meta)
• Événements marqués « Serveur » dans le Gestionnaire d'événements (CAPI actif, aucun « Navigateur »)
• Déduplication fonctionnelle : event_id = transaction_id pour purchase
• Event Match Quality > 6/10 (Advanced Matching + cookies d'attribution)
• Cookies fbp et fbc présents dans DevTools > Application > Cookies

Dépannage

Mé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

Matrice des responsabilités

Checklist hebdomadaire du media buyer

Chaque semaine, vérifier :

• Évolution du volume d'achats (Purchase)
• Score de qualité de correspondance (EMQ > 6/10)
• Ratio ATC → Purchase
• Effet du taux de consentement sur les volumes
• Cohérence entre GA4 et Meta (écarts < 15 %)
• Taux de LPV (plus bas par nature : ce n'est pas un signal d'alerte)
• Cookies d'attribution présents (fbp, fbc)

Et ensuite