Why Facebook Ads conversions don't match Shopify

Facebook and Shopify almost never report the same number of conversions, and usually that's fine: each counts something different. Here's how to tell a normal gap from a broken one, and how to fix the five things that cause a bad one.

Kay Vink
Kay Vink

You line up Facebook Ads against Shopify, the sale counts don't match, and you go looking for the bug. Usually there isn't one. Facebook counts every sale it believes its ads influenced, inside a window it picks, including people who only saw an ad and never clicked. Shopify counts the sales that actually happened. Two different questions produce two different numbers, and no setup will ever make them match.

So the job isn't to make them match. It's to tell a normal gap from a broken one, and the gap itself tells you which: how big it is, and whether Facebook is higher or lower than Shopify. Below, you'll see what a healthy gap looks like, then the five things that break it, each with a quick check to confirm it's yours and the fix.

#What each system actually counts

Different questions produce different numbers, permanently. Meta's count answers "how many orders did my ads influence, by my rules": it attributes within the campaign's window (7-day click / 1-day view is the common default), includes people who saw but never clicked, and books the conversion to the day of the click or view, not the order. Shopify answers "how many orders exist": no windows, no attribution, order date. Even a flawless setup reports Meta ≠ Shopify, and any tool promising a perfect match is wrong. This is the platform-side overcount logic explained fully in Every platform claims the same conversion: why ad platforms overreport; here we only need it as a baseline.

#The expected gap: when a mismatch is normal

Before you panic, a rule of thumb: a 15% to 30% Meta overclaim versus your own last-click orders is the attribution machine working as designed, not a bug. View-through and window overlap do exactly this to any store running real retargeting.

Seeing the counts side by side makes the baseline concrete. Per 100 Shopify orders, a healthy store tends to produce something like this:

SourcePer 100 Shopify ordersWhy
Shopify orders100the business truth
Server path (CAPI)~95recovers most browser loss
Browser pixel~75ad blockers, ITP, consent
Meta ad-attributed~55only the orders its window claims

Illustrative counts; the ordering is the point, not the exact numbers. Four lanes, four different numbers, none of them broken.

What is never normal: a stable ratio that jumps overnight. Ratios move when tracking changes, not when customers do.

#Failure mode 1: pixel + CAPI double counting (the flagship)

If Meta roughly doubled when CAPI went live, it's dedup. The pixel reports the purchase from the browser; CAPI reports it from the server; Meta only collapses the pair when both carry the same event_name and event_id, an exact string match, per Meta's deduplication documentation. Miss the contract and every purchase counts twice while every individual component shows green.

The check: Events Manager → Purchase event → the overlap/dedup view: server events should show as deduplicated against browser events. Then fire one test purchase through the Test Events tool and read both payloads: same event_id, same casing, same event_name. The four specific ways the contract breaks (missing ID one side, format/casing drift, late server events, missing browser event) are dissected in Meta conversion tracking end to end: pixel, CAPI, and events that dedup; the decision context for the two transports is Conversions API vs the Meta Pixel: what actually changes.

The fix: one shared ID minted at event time and passed to both transports. On Shopify, the native Meta integration handles this. The double-count usually comes from a second pixel, or a custom CAPI bolted on top of it. One integration owns the purchase event; remove or demote the rest (the same one-primary doctrine as Shopify and Google Ads conversion tracking without double counting, different dashboard).

#Failure mode 2: attribution window and view-through inflation

A 7-day-click/1-day-view Meta compared against Shopify's daily orders inflates structurally: conversions from last week's clicks land on those click days, and view-through adds orders no click ever touched. The check: in Ads Manager, use Compare attribution settings to split 1-day-click vs 7-day-click vs view-through. If the gap concentrates in view-through or the long window, nothing is broken; you're reading an optimization signal as if it were bookkeeping. The fix: align the comparison (1-day-click vs same-day orders gets closest), and report Meta's number as attributed influence, never as order count.

#Failure mode 3: date and timezone cuts

Meta books to click/view date in the ad account's timezone; Shopify stamps order date in the store's timezone. A store on UTC with an ad account on America/New_York guarantees daily mismatches that vanish over a week. The check: compare 7- and 30-day totals instead of days; if the gap collapses, it was calendar math. The fix: align account timezones where you can; compare rolling windows where you can't.

Ad blockers, ITP, and consent denials stop the pixel; CAPI recovers some of it (that's its job), but consent applies server-side too: denied is denied on both transports. The result: Meta undercounts relative to Shopify, concentrated in consented-out regions and privacy-forward browsers. The check: browser-vs-server event ratios in Events Manager, split by region; a Safari-heavy or EEA-heavy gap that stepped after a banner change is consent, not performance. The fix: correct consent wiring per Consent Mode v2 without losing your signal, keep CAPI healthy, and accept the unrecoverable slice as measured reality.

#Failure mode 5: test events, duplicate pixels, staging noise

The simple mistakes, checked last because they turn up in minutes: a test event code left in production, a staging store firing purchases, two pixel IDs installed (theme + app + GTM), or a dev's "let me just fire a test purchase" habit. The check: Events Manager shows every pixel ID and source sending events; audit the list, and you should recognize everything on it. The fix: one pixel ID, test codes stripped, staging domains excluded.

#The 10-minute diagnosis

#Verify the fix, then stop re-running this page

Prove it with one order: a test purchase through Test Events showing one browser event, one server event, one counted conversion, then a week of the Meta-vs-Shopify ratio sitting back in its band. The recurring version of these checks (dedup, values, consent, platform status) is The conversion tracking QA checklist: test it like you'd test code. Run it on every theme, app, or banner change, because each of those is how this page's failure modes get reintroduced.

#This isn't really a Facebook problem

Here's the part worth keeping once this particular gap is closed: almost none of it was really about Facebook and Shopify. Two systems answering different questions, a gap that stays normal until a short list of things breaks it, is also how Google Ads disagrees with GA4, how TikTok disagrees with your store, how nearly any two tools in your stack disagree. You didn't fix a Facebook problem. You learned to read a whole class of them.

That turns reconciliation from a recurring fire drill into a habit: glance at the ratio once a week, and while it sits in its band, you're done. The only hard part is remembering to look, which is exactly the part worth handing off. Connect your store to Buron and it watches your pixel, server events, and Shopify orders side by side, so the day the ratio breaks you get a dated alert in your Findings inbox instead of a "why did ROAS double?" three weeks later. [Connect your store →]

Frequently asked questions

Why does Facebook show more conversions than Shopify?

Because Meta counts attributed conversions, meaning every order its ads touched within the attribution window, view-through included, while Shopify counts orders. A moderate overcount is structural. A sudden 2x is different: that's usually a deduplication miss, with the pixel and Conversions API both counting the same purchase.

How does Meta deduplicate pixel and CAPI events?

By exact match on two fields: when a browser event and a server event arrive with the same event_name and event_id, Meta keeps one and discards the duplicate. If either side omits the ID, or the values differ even by casing, both events count, which is why dedup breaks show up as overnight conversion jumps.

Which number is right, Meta or Shopify?

Neither is wrong. They answer different questions. Shopify's order count is the business truth: how many orders exist. Meta's conversion count is an optimization signal: how many orders its window claims. Use Shopify (or your warehouse) to count, Meta to steer delivery, and never sum platform dashboards.

Should I turn off the Meta pixel now that I have the Conversions API?

No. The pixel and CAPI are complementary layers: the pixel carries browser context and feeds match quality; CAPI recovers what browsers block. Turning either off loses signal. The correct move is running both with deduplication verified in Events Manager, not choosing between them.

Related