Facebook Ads vs Shopify Orders Don't Match: The Fix | Clikim
Home  /  Blog  /  Meta vs Shopify Numbers
By Yael Rachmut · Attribution truth · Updated July 2026 · 11 min read

Meta Says 105 Purchases. Shopify Says 30. Who's Lying?

Nobody — but one of you might be double counting. The two-minute dedup check that forks every diagnosis, the nine causes sorted by gap size and direction, the honest 'how far apart is normal' answer, and a 70-minute worked cleanup of the classic 105-vs-30 case.

Facebook ads purchases don't match Shopify orders — diagnosis
QUICK ANSWER

Check one number first: the Purchase dedup rate in Events Manager. Under 80% means you’re double-counting — fixable in an hour with a shared event ID. At 95%+ your tracking is fine and the gap is attribution: Meta reporting 10–25% more than Shopify is normal, because they count different things on different clocks.

DEDUP <80% = DOUBLE COUNT 95%+ = HEALTHY +10–25% GAP IS NORMAL DIFFERENT CLOCKS

Key takeaways
One check first: Purchase dedup rate in Events Manager.
Under 80% = double counting; a shared event_id fixes it in an hour.
They will never match — different definitions, different clocks.
Meta 10–25% above Shopify with clean dedup is normal.
Attribution reports purchases on the click’s date, not the sale’s.
Reconcile monthly with one window — not daily screenshots.

The two-minute check that settles most cases

Dedup rate is the fork in the road — everything else in this guide depends on which branch you're on.

Dedup rate is the fork in the road — everything else in this guide depends on which branch you're on.

The forum version of this problem ("Meta shows 105 purchases, Shopify shows zero — is Facebook stealing from me?") almost always skips the one diagnostic that separates broken from normal: the deduplication rate. Meta receives your Purchase event twice by design — once from the browser pixel, once from the Conversions API — and merges the copies using a shared event_id. When that merge works (95%+ dedup rate), every real order counts once. When it doesn't — no event_id, mismatched IDs, or a third sender nobody remembers installing — every order counts twice, and your dashboard inflates toward that mythical 105. Meta's own deduplication documentation covers the mechanics; the operational summary is simpler: the fix is sending the order ID as the event_id from both sides, and the verification is watching browser+server rows merge with a checkmark in Test Events.

The three mismatches (and which one you have)

Gap size and direction diagnose the cause — treat the branch you're actually on.

Gap size and direction diagnose the cause — treat the branch you're actually on.

Cause
Direction
The tell
The fix
Missing event deduplication
Meta way HIGH (up to 2x)
Dedup rate <80% in Events Manager; browser+server rows both full
Same event_id (use the order ID) on pixel AND CAPI
Legacy pixel code in theme
Meta HIGH
Two browser Purchase events per checkout in Test Events
Remove old snippets; ONE integration owns each event
Multiple apps firing Purchase
Meta HIGH
Shopify channel + tracking app + manual pixel all installed
Audit app inventory; disable duplicate senders
Attribution windows
Meta high by 10-30%
Purchases 'arrive' days after the order (a Jul 3 click, Jul 9 order, reports on Jul 3)
Nothing — this is definitional; compare cohorts, not days
View-through & engage-through
Meta high
Conversions with zero clicks anywhere
Report click-only columns when reconciling
Repeat-customer multi-touch
Meta slightly high
Same customer, two ads, one order — both may claim it
Use first-conversion columns for reconciliations
Modeled conversions
Meta high
Small account, iOS-heavy traffic
Sanity-check against MER monthly
No CAPI / blocked pixels
Meta LOW
Browser-only events; EU/iOS-heavy traffic
Add Conversions API with match keys
Refunds & cancellations
Meta high over time
Meta never subtracts refunds; Shopify does
Reconcile net revenue monthly, not per-order

Direction is diagnostic: 2-3x high = duplication (fixable), modestly high = attribution (definitional), low = signal loss (fixable). Most panicked threads conflate all three.

The part nobody says out loud: they're answering different questions

Shopify's order count answers "what happened in my store?" Meta's purchase count answers "what do I estimate my ads caused, under my attribution settings?" Those are different questions and their answers differ legitimately: a customer who clicked your ad Tuesday and bought Friday is a Friday order in Shopify and a Tuesday conversion in Ads Manager (purchases report on the click's date — which alone destroys every day-level comparison). A customer who saw-but-didn't-click and bought within a day is a view-through conversion Meta claims and Shopify can't see the reason for. A repeat buyer who engaged with two campaigns may be claimed by both in some views. And on iOS traffic, part of Meta's number is modeled — a statistical estimate of conversions it can no longer observe directly. Stack those legitimacies and a clean, well-deduplicated account still reports 10–25% more purchases than the store most months. That's not fraud; it's epistemology. The number to escalate about is 2–3x — that's never attribution; that's duplication.

The full 10-minute audit, in order

1. Dedup rate (Events Manager → Purchase): under 80% → fix event_id and stop here; the rest is noise until this is clean. 2. Sender inventory: list everything that can fire Purchase — Shopify's channel app, any tracking app, manual pixel code, GTM containers, old theme snippets. One integration owns the event; disable the rest. (After Shopify's checkout-extensibility migration, "the old snippet still in the theme" became the classic silent double-counter.) 3. Test purchase: Test Events tab open, buy something cheap, watch for exactly one merged Purchase with browser+server icons. 4. Attribution accounting: switch reconciliation reports to click-only columns and compare cohorts (a week of clicks vs the orders those clicks produced) rather than calendar days. 5. Direction check: if Meta is below the store, the problem inverts — you're losing signal (no CAPI, pixel-only setups, consent banners, ad blockers) and delivery optimization is starving; the fix is server-side events with real match keys, not reporting hygiene. 6. Monthly truth: whatever the dashboards say, reconcile net revenue and blended MER once a month — the number that survives refunds, definitions and modeling. This audit catches the 2026 wrinkle too: after the January and March definition changes, older comparisons broke — any reconciliation crossing those dates needs rebaselining first.

The third witness: what GA4 adds to the argument

Once Meta and Shopify are reconciled, many operators pull in GA4 and reopen the panic — because GA4 shows a third number, usually the lowest of all. That's expected: GA4 runs last-click attribution by default, loses cross-device journeys the platforms model, undercounts everything consent banners and tracking prevention eat, and books conversions on the order's date rather than the click's. The triangle is stable in a healthy account: Shopify highest fidelity on WHAT happened, Meta highest (and premium-priced) on WHAT ADS CAUSED, GA4 lowest but most neutral on the journey. Escalate only when the triangle's shape changes suddenly — a corner moving alone is a tracking event, all three moving together is a business event. The full three-way framework gets its own guide shortly; for reconciliation purposes, two witnesses (store + dedup-clean Meta) are enough.

Worked example: 105 vs 30, dissected

The composite behind a hundred threads: a home-goods store, new to Meta, sees 105 purchases in Ads Manager against 30 Shopify orders for the same week. Audit: dedup rate 51% — the store runs Shopify's Meta channel app AND a tracking app AND a theme snippet from a 2024 tutorial, three senders with no shared event_id. Cleanup (channel app keeps Purchase; app's duplicate sender disabled; snippet deleted) drops the report to 41. Still 37% over — cohort analysis explains the rest: 6 view-through conversions, 3 window-timing artifacts from the prior week's clicks, 2 modeled. Final steady state: Meta ~36-38 against 30 store orders — a 20-25% definitional premium the owner now understands instead of fears. Total fix time: 70 minutes. The panic had lasted three weeks. Postscript worth noting: the store's CPA reporting stabilized within a fortnight of the fix — not because performance changed, but because delivery stopped learning from phantom purchases, and budget decisions stopped being made against a dashboard that priced conversions at half their real cost.

Count once, then let the definitions differ — reconciliation is a monthly discipline, not a daily argument.

Count once, then let the definitions differ — reconciliation is a monthly discipline, not a daily argument.

Why media buyers run on Clikim
9,800+
accounts under management
$490M+
in ad spend processed
<3 min
average rep reply
0%
top-up & spend fees
Trusted by 1,200+ media buyers scaling 7–8 figures on whitelisted Meta & TikTok accounts.

Frequently asked questions

Why does Facebook show more purchases than my Shopify store?+
Two families of causes: duplication (pixel + CAPI + apps firing Purchase without a shared event_id — dedup rate under 80% confirms it) and attribution (windows, view-through, repeat-buyer multi-touch, modeled iOS conversions — all definitional). Gap size tells you which: 2–3x is duplication; 10–25% is normal attribution premium.
What is a normal difference between Meta purchases and Shopify orders?+
With clean deduplication, expect Meta to report roughly 10–25% more than the store most months — attribution windows, view-through credit and modeling account for it. The premium also varies by mix: retargeting-heavy and iOS-heavy accounts sit at the top of the range. Consistently beyond ~40%, audit duplication; Meta below the store, audit signal coverage.
Where do I check my deduplication rate?+
Events Manager → your dataset → the Purchase event → deduplication details. It shows what share of browser/server pairs merged. 95%+ is healthy; under 80% means real double counting is reaching your reports and optimization.
What should I use as the event_id?+
The order ID — it's unique per purchase and, critically, identical on both the browser and server side of the same order, which is exactly what the merge needs. Random per-side UUIDs are the classic silent failure: valid IDs that never match.
Why do purchases show on days when I got no orders?+
Because conversions report on the CLICK's date, not the order's date. A Tuesday click that converts Friday is a Tuesday conversion in Ads Manager and a Friday order in Shopify. Day-level comparisons are structurally meaningless — reconcile weekly cohorts instead.
Meta shows FEWER purchases than Shopify — same problem?+
Inverted problem: signal loss rather than inflation. Browser-only tracking loses iOS users, ad-blocker users and consent-rejectors; other channels also drive orders Meta rightly doesn't claim. Fix the first part with Conversions API + real match keys; accept the second.
Can duplicate events hurt performance, or just reporting?+
Both — optimization learns from the events it receives, so double-counted purchases teach delivery that conversions are cheaper and more common than reality. Accounts often see steadier CPAs within weeks of fixing dedup, independent of the reporting cleanup.
How do I find every source firing the Purchase event?+
Inventory: Shopify's Meta channel app, tracking apps (Elevar-class), manual pixel code, GTM containers, and old theme snippets. Then verify empirically: one test purchase with the Test Events tab open — you should see exactly one merged Purchase. Extra rows name your culprit.
Did Shopify's checkout changes cause my duplicates?+
Frequently — the checkout-extensibility migration rebroke many setups: the new integration fires alongside a forgotten legacy snippet or an app's parallel sender. Post-migration stores should re-run the one-test-purchase verification even if 'nothing changed.'
Do refunds explain part of the gap?+
Over time, yes: Meta never subtracts refunds or cancellations; Shopify's net numbers do. On a 5-10% refund rate this quietly widens the monthly gap — one more reason reconciliation runs on net revenue, not order counts.
Which number do I actually optimize and report from?+
Platform number for in-platform decisions (it's what delivery learns from), store/net revenue + blended MER for money decisions and reporting. The reconciliation isn't about crowning one number — it's about knowing each number's job.
Did the 2026 attribution changes affect this comparison?+
Yes — January 12 removed long windows and March 3 narrowed click definitions, shrinking Meta's reported side. Any reconciliation crossing those dates compares different yardsticks; rebaseline first or you'll chase ghosts.
Is Triple Whale / an attribution tool the answer?+
They add a third opinion, not the truth — useful at scale for triangulation, but they disagree with both Meta and GA4 by design. Fix dedup and learn the definitional gaps first; a $300/mo tool on top of broken event_ids just charts the breakage prettily.
How often should I re-verify all this?+
One test purchase after ANY change to checkout, apps or pixels; a dedup-rate glance monthly; full reconciliation (cohorts, net revenue, MER) monthly. Tracking rots at the speed of app updates — the checks are cheap, the drift isn't.
Does double counting affect my billing or just my reports?+
Reports and optimization only — Meta bills for impressions and clicks delivered, not per conversion, so duplicated purchases never charge you directly. The indirect cost is real though: inflated conversion signals push delivery and budget decisions toward audiences that look cheaper than they are, and every scaling call made on a 2x-inflated CPA is a mispriced bet.
My agency says the gap is 'just iOS' — is that a sufficient answer?+
It's a partial answer at best. iOS modeling explains a slice of the definitional premium, but it can't explain a 2-3x gap (that's duplication), a Meta-below-store gap (that's signal coverage), or day-level mismatches (that's click-date reporting). Ask for the dedup rate and a one-purchase Test Events verification before accepting any one-word diagnosis.

Clean signal, steady accounts

Whitelisted infrastructure — stable rails under your tracking, headroom over your scaling, replacement cover when reviews misfire.