Meta CAPI Setup: Why It Under-Reports Sales

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London delivering tracking and measurement work for agency and in-house clients.

You installed the Meta Conversions API because signal loss was eating your reporting, and now the numbers look worse, not better. Ads Manager shows fewer conversions than before, or double what your store recorded, and Events Manager insists everything is fine. This is the guide we’d give a client in that spot: what CAPI actually does, the three setup paths, and the two failure modes (deduplication and match quality) that make a “working” setup under-report.

We set the Meta Conversions API up for agencies and marketing teams regularly, so the focus here is the implementation detail vendors skip when they’re selling you their own gateway.

What is the Meta Conversions API?

The Meta Conversions API (CAPI) is a server-to-server connection that sends conversion events to Meta directly from your server, rather than only from the visitor’s browser through the Meta Pixel. Because the event leaves your infrastructure instead of the browser, ad blockers, cookie limits and iOS App Tracking Transparency can’t drop it in transit. Meta’s guidance is to run CAPI and the Pixel together, with each event sent twice and deduplicated, so the two sources cover each other’s blind spots.

The point of CAPI is signal recovery. When Apple’s App Tracking Transparency prompt rolled out with iOS 14.5, a large share of iPhone users opted out of browser-level tracking, and browser pixels started losing purchase events they used to see. Server events sidestep that gap. The catch is that a server event Meta can’t match to a person, or can’t tell apart from the Pixel’s copy, is worth nothing. That’s where most setups quietly fail.

Why does CAPI under-report even after you install it?

CAPI under-reports when events reach Meta but get discarded, usually for one of two reasons: bad deduplication or poor match quality. The connection shows green in Events Manager, events tick upward, and yet the conversions attributed to your campaigns fall. Meta received the events; it just couldn’t use them.

Here’s the mechanism. Every purchase should arrive twice, once from the browser Pixel and once from your server. Meta expects to see both, recognise them as the same event, and keep one. If the two copies don’t carry a shared identifier, Meta can’t tell they’re the same sale. Depending on the timing, it either drops one as a suspected duplicate (under-counting) or keeps both (double-counting). Neither gives you a number you can trust. Get this wrong and you’ll see the same confusion we cover in why Meta ads over-report conversions: a dashboard that doesn’t match the till.

The three ways to set up Meta CAPI

There’s no single “correct” CAPI setup. There are three common paths, and the right one depends on your stack and who maintains it.

Setup path	Best fit	Main strength	Main risk
Native or managed gateway (Shopify CAPI, hosted gateways)	Shopify and small-to-mid ecommerce	Fast to ship, little code	Less control; deduplication handled for you, so hard to audit
Server-side Google Tag Manager (sGTM)	Teams already on sGTM, or feeding Meta plus GA4 and Google Ads from one server	One server layer for every platform	Needs a tagging server and real GTM skill to configure event_id correctly
Direct API integration	Engineering-led teams wanting full payload control	Complete control of parameters and timing	You own deduplication, hashing and retries end to end

A managed gateway or Shopify’s built-in connection is the quickest to get live and the right call when nobody on the team writes server code. The trade-off is visibility: the gateway decides how deduplication and hashing work, so when the numbers drift you have less to inspect.

Server-side GTM is the middle path. You run a tagging server (on Google Cloud, Stape or similar), and one server sends events to Meta, GA4 and Google Ads together. It’s the setup we reach for most with agency clients because a single server layer is easier to govern than three separate integrations. It also demands the most care: the event_id has to be generated once and passed to both the browser Pixel and the server tag, or deduplication breaks.

A direct integration gives an engineering team total control of the payload and is worth it when the business has bespoke server logic. It also puts every detail on you: hashing customer data correctly, generating a shared event ID, and retrying failed calls.

Event deduplication: the part everyone gets wrong

Deduplication is how Meta recognises the browser and server copies of one event as the same conversion and keeps a single count. Meta matches the two using a shared event_id plus the event_name, and treats events as duplicates when both arrive within a 48-hour window. Miss the shared ID and the whole thing falls apart.

The rule is simple to state and easy to break: the Pixel event and the server event for the same purchase must carry the same event_id. Generate that ID once, when the conversion happens, and hand it to both paths. A common mistake is letting each side mint its own ID, so Meta sees two different events and counts both. Another is sending the server event with a fresh timestamp on a later batch job, pushing it outside the 48-hour window so Meta never pairs it.

To check your own deduplication:

1. Open Events Manager, pick the Purchase event, and look at the event detail. Meta reports how many events it received from the browser versus the server, and how many it deduplicated.
2. If “server” and “browser” counts are both high but the deduplicated count is near zero, your event_id isn’t shared. Meta is counting each sale twice.
3. If the server count is near zero, your server events aren’t arriving at all, and CAPI isn’t doing anything.

Match quality: why events arrive and still get dropped

Match quality is Meta’s measure of how well it can tie a server event to a real person using the customer information you send. Every CAPI event should carry hashed identifiers: email, phone, name, and click identifiers like fbc (from the ad click) and fbp (the Pixel cookie). Send too few, and Meta can’t match the event to an account, so it’s dropped from attribution even though it technically arrived.

Meta scores this in Events Manager as Event Match Quality (EMQ), rated from poor to great per event. Server events often score worse than the Pixel because the browser passes cookies and click IDs automatically, while your server has to be told to collect and forward them. The fix is to capture fbc and fbp from the browser at conversion time, hash email and phone with SHA-256 before sending, and pass them in the server payload. A server event with only a purchase value and no customer parameters is close to useless: Meta receives it and can’t attribute it.

This is the same gap that makes a firing pixel report the wrong sales. A hit can leave the browser and still carry nothing Meta can act on, which is why our guide to a Facebook pixel check argues that “it fired” and “it worked” are different claims.

CAPI won’t fix Meta over-reporting

Worth saying plainly, because vendors imply otherwise: CAPI cleans up how events reach Meta, but it does nothing about how Meta attributes them. Meta still credits view-through conversions (someone who saw an ad but never clicked) and still fills tracking gaps with modelled estimates. So even a perfect CAPI setup can leave Ads Manager claiming sales your store never confirmed.

The scale of that gap surprises people. In one audit of a subscription box brand, Meta’s dashboard claimed 6.9 times the revenue Shopify actually recorded on the same ad spend, and most of the claimed purchases came from shoppers who saw an ad but never clicked it. CAPI wouldn’t have changed that number. Only reconciling Meta’s claimed conversions against last-click orders in your commerce platform gives you a figure you can plan spend against. Clean signal and honest attribution are two separate problems, and CAPI solves only the first.

A CAPI setup that actually reports correctly

Pulling it together, a Meta Conversions API setup you can trust does five things:

• Runs the Pixel and CAPI together, not one instead of the other, so the two sources deduplicate against each other.
• Shares one event_id per conversion across the browser and server events, generated once at the moment of purchase.
• Sends rich customer parameters on every server event: hashed email and phone, plus fbc and fbp, so match quality stays high.
• Verifies deduplication in Events Manager, not just that events arrive, by checking the deduplicated count is doing real work.
• Reconciles Meta’s numbers against your order data rather than trusting the dashboard, because CAPI never touches view-through inflation.

Miss any of the first three and CAPI under-reports. Skip the last two and you won’t know whether the number in front of you is real.

Not sure whether it’s your CAPI setup or the tracking underneath?

If your Meta reporting looks off and you can’t tell whether it’s a deduplication fault, a match-quality problem, or Meta doing what Meta does, a tracking audit finds out. We do this reconciliation work for clients most weeks: in one Meta audit, 71% of ad-claimed conversions never clicked the ad, and view-through counting, not CAPI, was the story. You can run a free first-pass scan of what’s firing on your site with Sonar, our free tracking checker, or use the tell us what’s broken, or book a call. Clean signal is the start; numbers you can spend against are the point.