Meta Conversions API: Setup, Deduplication & EMQ

Last quarter I audited a DTC brand spending €15,000/month on Meta. Their pixel reported 220 purchases. Shopify recorded 410. That is a 46% gap -- nearly half the conversions were invisible to Meta's algorithm, which meant Advantage+ was optimizing on a distorted picture and CPA kept climbing.

The fix was the Meta Conversions API. Within three weeks of a proper implementation -- server-side events, correct deduplication, Event Match Quality above 8 -- reported conversions jumped 38% and cost per purchase dropped by a fifth. No budget increase. Just better data.

This guide covers what the Conversions API is, how to set it up, how to avoid the deduplication mistakes that wreck it, and how to push your Event Match Quality high enough that Meta's algorithm actually benefits.

What Is Meta Conversions API (and Why the Pixel Alone Fails)

The Meta Conversions API (CAPI) is a server-to-server interface that lets you send conversion events directly from your server to Meta -- bypassing the browser entirely.

With the traditional Meta pixel, everything happens client-side: the user's browser loads fbevents.js, fires an event, and sends it to facebook.com. That worked well enough in 2019. In 2026, three forces have broken it:

1. Safari ITP caps JavaScript-set cookies at 7 days (24 hours if the URL has a click ID decoration). A user who clicks a Meta ad on Monday and buys the following Tuesday is invisible to the pixel on Safari.
2. Ad blockers affect roughly 32% of internet users globally and typically block requests to facebook.com domains, which kills pixel events entirely.
3. iOS App Tracking Transparency -- about 75% of users opt out -- limits the data the Facebook app and in-app browsers can collect.

The Conversions API sidesteps all three. Events travel server-to-server, so there is no browser script to block, no client-side cookie to expire, and no ATT prompt in the way. Meta reports that advertisers using CAPI alongside the pixel see 19% more attributed purchases compared to the pixel alone.

If this sounds familiar from server-side tracking in general, it should. The Conversions API is Meta's implementation of the same principle I cover in my server-side tracking guide. The difference is the specifics: deduplication logic, Event Match Quality scoring, and Meta-specific parameters that determine whether the setup actually helps or just adds noise.

Conversions API vs Meta Pixel: What Each Does

The pixel and the Conversions API are not competitors. Meta explicitly recommends running both -- redundant signals improve coverage. But they work differently, and understanding the split matters for deduplication.

Aspect	Meta Pixel	Conversions API
Where it runs	User's browser	Your server
Blocked by ad blockers	Yes	No
Affected by ITP	Yes (7-day cookie cap)	No (server-side cookies persist)
Sends PII for matching	Limited (browser cookies)	Full (hashed email, phone, IP)
Handles offline events	No	Yes
Requires development	No (copy-paste snippet)	Yes (server integration)

The strongest setup is both in parallel: the pixel catches real-time browser events with high speed, while the Conversions API fills the gaps the pixel misses and enriches events with first-party data that lifts match rates.

Three Ways to Set Up the Conversions API

There is no single "right" implementation. The best approach depends on your stack, team, and budget.

1. Server-Side GTM (sGTM) with the Meta CAPI Tag

This is the approach I use most often. If you already run Google Tag Manager, adding a server container gives you a single pipeline that feeds both Google and Meta.

The flow: your web GTM container sends events to your server container (hosted on Stape.io, Cloud Run, or similar). A Meta CAPI tag in the server container receives each event, enriches it with user parameters, and forwards it to Meta's API endpoint.

Pros: Centralized tagging for all platforms. One implementation covers Meta CAPI, Google Enhanced Conversions, GA4 server-side, and more. You control what data leaves your infrastructure.

Cons: Requires a server container and hosting. Overkill if Meta is your only ad platform (rare).

2. Meta Conversions API Gateway

The Meta Conversions API Gateway is Meta's managed server-side solution. It runs on your cloud infrastructure (AWS or GCP) but uses Meta's pre-built configuration -- essentially a one-click deployment that proxies pixel events server-side.

It is the fastest path to a working CAPI setup if you only need Meta and want minimal configuration. The downside: it is Meta-specific, so you still need a separate solution for Google or TikTok.

3. Direct API Integration

For developers comfortable with REST APIs, you can POST events directly to the Conversions API endpoint. This is common in custom e-commerce backends, mobile apps, and CRM-triggered workflows -- for example, sending a "Purchase" event when a payment webhook fires.

This approach also powers the meta offline conversions API use case: feeding CRM stage changes (lead qualified, deal closed) back to Meta so the algorithm learns which clicks produce real customers, not just leads. I covered why this matters for B2B at length in my B2B conversion tracking guide.

Deduplication: Where Most Implementations Break

Here is the single most common mistake with the Conversions API: sending the same event from both the pixel and CAPI without deduplication, which doubles your reported conversions.

Meta deduplicates on two fields: event_id and event_name. If the pixel fires a "Purchase" event with event_id: "order_12345" and CAPI sends the same "Purchase" with the same event_id, Meta keeps one and discards the duplicate. If either field is missing or mismatched, Meta counts both.

How to Get Deduplication Right

1. Generate a unique event_id per event. A transaction ID or order number works for purchases. For leads, use a form submission UUID. The key: the same ID must appear in both the pixel event and the CAPI event.
2. Set the event_id in the data layer. Push it from your backend so both the client-side pixel and the server-side tag read the same value. Never generate it in browser JavaScript independently from the server -- you will get mismatches.
3. Match event_name exactly. "Purchase" and "purchase" are different events to Meta's dedup logic. Stick to Meta's standard event names.
4. Test with the Events Manager. In Meta Events Manager, open the Test Events tab. Fire a conversion and verify you see one event marked "Browser and Server" -- not two separate events. If you see two, your event_id is not matching.

What Happens When Deduplication Fails

I see this in roughly a third of the CAPI implementations I audit. The symptoms:

• Conversion count in Meta doubles overnight after CAPI goes live.
• CPA drops to suspiciously low levels (Meta thinks conversions doubled).
• Advantage+ starts scaling spend aggressively because the algorithm believes performance improved.
• A few weeks later, actual ROAS tanks because the algorithm was chasing phantom conversions.

If your Meta numbers shifted dramatically right after a CAPI deployment, broken deduplication is the first thing to check. If you are not sure how to diagnose it, I can audit your setup and pinpoint the issue.

Event Match Quality: The Score That Determines CAPI ROI

Meta assigns every event a score from 1 to 10 called Event Match Quality (EMQ). It measures how reliably Meta can match a server event to a Facebook user. The higher the score, the more conversions Meta can attribute, and the better the algorithm optimizes.

An EMQ below 6 means Meta cannot match a significant share of your events -- you are sending data but getting little benefit. Above 8, and you are giving the algorithm strong signal.

What Drives Event Match Quality

EMQ depends on the user parameters you send with each event. Meta ranks them by matching power:

Parameter	Impact	Notes
Email (hashed)	Highest	Send for every event if possible
Phone (hashed)	High	Include country code
fbp cookie	High	The _fbp first-party cookie; pass it server-side
fbc cookie	High	Contains the click ID; critical for click-based attribution
Client IP address	Medium	Server-side makes this easy
User agent	Medium	Forward from the original request
External ID	Medium	Your internal user ID, hashed
First name, last name	Lower	Useful in aggregate

The three highest-impact actions for most implementations:

1. Always send hashed email. This alone can push EMQ from 4 to 7.
2. Pass the _fbp and _fbc cookies. These are first-party cookies set by the pixel. Read them server-side and include them in the CAPI payload. Without them, Meta cannot link the server event to the browser session.
3. Forward client IP and user agent. These are available in any server request. They cost nothing to include and improve matching.

How to Check Your EMQ

Open Meta Events Manager, navigate to your pixel, and click on a specific event (e.g., "Purchase"). The Event Match Quality score appears in the overview. Meta also shows which parameters are present and which are missing -- the gaps tell you exactly what to fix.

A Practical Checklist

Before you consider your Meta Conversions API implementation done, verify each item:

• CAPI events fire for every standard event your pixel tracks (ViewContent, AddToCart, Purchase, Lead, etc.)
• Every event includes a unique event_id that matches the pixel event
• Deduplication is confirmed in Events Manager (events show "Browser and Server," not duplicates)
• Hashed email is included in every event where available
• _fbp and _fbc cookies are forwarded to CAPI
• Client IP and user agent are included
• Event Match Quality is 6 or above for all key events (aim for 8+)
• Consent is respected -- no events fire for users who declined tracking

Cost and Effort

Approach	One-time setup	Monthly cost
sGTM + Stape.io	€500-1,500 (implementation)	~€20-50 (hosting)
Meta CAPI Gateway	€200-500 (deployment)	~€30-100 (cloud infra)
Direct API integration	€1,000-3,000 (development)	Negligible (runs on your servers)

For most businesses already running Google Ads alongside Meta, the sGTM route wins because one implementation covers both platforms. If you are Meta-only with a modest budget, the Gateway is the fastest path. Direct API integration makes sense when you have custom backend requirements or need to handle offline events at scale.

The payoff math is straightforward: if your pixel is missing 30-40% of conversions (typical for sites with significant Safari and mobile traffic), CAPI recovers the majority of those. More signal means better optimization, which means lower CPA at the same spend. For an account spending €5,000/month on Meta, even a 15% CPA improvement is €750/month -- the implementation pays for itself in weeks.

FAQ

Not sure your Meta Conversions API setup is actually working? Get in touch -- I will audit your implementation, check deduplication and Event Match Quality, and tell you exactly what to fix.