GuideFull CAPI~15 min

Meta Ads CAPI

Guide technique MediaBuyer : Full CAPI server-side. Architecture sGTM, deduplication, consent EU, troubleshooting.

Connectors0/2

Meta Pixel ID

Meta Events Manager — chiffres uniquement

Const - Meta - Pixel ID

Meta Access Token

Meta Events Manager > Settings > System Users

Const - Meta - Access Token

1Role / Objectif

Meta CAPI (Conversions API) est la destination server-side qui remplace le pixel Meta browser. Dans notre stack, c'est une architecture Full CAPI : aucun pixel Meta ne tourne dans le navigateur.

Ce setup permet :

Tracking 100% server-side via sGTM
Conformite RGPD stricte (EU-Only consent)
Attribution robuste malgre les restrictions cookies (ITP, adblockers)
Deduplication deterministe via event_id
Reduction de la dependance aux pixels browser
Advanced Matching automatique (hash SHA-256 cote server)

Le systeme repose sur une source unique d'evenements (dataLayer GTM Web) afin d'eviter toute duplication. Aucun evenement n'est envoye directement depuis le navigateur vers Meta.

2Architecture Dual-Send

L'architecture repose sur un dual-send : le navigateur envoie les events au DataLayer, et le serveur sGTM les route vers Meta CAPI. Il n'y a pas de pixel Meta browser — c'est du Full CAPI server-only.

Flux complet des donnees

Browser (DataLayer)
        |
GTM Web (Consent Mode + DataLayer)
        |
GA4 Config Tag (transport technique)
        |
  HTTP request → custom domain sGTM (first-party)
        |
sGTM (server)
  ├── GA4 Client (recoit la requete)
  │     ├── GA4 Server Tag → Google Analytics 4
  │     ├── META – CAPI – All Events → Meta Conversions API
  │     └── GADS – Conv – purchase → Google Ads
  │
  └── Enrichissement server-side :
        • Hash SHA-256 automatique (email, tel, adresse)
        • Attribution cookies (fbp, fbc)
        • event_id pour deduplication
        • Consent Mode v2 signaux transmis

Principes fondamentaux

Aucun pixel Meta browser — Full CAPI server-only
Aucun double envoi client + server
Une seule source : dataLayer GTM Web
Consent obligatoire avant tout tracking marketing
GA4 utilise comme transport technique uniquement
Cookies d'attribution persistes en first-party par Addingwell (cookie restore)

3CAPI Data Flow

Voici ce que Meta recoit via CAPI versus ce qu'un pixel browser enverrait normalement. En mode Full CAPI, tout passe par le serveur.

Parametre	Valeur
Mode	Full CAPI (server-only)
Tag sGTM	META – CAPI – All Events
Deduplication	event_id = transaction_id (purchase)
Attribution cookies	fbp + fbc (1P cookies, persistees par cookie restore)
Advanced Matching	SHA-256 automatique (email, tel, adresse)
Consent transport	Consent Mode v2 signaux transmis au server

Donnees transmises par CAPI

Le serveur sGTM envoie a Meta :

Event name (PageView, ViewContent, AddToCart, InitiateCheckout, Purchase)
Event ID (pour deduplication)
User data hashee : email, telephone, adresse (SHA-256)
Attribution : fbp (browser ID), fbc (click ID depuis fbclid)
Ecommerce : value, currency, content_ids, content_type, num_items
Server URL : action_source = "website"

Ce que CAPI ne recoit PAS (vs pixel browser)

Pas de cookie _fbp lu directement par le navigateur (lu par GTM Web et transmis au server)
Pas de PageView instantane au chargement (le server doit recevoir la requete GA4 d'abord)
Pas de retargeting dynamique via pixel JS (utiliser les catalogues Meta a la place)

4LPV Warning (Landing Page View)

Limitation Full CAPI

Le taux LPV (Landing Page Views / Link Clicks) est structurellement plus bas en mode Full CAPI car il n'y a pas de pixel browser pour comptabiliser les vues de page instantanement.

Le LPV ne represente plus

Un chargement reel de pixel browser (pas de pixel JS Meta)

Mais represente

Un signal estime cote serveur (page_view via sGTM)

Pourquoi le LPV est plus bas

Causes normales en Full CAPI :

Navigation rapide (onglet ferme avant que la requete server n'arrive)
Refus consent (aucun event envoye)
Adblockers (bloquent la requete GA4 transport)
Abandons rapides avant chargement complet
Latence reseau entre browser et sGTM

Monitorer dans Events Manager

Verifier dans Meta Events Manager > Diagnostics. Si le ratio LPV/Link Clicks est < 50%, verifier que le transport sGTM repond bien en 200.

Consequence pour les MediaBuyers

Le LPV Rate ne doit pas etre utilise pour juger la qualite du trafic ou optimiser les campagnes. Utiliser les metriques de conversion (Purchase, ATC) a la place.

5EMQ / Event Match Quality

L'Event Match Quality (EMQ) est le score Meta qui mesure la qualite du matching entre les events server et les utilisateurs Meta. Un score eleve est essentiel pour l'attribution et l'optimisation des campagnes.

Score	Qualite	Impact
> 8/10	Excellent	Attribution optimale, optimisation campagnes fiable
6-8/10	Bon	Attribution correcte, quelques signaux manquants
< 6/10	Faible	Attribution degradee, optimisation campagnes compromise

Facteurs qui influencent l'EMQ

Presence de _fbp (browser ID) — cookie first-party persiste par cookie restore
Presence de _fbc (click ID) — genere a partir du parametre fbclid
User data hashee (email, telephone, adresse) — hash SHA-256 automatique cote server
External ID (identifiant utilisateur stable)
IP address et User Agent (transmis automatiquement par sGTM)

Comment verifier l'EMQ

Aller dans Meta Events Manager > Test Events. Chaque event server affiche son score EMQ. Objectif : > 6/10 pour tous les events de conversion.

Ameliorer l'EMQ

1Verifier que le cookie restore Addingwell est actif (fbp et fbc persistes en 1P)
2Verifier que le Advanced Matching est configure dans le tag sGTM Meta CAPI
3S'assurer que les user_data (email, tel) sont presentes dans le DataLayer au moment du purchase
4Verifier que le custom domain sGTM repond correctement (cookies ecrits sous le bon domaine)

6Events & Parameters

Source unique des evenements

Tous les evenements proviennent exclusivement de :

GTM Web → dataLayer → GA4 event → sGTM → Meta CAPI

Aucun evenement ne doit etre envoye directement depuis :

Le theme Shopify
Un pixel Meta browser
Une application externe (Facebook & Instagram app)
Le serveur sans passer par GA4 transport

Funnel Ecommerce

Action utilisateur	GA4	Meta CAPI
Page chargee	page_view	PageView (optionnel)
Produit vu	view_item	ViewContent
Ajout panier	add_to_cart	AddToCart
Debut checkout	begin_checkout	InitiateCheckout
Achat	purchase	Purchase

Parametres cles par event

Parametre	GA4	Meta CAPI	Description
Transaction ID	transaction_id	event_id	Identifiant unique pour deduplication
Valeur	value	value	Montant total de la commande
Devise	currency	currency	Code ISO 4217 (EUR, USD)
Produits	items[]	contents[]	Array des produits
User email	user_data.email	em (hashed)	Hash SHA-256 cote server

7Logique de Deduplication

Identifiant unique global

transaction_id = event_id Meta

Ce meme identifiant est utilise pour :

GA4 purchase
Meta Purchase
Tous les events server

Regles de deduplication

Un seul purchase doit exister dans la dataLayer
Aucun second envoi Meta client (pas de pixel browser)
Aucun purchase envoye directement par Addingwell
Aucun mapping double cote sGTM

Full CAPI = pas de deduplication browser/server

En mode Full CAPI, il n'y a pas de pixel browser Meta. La deduplication concerne uniquement les doublons potentiels cote DataLayer (ex: purchase fire deux fois).

8Identifiants d'Attribution

Facebook Click Identifiers

_fbp

Cookie first-party
Identifie le navigateur
Utilise pour le matching probabiliste
Persiste par cookie restore Addingwell (contourne ITP Safari)

_fbc

Genere a partir du parametre fbclid
Permet l'attribution click-to-conversion
Persiste par cookie restore Addingwell

Transmission vers CAPI

Les identifiants sont :

1Lus cote GTM Web (cookies 1P)
2Injectes dans les events GA4 (transport)
3Transmis via sGTM vers Meta CAPI
4Enrichis par le hash SHA-256 cote server (user_data)

Gestion du consent

Le consent est gere exclusivement par :

Cookiebot + GTM Web Consent Mode v2

Signaux requis pour Meta CAPI :
  • ad_storage = granted
  • ad_user_data = granted

Categorie Cookiebot : Marketing

Aucun consent n'est gere dans :

Le theme Shopify
Le Custom Pixel
Le serveur sGTM

Regles

Sans consent marketing :

Aucun event Meta envoye
Aucun identifier transmis
Aucun matching possible
Les signaux Consent Mode v2 sont transmis au server (mais le tag Meta ne fire pas)

10Configuration

Tag sGTM : META -- CAPI -- All Events

Parametre	Valeur	Source
Pixel ID	Variable Connectors	meta_pixel_id dans GTM
Access Token	Variable Connectors	meta_access_token dans GTM
Event Name	Mapping automatique	GA4 event → Meta event
Event ID	transaction_id / event_id	DataLayer
User Data	Hash SHA-256 automatique	Addingwell template
Action Source	website	Fixe

Credentials necessaires

1Pixel ID : Meta Events Manager > Data Sources > Pixel > Settings
2Access Token : Meta Events Manager > Settings > Generate Access Token (System User)

Access Token

L'Access Token doit etre genere via un System User avec les permissions ads_management et ads_read. Ne jamais utiliser un token personnel.

11Verification

Verification rapide

1Ouvrir Meta Events Manager > Test Events
2Naviguer sur le site avec consent accepte
3Verifier que les events apparaissent comme "Server" (pas "Browser")
4Verifier le score EMQ > 6/10 pour chaque event
5Faire un achat test et verifier le Purchase

Phase 3 : Checklist Destinations Meta

Checklist de verification specifique Meta CAPI, extraite du processus QA complet (Step 5 - Verify).

Meta CAPI (Full CAPI)0/5

12Troubleshooting

Baisse des conversions

Verifier :

1Consent marketing actif (ad_storage + ad_user_data = granted)
2Presence purchase dans GA4 Realtime
3Reception dans sGTM (logs server)
4Envoi CAPI visible dans Meta Test Events

Match quality faible (EMQ < 6)

Verifier :

Presence _fbp (cookie restore actif ?)
Presence _fbc (fbclid capture ?)
user_data hashee presente (email, tel)
Custom domain sGTM repond en 200

Meta CAPI sans events

Verifier :

Access Token invalide — regenerer dans Events Manager > Settings > System Users
Pixel ID incorrect — verifier la variable dans GTM
Consent non accorde — verifier que ad_storage et ad_user_data sont granted
Transport sGTM en erreur — verifier les logs server Addingwell

Taux LPV faible

Causes (comportement attendu en Full CAPI) :

Sans pixel browser, les page_view ne sont pas toutes captees
Navigation rapide, onglets fermes avant la requete server
Monitorer dans Events Manager > Diagnostics
Si ratio LPV/Link Clicks < 50%, verifier que le transport sGTM repond en 200

Attribution instable

Causes possibles :

Consent refuse (aucun identifier transmis)
Absence fbclid dans l'URL (fbc non genere)
Cookie restore desactive dans Addingwell
Trafic non qualifie (bots, scrapers)

Doublons purchase

Causes :

Double purchase dans la dataLayer (page thank-you rechargee)
Mapping double cote sGTM (deux tags Meta actifs)
event_id non stable entre les envois
App "Facebook & Instagram" encore active (pixel natif)

Cookies attribution absents (fbp, fbc)

Verifier :

Cookie restore desactive dans Addingwell > Settings
Custom domain sGTM non configure (cookies ecrits par le domaine sGTM first-party)
Verifier dans DevTools > Application > Cookies avec le domaine du store

13Metriques Fiables pour Optimisation

Les KPIs fiables dans ce setup Full CAPI sont :

Purchase volume
Cost per Purchase
ROAS
AddToCart Rate
Checkout Rate

Metriques a eviter

LPV Rate (Landing Page Views / Link Clicks) — structurellement bas en Full CAPI
Reach vs Impressions sans contexte consent
Tout ratio base sur le pixel browser (inexistant dans ce setup)

14Responsibilities Matrix

Tracking Team

Integrite dataLayer
Declenchement evenements
Consent management
Persistance identifiers (cookie restore)
Deduplication
Configuration sGTM et tags

MAds Team

Optimisation campagnes
Choix evenements d'optimisation
Analyse attribution
Interpretation performance
Monitoring EMQ dans Events Manager

Responsabilite partagee

Diagnostic ecarts plateformes
Validation volumes
Debugging cross-tools
Monitoring LPV rate et EMQ

15Checklist Hebdomadaire MediaBuyer

Chaque semaine verifier :

Evolution volume Purchase

Match quality score (EMQ > 6/10)

Ratio ATC → Purchase

Impact consent rate sur le volume

Coherence GA4 vs Meta (ecarts < 15%)

LPV rate (attendu plus bas, pas un signal d'alerte)

Cookies attribution presents (fbp, fbc)

Meta Ads CAPI

1Role / Objectif

2Architecture Dual-Send

Flux complet des donnees

Principes fondamentaux

3CAPI Data Flow

Donnees transmises par CAPI

Ce que CAPI ne recoit PAS (vs pixel browser)

4LPV Warning (Landing Page View)

Pourquoi le LPV est plus bas

5EMQ / Event Match Quality

Facteurs qui influencent l'EMQ

Ameliorer l'EMQ

6Events & Parameters

Source unique des evenements

Funnel Ecommerce

Parametres cles par event

7Logique de Deduplication

Identifiant unique global

Regles de deduplication

8Identifiants d'Attribution

Facebook Click Identifiers

Transmission vers CAPI

9Consentement EU

Gestion du consent

Regles

10Configuration

Tag sGTM : META -- CAPI -- All Events

Credentials necessaires

11Verification

Verification rapide

Phase 3 : Checklist Destinations Meta

12Troubleshooting

13Metriques Fiables pour Optimisation

14Responsibilities Matrix

15Checklist Hebdomadaire MediaBuyer