Configuring Meta Conversions API (CAPI) via server-side GTM requires two distinct configurations to work correctly: event deduplication (to avoid double-counting when both browser Pixel and server-side CAPI are active) and user data mapping (for attribution via Event Match Quality scores). GA4 has a pre-installed Client and works with minimal setup; Meta CAPI does not.
What You Need Before Starting
- A Meta Pixel ID from your Business Manager
- A CAPI Access Token — use system user tokens, not personal user tokens. Personal tokens expire when someone leaves the Business Manager account; system user tokens persist. A lapsed token is a silent failure that stops all server-side Meta events without any browser-visible error.
- The Meta CAPI Community Template installed in your server container from the Template Gallery
Event Deduplication
Meta recommends running both the browser Pixel and CAPI simultaneously. Browser-side Pixel sends events when JavaScript runs; server-side CAPI sends events from your server. Each conversion gets recorded twice — once by each signal source — and Meta would count both as separate conversions without deduplication.
Deduplication requires both sources to send a shared event_id for the same event occurrence. Meta then matches events within a 48-hour window and deduplicates them. When it works correctly, Events Manager shows “1 event from 2 sources” rather than two separate event counts.
Here’s how to wire it up:
Step 1: Web container. Install the Unique Event ID variable template (available in the Community Template Gallery) in your web container. This generates a UUID for each event. Add this ID as an event parameter in your GA4 tags — conventionally named event_id:
// In your GA4 tag, add a custom event parameter:// Parameter name: event_id// Value: {{Unique Event ID}}Step 2: Server container. The Meta CAPI tag receives the incoming GA4 event data (which now includes event_id in the event parameters). Configure the tag to read event_id from the Event Data and forward it as the event_id field to Meta’s API.
Step 3: Browser Pixel. Make sure the Meta Pixel’s fbq('track', ...) call also includes the same event_id. If you’re firing the Pixel through the web GTM container, use the same Unique Event ID variable. If the Pixel is hardcoded in your HTML, you’ll need a different mechanism to pass the ID.
Meta’s 48-hour deduplication window is generous, but the event_id must be identical character-for-character. Even a case difference breaks matching.
Event Match Quality Score
Your Event Match Quality (EMQ) score appears in Meta Events Manager and determines how well Meta can attribute your CAPI events to Facebook/Instagram users. Higher scores mean better attribution. Target 6.0 or above. Scores below 4.0 typically indicate a configuration problem, not just missing data.
EMQ is determined by how many user identity signals you send with each event. The signals Meta uses, in approximate order of importance:
| Signal | Parameter | Format Required |
|---|---|---|
em | SHA-256 hashed | |
| Phone | ph | SHA-256 hashed |
| First name | fn | SHA-256 hashed |
| Last name | ln | SHA-256 hashed |
| City | ct | SHA-256 hashed |
| State | st | SHA-256 hashed |
| Postal code | zp | SHA-256 hashed |
| Country | country | SHA-256 hashed |
| External ID | external_id | Your internal user ID |
| Click ID | fbc | From _fbc cookie |
| Browser ID | fbp | From _fbp cookie |
SHA-256 hashing is handled by the CAPI tag template — you provide the raw values and it hashes before sending. Never send unhashed PII to Meta’s servers.
You don’t need all signals for a good EMQ score. Email alone can push you into the 6+ range. The point is that mapping user data fields you actually have access to is worth doing — it directly affects how many of your server-side conversions get attributed to the right campaigns.
Forwarding _fbp and _fbc Cookies
Two Meta-specific cookies are critical for attribution and often get missed in server-side implementations:
_fbp (Facebook Browser ID): Set by the Meta Pixel on your domain. Identifies a browser session. When a user clicks a Meta ad, this cookie is updated to include the click information.
_fbc (Facebook Click ID): Captures the fbclid click identifier from Meta ad links. This cookie is what enables click-through attribution — without it, server-side CAPI events can only match via user data, not by the specific ad click that drove the visit.
In a server-side GTM setup, these cookies are sent from the browser to your server container with each request (because they’re first-party cookies under your domain). But you need to explicitly configure the Meta CAPI tag to read them from the incoming request cookies and forward them to Meta.
In your server container, create two Cookie variables:
- Variable name:
fbp, Cookie name:_fbp - Variable name:
fbc, Cookie name:_fbc
Then map these variables to the fbp and fbclid (or fbc) fields in your Meta CAPI tag configuration. Without this mapping, the cookies exist on the request but never get forwarded.
Consent Enforcement
Meta CAPI is a non-Google tag, which means it does not automatically read Google’s Consent Mode signals. It fires unconditionally unless you build explicit consent checks into your trigger conditions.
For EEA users who have denied consent, your Meta CAPI tag must not fire. Build this by adding conditions to the CAPI tag’s trigger that check the decoded consent state from the incoming request. Typically this means checking that ad_storage and ad_user_data are both granted before the tag fires.
This is a compliance requirement, not a best practice. Firing CAPI events for users who denied consent violates GDPR and Meta’s own data use terms.
Verifying the Setup
Meta Events Manager shows incoming events in near real-time (typically a 1-2 minute delay). When checking your implementation:
- Event deduplication is working — Events Manager shows “from 2 sources” for events where both Pixel and CAPI are firing
- EMQ score is visible — appears per event in Events Manager after a few days of data
_fbcis arriving — for sessions from Meta ad clicks, the match quality breakdown shows “click ID” as a matched signal
The most common silent failure is the access token expiring. If CAPI events stop appearing in Events Manager but Pixel events continue, the token is almost certainly the issue. System user tokens with appropriate permissions don’t expire, which is why they’re preferable to personal access tokens.