Meta Ads CAPI

1Role / Purpose

Meta CAPI (Conversions API) is the server-side destination that replaces the browser Meta pixel. In our stack this is a Full CAPI architecture: no Meta pixel runs in the browser at all.

This setup delivers:

• 100% server-side tracking through the sGTM
• Strict GDPR compliance (EU-only consent)
• Robust attribution despite cookie restrictions (ITP, adblockers)
• Deterministic deduplication through event_id
• Less dependence on browser pixels
• Automatic Advanced Matching (server-side SHA-256 hashing)

2Dual-Send Architecture

The architecture is a dual-send: the browser pushes events to the DataLayer, and the sGTM server routes them to Meta CAPI. There is no browser Meta pixel: this is Full CAPI, server-only.

Full data flow

Browser (DataLayer)
      |
GTM Web (Consent Mode + DataLayer)
      |
GA4 Config Tag (technical transport)
      |
HTTP request → sGTM custom domain (first-party)
      |
sGTM (server)
├── GA4 Client (receives the request)
│     ├── GA4 Server Tag → Google Analytics 4
│     ├── META – CAPI – All Events → Meta Conversions API
│     └── GADS – Conv – purchase → Google Ads
│
└── Server-side enrichment:
      • Automatic SHA-256 hashing (email, phone, address)
      • Attribution cookies (fbp, fbc)
      • event_id for deduplication
      • Consent Mode v2 signals forwarded

Core principles

• No browser Meta pixel: Full CAPI, server-only
• No duplicate client + server send
• One source only: the GTM Web dataLayer
• Consent required before any marketing tracking
• GA4 used purely as technical transport
• Attribution cookies persisted first-party by Addingwell (cookie restore)

3CAPI Data Flow

Here is what Meta receives through CAPI versus what a browser pixel would normally send. In Full CAPI mode, everything goes through the server.

What CAPI forwards

The sGTM server sends Meta:

• Event name (PageView, ViewContent, AddToCart, InitiateCheckout, Purchase)
• Event ID (for deduplication)
• Hashed user data: email, phone, address (SHA-256)
• Attribution: fbp (browser ID), fbc (click ID from fbclid)
• Ecommerce: value, currency, content_ids, content_type, num_items
• Server URL: action_source = "website"

What CAPI does NOT receive (vs a browser pixel)

• No _fbp cookie read directly by the browser (GTM Web reads it and forwards it to the server)
• No instant PageView on load (the server must receive the GA4 request first)
• No dynamic retargeting through the JS pixel (use Meta catalogues instead)

4LPV Warning (Landing Page View)

Why LPV comes out lower

Expected causes in Full CAPI:

• Fast navigation (tab closed before the server request lands)
• Consent declined (no event sent)
• Adblockers (blocking the GA4 transport request)
• Quick bounces before the page finishes loading
• Network latency between browser and sGTM

5EMQ / Event Match Quality

Event Match Quality (EMQ) is Meta's score for how well server events match Meta users. A high score is essential for attribution and campaign optimisation.

What drives EMQ

• _fbp present (browser ID): first-party cookie persisted by cookie restore
• _fbc present (click ID): generated from the fbclid parameter
• Hashed user data (email, phone, address): automatic server-side SHA-256
• External ID (a stable user identifier)
• IP address and User Agent (forwarded automatically by the sGTM)

Improving EMQ

1. 1Check that Addingwell cookie restore is active (fbp and fbc persisted first-party)
2. 2Check that Advanced Matching is configured on the Meta CAPI sGTM tag
3. 3Make sure user_data (email, phone) is in the DataLayer at purchase time
4. 4Check that the sGTM custom domain answers correctly (cookies written under the right domain)

6Events & Parameters

Single event source

Every event comes exclusively from:

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

E-commerce funnel

Key parameters per event

7Deduplication Logic

Global unique identifier

transaction_id = Meta event_id

The same identifier is used for:

• GA4 purchase
• Meta Purchase
• Every server event

Deduplication rules

• Exactly one purchase must exist in the dataLayer
• No second client-side Meta send (there is no browser pixel)
• No purchase sent directly by Addingwell
• No double mapping in the sGTM

8Attribution Identifiers

Facebook click identifiers

Forwarding to CAPI

The identifiers are:

1. 1Read in GTM Web (1P cookies)
2. 2Injected into the GA4 events (transport)
3. 3Forwarded through the sGTM to Meta CAPI
4. 4Enriched with server-side SHA-256 hashing (user_data)

9EU Consent

Consent handling

Consent is handled exclusively by:

Cookiebot + GTM Web Consent Mode v2

Signals Meta CAPI requires:
• ad_storage = granted
• ad_user_data = granted

Cookiebot category: Marketing

Rules

Without marketing consent:

• No Meta event is sent
• No identifier is forwarded
• No matching is possible
• Consent Mode v2 signals still reach the server (but the Meta tag does not fire)

10Configuration

sGTM tag: META -- CAPI -- All Events

Credentials needed

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

11Verification

Quick check

1. 1Open Meta Events Manager > Test Events
2. 2Browse the site with consent accepted
3. 3Check that events show up as "Server" (not "Browser")
4. 4Check the EMQ score is > 6/10 on each event
5. 5Place a test order and check the Purchase

Phase 3: Meta destinations checklist

Meta CAPI-specific verification, lifted from the full QA process (Step 5: Verify).

12Troubleshooting

13Metrics You Can Optimise On

The KPIs that hold up in this Full CAPI setup:

• Purchase volume
• Cost per Purchase
• ROAS
• AddToCart Rate
• Checkout Rate

14Responsibilities Matrix

15Weekly Media-Buyer Checklist

Every week, check: