The GA4 e-commerce tracking playbook

Every conversion decision your store makes stands on this plumbing. A large share of stores run with a funnel that double-counts, drops steps, or misattributes — and decide confidently on the garbage.

GA4’s e-commerce model is a sequence of events — view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase — each carrying an items array and value parameters. Get them right and every downstream analysis works; get them subtly wrong and everything downstream lies politely. This playbook implements the model, validates it against ground truth, and installs the checks that keep it honest as the store changes.

Stage 1: Implement the event model completely

Partial implementations are the norm and the problem: purchase without begin_checkout means no funnel; events without the items array mean no product-level analysis; missing value and currency mean revenue reports that cannot reconcile. Implement the full sequence with complete parameters, through your platform’s native integration where solid, and audited even then — native integrations drift.

  • The full event sequence, from view_item through purchase

  • Complete items arrays: id, name, category, price, quantity on every commerce event

  • value and currency on every event that carries money

  • Transaction IDs that match your order system exactly — deduplication depends on them

Stage 2: Validate against ground truth

The test is reconciliation: GA4 purchase revenue against actual orders over the same window. Expect a small gap from consent and blockers; investigate anything beyond it. Then walk the funnel as a shopper on desktop and mobile, watching events fire in DebugView — every step, once each, with the right parameters. Double-fired purchases and phantom checkout steps announce themselves here.

Stage 3: Keep it trustworthy

Tracking decays like everything else: theme updates drop tags, new templates ship without events, apps inject duplicates. Re-reconcile on a schedule, re-walk the funnel after every significant theme or checkout change, and record the validated state so drift is detectable rather than discovered during a crisis of confidence in the numbers.

How it works

01

Implement the full model

Every event, complete parameters, matching transaction IDs — through the platform integration, audited.

02

Reconcile and walk

Revenue reconciled to orders, the funnel walked in DebugView on both device classes.

03

Schedule the re-checks

Reconciliation on a cadence, re-validation after every structural store change.

What you get

  • A funnel where every step is real and fires once

  • Revenue reports that reconcile with your order system

  • Product-level analysis that actually has the data it needs

  • Drift caught by schedule instead of by crisis

Frequently asked questions

My platform has a native GA4 integration. Am I done?

Closer to started. Native integrations vary in completeness — checkout steps and items-array quality are the common gaps — and they drift with platform updates. Audit what actually fires before trusting it.

How closely should GA4 revenue match my orders?

Within the gap that consent mode and blockers explain for your traffic mix — commonly five to fifteen percent under-reporting. A stable, understood gap is fine; an unstable or growing one is a defect.

Is server-side tagging worth it?

It narrows the blocker gap and improves data durability at real setup cost. Fix the basics first — a server-side pipeline faithfully transmitting broken events is expensive garbage.

Which agents run this?

Analyst owns the audit, reconciliation, and scheduled re-validation, producing exact fix instructions for anything broken — it validates before it ever reports, because reporting on bad data is worse than not reporting.

Put the team to work on your store

Connect your storefront, analytics, and email stack, set a goal, and let the agents run the work end to end. Start on the free plan with your own model key.