The Complete GA4 Ecommerce Accuracy Checklist

Most marketing teams find out their GA4 ecommerce data is wrong only after they've already shifted budget based on it. GA4 ecommerce tracking accuracy isn't a one-time setup task — it's a set of checks that degrade silently as your site, tag manager, and ad platforms change. This checklist covers the seven areas most likely to be quietly inflating or deflating the revenue numbers you're using to judge ROAS.

Key takeaways

• GA4's default attribution and session logic can create legitimate-looking revenue numbers that are still wrong — accuracy has to be verified, not assumed.
• Duplicate purchase events are one of the most common causes of overstated revenue, often from a GTM tag firing on page refresh or back-button navigation.
• Safari and iOS traffic frequently under-report purchases due to Intelligent Tracking Prevention (ITP) capping cookie lifespan, which skews attribution rather than eliminating it entirely.
• Refunds are not tracked automatically in most GA4 implementations — without a dedicated refund event, revenue stays inflated indefinitely.
• ROAS mismatches between GA4 and ad platforms like Meta are usually attribution-model differences, not tracking errors, but the two causes require completely different fixes.

Why doesn't my GA4 revenue match my order management system?

A gap between GA4 revenue and your order management system (OMS) or Shopify/WooCommerce backend almost always comes from duplicate events, currency mismatches, or purchases that fire before a payment is confirmed. GA4 counts what the tag reports, not what was actually paid.

Start by comparing total transaction counts, not just revenue totals — a revenue match with a transaction count mismatch usually means average order value is masking duplicates on one side and missed events on the other. If your transaction count in GA4 is higher than orders placed, see our guide on duplicate transactions inflating revenue for the most common firing-logic causes.

Is your purchase event firing exactly once per order?

The purchase event should fire exactly once per completed transaction, triggered only on a confirmed order confirmation page or server-side event, never on page load alone. A purchase event is a GA4 ecommerce event that records transaction ID, revenue, and item-level data at the moment of conversion.

Common failure points: the tag firing on every page refresh of the confirmation page, firing again when a user hits "back" and reloads, or firing from both a client-side GTM tag and a server-side container simultaneously. The fix is almost always a transaction ID deduplication check inside GTM, paired with a server-side tag setup — see server-side GTM setup for GA4 if you haven't moved to that architecture yet.

Are you missing purchases from Safari and iOS users?

Yes, if you rely solely on client-side cookies, Safari and iOS traffic will under-report purchases because Intelligent Tracking Prevention (ITP) caps script-set first-party cookies at as little as seven days per WebKit's published policy. This doesn't erase the purchase — it breaks the session-to-conversion link, so the revenue often gets attributed to "direct" or lost entirely.

If your Safari/iOS conversion rate looks unusually low compared to Chrome and Android, that's the signal to check. Full remediation steps are in GA4 missing purchases on Safari and iOS.

Are refunds actually being subtracted from your revenue?

By default, GA4 does not automatically detect and subtract refunds — revenue stays on the books at full value unless your implementation explicitly sends a refund event with the matching transaction ID. A refund event is a separate GA4 ecommerce event, distinct from purchase, that reduces reported revenue for a given transaction.

This matters most for high-return categories like apparel, where refund rates can materially change true ROAS. If refunds aren't wired up, your GA4 revenue is a gross figure, not a net one, and every ROAS calculation built on it is overstated. Details on implementation are in refunds not tracked correctly.

Why doesn't my checkout funnel show a clean drop-off?

Missing or malformed data at specific checkout steps usually means the begin_checkout, add_shipping_info, or add_payment_info events aren't firing consistently, often because they depend on a UI state (like an accordion expanding) rather than a page or DOM-ready event. This creates funnel steps with implausibly low or zero counts.

A checkout funnel with a sudden 90%+ drop between two adjacent steps is rarely a real user behavior — it's a tagging gap. See checkout funnel steps missing data for how to trace which trigger condition is failing.

Is your add-to-cart data trustworthy?

Add-to-cart data is trustworthy only if the add_to_cart event fires on every cart addition path — including quick-add buttons, cart drawers, and quantity updates — not just the primary product page "Add to Cart" button. Single-source event wiring is the most common gap here.

If add-to-cart volume looks flat while sessions grow, or if it's suspiciously identical to purchase volume, the event is likely only capturing a fraction of real interactions. Full diagnostic steps are in add to cart events not firing.

Why doesn't my GA4 ROAS match Meta Ads Manager?

GA4 and Meta Ads Manager will rarely match exactly because they use different attribution models, different lookback windows, and different definitions of a conversion — this is expected, not necessarily a tracking error. GA4 uses data-driven attribution with a 90-day lookback window for most key events (30 days for acquisition events, per Google's documentation), while Meta uses its own 7-day click / 1-day view window by default.

Before assuming your tracking is broken, confirm you're comparing like-for-like windows and the same conversion event definition. If the gap is still large after normalizing for that, the underlying cause is usually one of the tracking issues above, not the attribution model. See GA4 ROAS does not match Meta Ads Manager for a side-by-side reconciliation method.

The checklist at a glance

Compare GA4 revenue vs OMS

transaction count first

Check purchase event dedup

one fire per order

Segment Safari/iOS conversion rate

ITP cookie limits

Verify refund event exists

net vs gross revenue

Audit checkout funnel steps

look for cliff drop-offs

Confirm add-to-cart coverage

all cart entry points

Normalize attribution windows

before comparing to ad platforms

Common causes and fixes at a glance

Frequently asked questions

How often should I run a GA4 ecommerce accuracy audit?

Run a full check quarterly at minimum, and immediately after any GTM container change, site platform migration, or checkout redesign. These changes are the most common trigger for silent tracking breaks.

Can I trust GA4's built-in ecommerce reports without an audit?

No — GA4 reports faithfully what your tags send it, but it has no way to know if a tag is duplicating, missing, or misfiring. The reports are only as accurate as the implementation feeding them.

What's the fastest way to spot if my GA4 data has a problem?

Compare transaction counts (not just revenue) between GA4 and your OMS for the same date range, and segment conversion rate by browser to catch Safari/iOS gaps. Large discrepancies in either check point to a specific fix above.

Does fixing these issues require a developer?

Most fixes are configuration changes inside Google Tag Manager rather than code changes, though server-side tagging setups typically need engineering support. A free instant audit can tell you which category your issues fall into before you scope the work.