Meta Conversions API Setup: Dedup, Match Quality, Verification

The Conversions API is usually described as a backup for the browser pixel. That framing is why so many setups end up worse than the pixel alone: teams bolt on a server feed, watch their conversion count roughly double, and only discover months later that deduplication was never working. This guide covers the setup in the order that keeps the numbers honest — what CAPI actually is, the four ways to send events, the deduplication rules that decide whether your data is usable, and how to verify it before you trust a single reported conversion.

What the Conversions API actually changes

The browser pixel reports events from the visitor's device. That path is lossy by design now: tracking prevention in browsers, extensions, and network-level blocking all remove a share of events before they reach Meta, and the share is largest on exactly the traffic you care most about.

The Conversions API sends the same events from your server instead. The event does not travel through the visitor's browser, so it is not subject to browser-side blocking. What it is subject to is your own implementation: if your server does not know something, Meta does not receive it.

Two consequences follow, and both are the opposite of what "backup" implies:

CAPI is not a replacement for the pixel. The recommended setup is both, sending the same events, deduplicated. The pixel contributes browser-side signals a server cannot see; the server contributes events the browser never delivers.
CAPI quality is your responsibility. The pixel collects identifiers automatically. On the server you have to attach them deliberately, and a server feed with thin customer information matches poorly — which shows up as attributed conversions quietly disappearing rather than as an error.

If you have not set up the browser side yet, do that first: see the Facebook Pixel setup guide.

The four ways to send events

Direct API integration. Your backend calls the API itself. Maximum control over which events fire, what data is attached, and when. Requires developer time and ongoing maintenance, and it is the only option that lets you send events that have no browser equivalent at all — an offline sale, a refund, a lead that qualified three days later.

A platform integration. Most major e-commerce platforms ship a first-party CAPI connection. Fastest route, and adequate for standard purchase funnels. The limitation is that you send what the integration decides to send.

A partner or tag-manager integration. Server-side tag management routes events through your own server container. Good middle ground when you already run server-side tagging for other reasons.

Conversions API Gateway. A hosted service that stands up the server-side infrastructure for you. Reasonable when you lack engineering capacity, at the cost of another dependency in the path.

For most teams the honest answer is the platform integration first, then a direct integration for the events the platform cannot see.

Deduplication: the part that decides whether any of this works

If the pixel and the server both report the same purchase and Meta cannot tell they are the same purchase, it counts two. Your reported conversions inflate, your reported cost per result halves, and every optimisation decision downstream is made on numbers that are wrong in a direction that looks good.

Two fields do the work, and both must match across the two channels for the same event:

event_name — the same event name from both sides.
event_id — a unique identifier you generate for that specific occurrence, sent identically by the pixel and by the server.

The rule that catches people: event_id must be generated once per event occurrence and then shared with both senders. Generating it independently on the client and on the server produces two different values and no deduplication at all. Practically, generate it server-side when rendering the page and pass the same value into the browser event.

Deduplication has a matching window, so a server event sent long after the browser event may not pair. Send both close together.

Customer information: what actually drives match quality

Every parameter you attach is hashed before sending. More parameters means a higher chance the event matches a person, which is what determines whether the conversion is attributed at all.

In rough order of contribution: email, phone number, external ID, then name, city, state, postcode and country. Add the click identifier (fbc) and browser identifier (fbp) whenever you have them — these come from the browser and have to be captured and passed to your server deliberately, and they are the single most common omission in server-only setups.

Normalise before hashing: lowercase, trim whitespace, strip punctuation from phone numbers, and use the country calling code. A correctly hashed but incorrectly normalised value matches nothing, and produces no error.

Meta reports an event match quality score per event. Treat a low score as a defect to fix, not a number to observe.

Setup, in the order that avoids rework

Confirm the pixel works first. A broken browser side makes every later number ambiguous.
Decide the event list. Start with the events you optimise campaigns toward. Sending everything adds noise and match-quality problems without adding decisions.
Generate event_id server-side and pass it to the browser event. Do this before writing the server call, not after.
Attach the richest customer information you legitimately hold, normalised then hashed, including fbc and fbp.
Send to the test endpoint first and watch events arrive in the Events Manager test tool.
Verify deduplication with real traffic, not with test events. Compare reported counts against your own order records for the same window.
Check match quality after a few days of volume, and fix the weakest parameters.

How to tell it is working

Three checks, and none of them is "the dashboard shows events".

Your own order count is the oracle. For a fixed window, compare orders in your database against reported purchases. Roughly equal is correct. Substantially higher means deduplication is failing. Substantially lower means match quality or missing events.

Deduplication is visible in the diagnostics. Events Manager reports when it receives redundant events and whether they were deduplicated. Redundant-but-not-deduplicated is the failure state to hunt for.

Match quality is stable and reasonable. A score that drops after a deploy is a broken parameter, and it will not announce itself any other way.

Frequently asked questions

Do I still need the pixel if I have CAPI? Yes. The recommended configuration is both, deduplicated. Server-only setups lose browser-side signals and usually match worse.

Will my conversion count go up? Genuinely recovered events will raise it modestly. A large jump on day one is almost always duplication, not recovery.

What if I do not have email addresses? Send what you have — external ID, fbc, fbp and geography still contribute. Match quality will be lower and attribution weaker, which is a real cost, not a formality.

Can I send events for things that never happened in a browser? Yes, and this is CAPI's most underused capability: offline conversions, phone orders, and leads that qualify later.

Does this help with ad account stability? Indirectly. Better measurement means fewer changes made on bad data. Account and policy stability is a separate topic — see Meta ad policy approval and disapproval.

The short version

Run the pixel and the Conversions API together, send the same events from both, and share one event_id per occurrence so Meta can deduplicate. Attach as much normalised customer information as you legitimately have, including the browser identifiers. Then verify against your own order records rather than against the dashboard — the failure mode here does not throw errors, it just makes your numbers look better than they are.

DeepClick works with advertisers on the measurement layer around Meta campaigns, including how tracking and landing-page delivery fit together.