GA4 in a shop almost always “works”: the charts render, sessions flow in. An audit starts with a different question: do the e-commerce events tell the truth? Every funnel, every analysis and every campaign optimised on GA4 conversions is exactly as good as the implementation underneath. This guide is an audit checklist: the full set of events, common mistakes, coverage against real orders and a validation routine.
Checklist
GA4 e-commerce events: the set that must work
The purchase journey in GA4 consists of standard events with names defined in Google’s documentation. The audit starts by checking whether all of them are sent and what they carry in their parameters:
| Event | When it should fire | What it must carry |
|---|---|---|
| view_item_list | listing / category view | items with item_id |
| view_item | product page visit | items, value, currency |
| add_to_cart | adding to cart | items with quantity and price |
| begin_checkout | start of checkout | items, value |
| add_payment_info | payment method selection | items, payment_type |
| purchase | once per paid order | transaction_id, value, currency, items |
Two rules above all: standard names (custom inventions such as add_to_basket will not feed e-commerce reports or conversion models) and consistent item_id values that match the identifiers in the shop system and the product feed. Without the latter you cannot link behaviour to specific products, which underpins all the funnel analytics described in the guide on combining GA4 statistics with sales.
Common mistakes
Five common mistakes in shop GA4 implementations
The same mistakes come up in shop after shop, regardless of platform. Notes from audits:
purchase fired only on the thank-you page
After a redirect payment some customers never return to it. The order exists, the event does not; coverage drops quietly and unevenly.
Missing or repeated transaction_id
Without an identifier there is no deduplication: a refreshed thank-you page counts the order a second time. The number of events should equal the number of unique transactions.
value sometimes gross, sometimes net
A purchase value that mixes tax and shipping across templates inflates or understates revenue in GA4. Set one definition and verify it with a test order.
item_id inconsistent with the shop
GA4 sends the variant SKU, the shop reports the product ID, the feed something else again. Three systems, three dictionaries and no shared per-product analysis.
Custom names instead of standard ones
The events work but have their own names, so e-commerce reports stay empty and conversion models have nothing to learn from.
Main method
Coverage: compare purchase with shop orders
The strongest implementation test requires no look at the code: compare the number and value of purchase events with paid orders from the shop system, period by period. This single figure (coverage) tells you whether the data can be trusted (illustrative data, a supplements shop):
Coverage: GA4 purchase / paid orderssupplements shop · illustrative data
Week 3 reflects the implementation, not the customers: after the payment provider changed, some customers stopped returning to the thank-you page. Without coverage monitoring, a week like this would look like “weaker traffic” and lead to poor budget decisions.
Some gap is normal: script blocking, missing consent and unusual payment paths will always take a few per cent. The alarm is not the number itself but a change in level: coverage that has been stable for months and suddenly drops signals a measurement failure. The same logic applies to value: the sum of value from purchase versus the sum of revenue from paid orders.
The shop system tells you how much you actually sold. GA4 tells you how much of that it sees. The audit makes sure the second figure does not drift away from the first.
Routine
Step-by-step validation: test order and DebugView
The qualitative audit is done by hand, on the live shop:
Enable DebugView and walk through the path
From the listing, through the product page and basket, to a paid test order. Each step should show its event in DebugView in real time.
Check the parameters of every event
An items array with the correct item_id, price and quantity; in purchase, also transaction_id, value and currency. Compare value with the order amount and the agreed definition (gross or net, with or without shipping).
Test the edge cases
Payment with a redirect, refreshing the thank-you page, returning via browser history. This is where gaps and duplicates appear, not on the happy path.
Set up continuous coverage monitoring
A weekly comparison of purchase versus paid orders (count and value). A one-off audit expires with the first change of theme, plugin or payment provider.
Real risk
A broken implementation damages more than reports. Google Ads campaigns learn from GA4 events; a gap in purchase means fewer conversion signals, weaker optimisation and genuinely more expensive orders. The mechanics of discrepancies between ad panels and the shop are covered in the guide to conversions and attribution.
DataOrganizer
How DataOrganizer monitors GA4 data quality
DataOrganizer pulls GA4 events and, in parallel, orders from the shop system, so coverage is calculated from the data without manual exports: purchase count and value versus paid orders, day by day. On top of that, automatic anomaly detection flags sudden changes before anyone opens a report:
Purchase coverage in recent weeks:
| Week | GA4 purchase | Paid orders | Count coverage | Value coverage |
|---|---|---|---|---|
| 18.08–24.08 | 418 | 446 | 94% | 95% |
| 25.08–31.08 | 289 | 401 | 72% | 70% |
| 01.09–07.09 | 437 | 459 | 95% | 96% |
In the week of 25.08–31.08, coverage fell to 72% and returned to normal after 01.09. The drop coincides with the change of payment provider, which suggests that customers paying via a redirect did not return to the thank-you page. GA4 reports for that week understate sales; use shop data for comparisons.
Key takeaway
A GA4 audit only works as a habit. Qualitatively: a test order with DebugView after every change to the shop. Quantitatively: purchase coverage against paid orders every week. DataOrganizer handles the second part automatically, because it keeps both sources side by side.
FAQ
Frequently asked questions about a shop GA4 audit
Which e-commerce events must a shop have in GA4?
The standard path: view_item_list, view_item, add_to_cart, begin_checkout, add_payment_info and purchase, each with an items array, and purchase with transaction_id, value and currency. Names must follow Google’s documentation; e-commerce reports do not recognise custom inventions.
Why does GA4 show fewer orders than the shop?
Most often because purchase fires only on the thank-you page (some customers do not return to it after a redirect payment), plus script blocking and missing consent. A gap of a few to around fifteen per cent is normal; a sudden drop in coverage is a measurement failure, not a change in customer behaviour.
What causes duplicate purchase events?
Refreshing or reopening the thank-you page when transaction_id is missing. A correct implementation sends purchase once per order, with a unique identifier; the audit compares the number of events with the number of unique identifiers.
How do you check the implementation is correct?
Qualitatively: a test order with DebugView and a check of each event’s parameters, including edge cases (payment redirects, refreshes). Quantitatively: coverage of purchase count and value against paid orders from the shop, monitored continuously rather than once.
How does DataOrganizer help?
It keeps GA4 events and shop orders in one model, so coverage is calculated automatically and anomaly detection reports sudden changes in the data. The question “does GA4 capture all orders?” gets an answer with figures within a minute, together with the period in which the data should not be trusted.
Cheat sheet for the whole guide
A GA4 audit in three layers
1. A full set of events with standard names. The path from view_item to purchase, with items, transaction_id, value and currency. Everything else is built on this.
2. Coverage as an ongoing measure of trust. Purchase count and value versus paid orders from the shop, week by week. A change in level is an implementation alarm before it becomes a poor budget decision.
3. Validation after every change. A test order checked in DebugView after changing the theme, a plugin or the payment provider. DataOrganizer closes the loop: coverage and anomalies are calculated automatically, because GA4 and shop data sit side by side.
DataOrganizer · GA4 under constant monitoring
Connect GA4 and your shop system: purchase events are compared with paid orders day by day (count and value), and data anomalies are flagged automatically. Demo account available instantly; you pay only for connected sources.