Attribution Leak
Calculator
Your ad platforms optimize on the purchases they can see. Enter what they report, what your store actually took, and how your tracking is wired. You get the attribution gap, the real cost per purchase, the most likely cause, and the three things to check in Events Manager before you touch a campaign. Runs in your browser; nothing is sent anywhere.
By Daria Dovzhikova · Updated October 2026
Needs at least one platform with spend and the actual purchase count.
Methodology
Two of the outputs are arithmetic on your inputs. One is an estimate with a single exposed assumption. The page keeps them apart on purpose.
reported_total = sum of purchases each platform reports
actual = purchases in the order of record, same window
gap_share = 1 - reported_total / actual (when reported < actual, under-reporting)
over_report = (reported_total - actual) / reported_total
(when reported > actual, duplicates or multi-claim)
aligned = within 5% either way
reported_cpa = total_spend / reported_total
real_cpa = total_spend / actual
reported_roas = reported_total * aov / total_spend
real_roas = actual * aov / total_spend
steered_spend = wrong_signal_share * total_spend * misallocation_factor
wrong_signal_share = gap_share or over_report
misallocation_factor = your assumption, default 25%Why the last line is an assumption and not a statistic: no ad platform publishes how much worse its delivery gets per missing conversion, and any number claiming to be that figure is someone's guess dressed up. The calculator makes the guess visible and lets you set it. The default of 25% says: of the spend being steered by a signal that cannot see a quarter of your sales, assume a quarter of that spend lands in the wrong place. Set it to 0 to see the arithmetic without it.
Per-platform real cost per purchase is deliberately absent. Your order of record knows how many purchases happened; it does not know which platform earned each one, and a tool that pretended otherwise would be inventing attribution. The blended real CPA is the honest number. If you want per-platform truth, that is a measurement project: server-side events, deduplication, and a reporting view finance will accept, measured on match rate and attributed revenue before and after.
Deduplication mechanics and Event Match Quality follow Meta's own documentation: deduplicating pixel and server events (same event_name and event_id on both paths) and about Event Match Quality. The cause ranking is pattern-matching on your inputs, in the order these problems turn up in audits, and it is a starting list rather than a diagnosis.
What the number means
Under 10% either way. Measurement is fine. If you have a problem it is in attribution windows, campaign assignment, or a platform claiming credit for organic sales, and the counts alone will not show it.
10% to 40% under-reported. The normal shape of a browser-only or half-wired setup. Signal loss from blockers, consent, and cross-domain handoffs. The fix is a server path with real match keys and deduplication, and it is a four-week job, not a quarter.
Over 40% under-reported. Something is broken, not tuned. A dead pixel ID, a Conversions API that never connected, a checkout migration that removed the purchase event. One root cause explains most of it. Find that before touching parameters. A DTC hardware brand we audited was at 95%: 151 purchases on the store, 7 in Meta, a Conversions API returning API_unavailable, a cross-domain event-id mismatch between the WordPress site and the Shopify checkout, and 28 unverified domains on the pixel. The reported cost per purchase was $2,440. The real one was somewhere between $700 and $1,200.
Any amount over-reported. Duplicates. Fix the event_id before anything else, or every optimization decision is made on a doubled number. Read the 2026 Shopify tracking rebuild guide for the order of operations.
FAQ
What is an attribution gap?
The difference between the purchases your ad platforms report and the purchases in your order of record for the same window. A Shopify store that took 150 orders while Meta Ads Manager shows 40 has a 73% gap. The platform is optimizing delivery on the 40 it can see, so the money follows a signal that misses most of what you sold.
Why does Meta report fewer purchases than Shopify?
Signal loss between the browser and Meta. Ad blockers and iOS privacy settings stop the browser pixel; a declined consent banner stops it by design; a checkout that renders the confirmation without a page load never fires the purchase event; a marketing site on one domain and a checkout on another drops the click ID at the handoff. Each one removes a slice of purchases from what Meta can count, and the slices add up.
Why does Meta report more purchases than Shopify?
Duplicate events. When the browser pixel and the Conversions API both send the same purchase without a shared event_id, Meta counts it twice. Adding up several platforms causes the same effect at a different level: Meta, Google, and TikTok each claim the purchases they touched, so the sum of platform reports exceeds real orders even when each platform is honest.
What is Event Match Quality?
Meta's 1 to 10 score for how well the customer parameters on a server event (hashed email, phone, external ID, click ID, browser ID) let Meta match the event to a person. Events that arrive with too few parameters can be received and still count for nothing because they match nobody. Meta's Events Manager shows the score per event, with the parameters it is missing.
Does the Conversions API fix the gap?
Only when it is actually delivering events with match keys and the browser and server paths are deduplicated. An integration that exists in a settings screen but sends nothing, sends events without an email or phone, or double-counts with the pixel can leave the gap the same size or make it worse. The connection method column in Events Manager tells you which of the three you have.
What is deduplication?
The rule Meta uses to keep a purchase sent twice, once from the browser and once from the server, from counting twice. Both events carry the same event_name and the same event_id, generated once per order at the source, and Meta keeps one. Missing or mismatched event_ids are the most common cause of reported purchases exceeding real orders.
What does the Meta Pixel Helper show that Events Manager does not?
The Pixel Helper browser extension shows what the pixel fires on a page in real time: which events, which parameters, and which errors. It is the fastest way to confirm that a purchase event fires on the confirmation page at all, and whether it carries an event_id. Events Manager shows what arrived at Meta; the Pixel Helper shows what left the browser.
How accurate is the estimate?
The gap percentage and the real cost per purchase are arithmetic on your own numbers and are as accurate as the numbers you enter. The steered-spend figure is an estimate built on one adjustable assumption, the share of wrong-signal spend that ends up misallocated, and it says so on the page. Treat it as an order of magnitude, then measure it properly.
From estimate to measurement
Measure it instead of estimating it.
A measurement project reads your Events Manager, your order of record, and your event layer, ships server-side events, deduplication, and a reporting view finance will accept, and re-measures on match rate and attributed revenue. For a developer-tool or AI-product team, that can be one of the two experiment cards in a four-week Growth Pilot.
The GTM Labs Newsletter
Developer-first growth, monthly.
One short, useful essay per month on developer marketing, AI-powered growth, and what's actually working in 2026. Unsubscribe anytime.