Ask a store owner whether their tracking is accurate and you'll get a feeling. "Pretty good, I think." Feelings don't survive contact with a spreadsheet. Accuracy is a number, and you can compute it this afternoon with your store admin and two reporting tabs.
- Pick a clean 7-30 day window — No migration, no checkout change, no flash sale with refunds still settling
- Pull the backend truth — Order count and revenue from your store admin or CRM, test orders and refunds stripped
- Pull captured events, not attribution — GA4 purchase event count and Meta Events Manager Purchase events received
- Divide, twice — Captured over actual, times 100 - run counts and revenue separately, they fail independently
- Read the band — 412 captured against 460 real orders is 89.6%: leaking, not structurally broken
How do you measure conversion tracking accuracy?
You compare what your platforms recorded against what actually happened, in the same window, and express it as a percentage. The formula is just captured ÷ actual × 100. The work is in pulling the right two numbers; most people pull the wrong ones.
- Pick a clean period. 7 to 30 days. No site migrations mid-window, no checkout changes, no huge flash sale with a refund wave still settling. 30 days smooths out noise; 7 days is fine for high-volume stores.
- Pull the backend truth. Orders from your Shopify or WooCommerce admin, leads from your CRM. Get the count and the revenue. This is reality. Everything else gets measured against it.
- Pull what each platform captured in the exact same date range: GA4
purchaseevent count, Meta Events ManagerPurchaseevents received, your Google Ads conversion action count. Raw capture, not attribution (more on that trap below). - Divide. 412 purchases captured in GA4 against 460 real orders is 89.6% accuracy. Do it once for counts, once for revenue.
That's the whole method. One afternoon, one spreadsheet row per platform.
Where does the "actual" number come from?
From the system that money or leads actually flow through, never from an analytics tool. For ecommerce that's the orders screen in your platform admin; for lead gen it's the CRM. Before you count, clean it: strip test orders, strip canceled and fully refunded orders, and note whether your revenue figure includes taxes and shipping. You're building the denominator. If the denominator is dirty, every percentage downstream is fiction.
| Ads Manager columns | Events Manager totals |
|---|---|
| Attributed conversions only | Purchase events received, raw |
| Reported by click date, not sale date | Browser and server, deduplicated |
| Capped by the attribution window | Counted on the day they happened |
| Blind to untracked channels | Comparable to your order list |
| Always looks like undercounting | This is the capture number |
What number do you pull from GA4 and Meta?
You pull captured events, not attributed conversions, and this is where most self-audits go wrong. Attribution answers "which ad gets credit?" Capture answers "did the platform even see the sale?" Accuracy is a capture question.
In GA4, use the raw purchase event count from the Events report or an Exploration, not the Advertising workspace. In Meta, open Events Manager, select your pixel/dataset, and read the Purchase events received for your window. That's the deduplicated total of browser and server events the dataset ingested. Do not use Ads Manager conversion columns for this.
| Stage | What happens |
|---|---|
| Real orders in your admin | The denominator every ratio is measured against |
| 95%+ healthy | Residual loss only; re-check quarterly |
| 85-95% leaking | Ad blockers, consent banner, fragile page triggers |
| Below 85%, structurally broken | Tags missing real checkout paths entirely |
What does your accuracy percentage actually mean?
The bands are pretty consistent across the audits I run, and each one points to a different class of problem.
| Accuracy | Verdict | What's usually going on |
|---|---|---|
| 95%+ | Healthy | Normal residual loss (hard opt-outs, edge cases). Maintain and re-check quarterly. |
| 85–95% | Leaking | Ad blockers eating browser tags, consent banner suppressing events, fragile thank-you-page triggers missing some checkouts. |
| Below 85% | Structurally broken | Tags not firing on real purchase paths, broken dataLayer, an express-checkout or redirect flow that skips your trigger entirely. |
| Above 100% | Also broken | Overcounting: deduplication failure, refire on page refresh, test events polluting production. |
Notice the last row. People assume more conversions means better tracking. 118% accuracy means Meta is optimizing on phantom purchases, and that's just as expensive as missing real ones. This banding is also why an accuracy guarantee is even possible: accuracy isn't a vibe, it's a measurable ratio, so you can hold a setup to a floor and verify it.
How do you diagnose your specific number?
Match the symptom, not the number alone.
Undercounting (below 100%). The event dies somewhere between the buyer's browser and the platform. The usual suspects, in the order I check them: ad blockers silently killing the pixel request, the consent banner blocking tags for everyone who doesn't click accept, and thank-you-page triggers that miss buyers who close the tab early, pay through PayPal's redirect flow, or land on a confirmation URL your trigger doesn't match.
Overcounting (above 100%). Almost always deduplication failure. If you send a browser pixel event and a server event for the same purchase, they need a shared event_id so Meta can merge them; without it, every sale counts twice. Also check for purchase tags that refire when someone refreshes or revisits the confirmation page, and for staging or test events flowing into the production dataset.
Counts fine, revenue off. A value mismatch. One system reports revenue with taxes and shipping, the other without. Currency mismatch on multi-currency stores. Refunds subtracted in the backend but never in the platform. Run the count ratio and the revenue ratio separately, because they fail independently and point at different bugs.
What mistakes ruin the measurement itself?
Three mistakes produce a wrong accuracy number, and I see them in almost every DIY audit.
- Comparing attributed conversions to orders. Ads Manager or the GA4 Advertising view against your order list is apples to oranges. Attributed numbers are a subset by definition, so this "audit" always screams undercounting even when capture is fine.
- Ignoring test orders and refunds. Your dev's $1 test orders inflate the platform side; refunds you removed from backend revenue but not from GA4 deflate the ratio. Clean both sides the same way.
- Time-zone offsets. Your Shopify store on America/New_York, GA4 property on UTC, ad account on something else. A "same" 7-day window can be shifted by hours on each side, enough to fake a few points of error on a small store. Align the time zones, or use 30 days so the edges matter less.
Which fixes match each accuracy band?
Once you have a trustworthy number, the fix follows from the band. Above 100%: fix deduplication first, usually by making the browser and server events share an event_id, then kill refresh-refires. Below 85%: the plumbing is wrong, so audit triggers and the dataLayer on every real checkout path before touching anything else, because no amount of signal recovery rescues a tag that never fires. And 85–95%, the most common band? That leak is mostly losses your browser-only setup can't prevent, which is where the architecture itself has to change.
Why does first-party server-side tracking move you into the high 90s?
Because it removes the single biggest cause of the 85–95% leak: depending entirely on a script in the buyer's browser. Plain language version: today your Meta Pixel and GA4 tag run on the buyer's device and send data to third-party domains like facebook.com. Ad blockers block those requests, Safari's tracking protections cap their cookies, and a declined consent banner stops them cold. Server-side tracking adds a small server you control, on your own subdomain (something like track.yourstore.com), built on Google Tag Manager's server container. Purchase data flows from your site to your server, and your server forwards it to Meta, Google, and TikTok.
For accuracy specifically, that changes four things. Requests to your own subdomain are first-party, so the blockers that kill facebook.com requests mostly don't touch them, which recovers the conversions your ratio said were missing. Cookies set server-side on your domain live longer under Safari's ITP limits, so returning buyers stay recognizable instead of looking like fresh anonymous visitors. Every platform gets fed from one server source of truth with proper event_id deduplication, so overcounting largely disappears along with undercounting. And because your server decides exactly what gets shared, per consent, you stay compliant without going dark. This is the mechanism behind the bands: browser-only setups plateau in the 80s because the losses are outside your control, and first-party server-side capture is what moves the same store into the high 90s, where the ratio stops being a problem you think about.
Frequently asked questions
What is a good conversion tracking accuracy percentage?
95% or higher is healthy; a well-built first-party server-side setup typically runs around 98%. Between 85% and 95% you're leaking recoverable signal, and below 85% something in the setup is structurally broken.
How do I check if my Meta Pixel is tracking all purchases?
Compare the Purchase events received in Events Manager for a 7–30 day window against real orders in your store admin for the same window. Use Events Manager's raw event counts, not Ads Manager's attributed conversion columns.
Why does Ads Manager show fewer conversions than Shopify?
Partly because some events never get captured, but mostly because Ads Manager only shows conversions attributed to your ads within the attribution window, reported by click date. It will always show fewer than total orders, which is why it's the wrong tool for measuring accuracy.
Can conversion tracking show more conversions than I actually got?
Yes, and it means the setup is broken, not generous. Accuracy above 100% is almost always a deduplication failure between browser and server events, purchase tags refiring on page refresh, or test events polluting production data.
How often should I re-check my tracking accuracy?
Quarterly as a baseline, plus after anything that touches the checkout: a theme change, a new payment method, a consent banner update, or a platform migration. A one-hour spot check catches leaks months before the ad performance makes them obvious.
Does server-side tracking make conversion tracking 100% accurate?
No. Some loss always remains from hard opt-outs and edge cases, which is why realistic targets are ~98% typical and 95%+ guaranteed, not 100%. Anyone promising perfect tracking is measuring it wrong.
Should I measure accuracy on conversion counts or revenue?
Both, separately. Counts and revenue fail independently: a store can capture 97% of purchases while misreporting value on every one of them through currency, tax, or refund mismatches.
- accuracy
- tracking audit
- data quality
WhatsApp