What is a GA4 audit actually for?
One purpose: establishing whether the numbers the business reads can be trusted, with evidence. That splits into three questions. Does every meaningful action produce the right event with the right parameters? Do revenue and purchase counts reconcile against the commerce platform's own orders table? And do the property's settings - attribution, data retention, filtering, identity - match what the team believes they are? On most properties audited for the first time, at least one of those three fails materially.
What does the event layer usually get wrong?
The recommended ecommerce events form a funnel - item viewed, added to cart, checkout begun, purchase - and the audit checks each stage for presence, uniqueness, and parameter completeness. The recurring defects:
- Duplicate purchases. The thank-you page fires on refresh or back-navigation, and the purchase event has no transaction deduplication. Revenue inflates quietly, usually by single-digit percentages - enough to corrupt decisions without triggering suspicion.
- Missing parameters. Items arrays without item ids, values without currency, events renamed just enough that built-in reports ignore them.
- Double tagging. A platform integration and a tag manager container both sending the same events, sometimes with different parameter conventions - two overlapping truths, both wrong.
- Funnel gaps. Checkout steps that never fire on one payment method or one device class, discovered only when someone segments the funnel.
How should purchases be reconciled?
Pick a closed date range and compare three counts: orders in the commerce platform, purchase events in GA4, and conversions recorded by each ad platform. They will not match - the question is whether the deltas are explained (consent rejections, ad blockers, refunds, timezone boundaries) or unexplained. The audit's job is to shrink the unexplained remainder until what is left is the known, documented cost of measurement under consent - not a mystery.
| Check | Passing looks like | Common failure |
|---|---|---|
| Purchase count vs orders | Stable small delta, explained by consent and blockers | Drift that grows with traffic - duplication or dropped events |
| Revenue vs orders | Deltas track refunds and taxes consistently | Currency or tax handled differently per event source |
| Transaction ids | Unique per order across all senders | Missing ids, or two senders using different id schemes |
| Funnel coverage | Every step fires on every template and device class | A payment method or template silently untracked |
Which settings silently corrupt reporting?
The audit reviews the property configuration as evidence, not as trivia: attribution model and lookback windows (they change channel credit retroactively when edited), data retention (short retention quietly truncates exploration reports), internal traffic and payment-referrer exclusions (a missing referral exclusion hands checkout revenue to the payment provider), cross-domain settings, and identity mode. None of these announce themselves when wrong; all of them reshape every report downstream.
What does the deliverable look like?
A findings register - each defect with its evidence, its measured impact where quantifiable, and its fix - plus the reconciliation table and a re-test after remediation. The standard is simple: every number in the deliverable traces to a query or a capture someone else could re-run.