The ecommerce dataLayer is finished when GA4 revenue and your order system agree on the same orders.

Ecommerce tracking gets complicated once refunds, multi-currency carts, and bundled promotions enter the picture. We design the dataLayer schema around those realities, then compare GA4 revenue with the orders that were actually paid. You end up with a GA4 ecommerce setup that reconciles with your order system and accounts for the edge cases you already know about.

Plan ecommerce tracking All Google Analytics & GA4 Consulting tasks

Some of the 500+ brands we've worked with

See all references

The commerce-specific pieces that generic event tracking doesn't cover. The process ties the event map and payload specification to purchase, refund, and promotion tests.

How we hold ourselves to it

The item array maps to your real catalog — We map your catalog to GA4's item array, including variant, category, price, and quantity, then build the journey from view_item through purchase around your checkout flow.
Currency and value, calculated the way finance expects — We set the right currency parameter and value calculation, including tax and shipping decisions your finance team actually wants reflected.
What happens when a promotion or a refund hits? — We build promotion view and select events where you run merchandising, and wire refund events so returned revenue actually leaves your reports.
A transaction ID stops the purchase event from double-counting — We add a transaction ID check so a page refresh or a retried checkout doesn't count the same order twice.

Map the commerce journey
We walk your actual catalog, cart, and checkout to identify every commerce event GA4 needs, well past a generic list pulled from documentation. The ecommerce lead confirms item array properties, currency codes, and coupon logic.
Commerce event map
Build the dataLayer schema
We specify the exact item and event payloads, including currency, value, and any custom parameters your catalog needs. The developer checks the schema against real product data.
dataLayer specification
Implement and test with real orders
We test the flow with real (or realistic sandboxed) purchases, refunds, and promotions to catch schema issues before launch. The analyst reviews each flagged mismatch before sign-off.
Journey test log
Reconcile against your order system
We compare GA4 revenue and item counts against your actual order data and explain any remaining gap. The analyst decides whether the remaining gap is acceptable.
Reconciliation summary

The item array carries the hardest parts of ecommerce tracking.

Automation parses the existing cart and checkout payloads against the GA4 item schema, drafts the event and item fields, flags orders where GA4 and the dataLayer disagree, and calculates the revenue gap. People decide the things a parser cannot: what the coupon logic really means, whether the schema holds against real catalog data, and whether the remaining gap is acceptable.

A schema your developers can implement without guessing, and proof it works.

Technical specification
Ecommerce dataLayer specification
The exact event and item payloads for view_item through purchase, refunds, and promotions, ready to hand to a developer.
QA report
Reconciliation report
How GA4 revenue and item counts compare to your order system, with any explained variance.
Runbook
Maintenance notes
What to check the next time your catalog, pricing, or checkout flow changes.

We call it done when: GA4 purchases reconcile with the order export inside an agreed variance, and refunds and retried checkouts have both been tested.

If your GA4 revenue and your order system don't already agree, the list below explains why that's worth fixing now.

A good fit when

GA4 revenue and the order system disagree, and nobody has compared individual purchases, refunds, or retries to explain the gap.
You are launching a store, cart, or checkout flow and need commerce events designed from the start.
Refunds, multi-currency prices, and bundled promotions are present, but the item-level data cannot yet explain them reliably.
The dataLayer, checkout code, and order export are available, but nobody has checked the payload against real product data.

A builder loading product boxes onto a dataLayer conveyor feeding into a GA4 cart report

Better handled as other work when

You need general event naming or key-event decisions outside ecommerce. That belongs in GA4 Event & Conversion Tracking.
GA4 differs from finance for reasons beyond ecommerce, such as attribution or identity. That belongs in GA4 Reporting Validation & Reconciliation.

If one of these is closer to your situation, start here instead: All Google Analytics & GA4 Consulting tasks

We call it done when: the item array, currency codes, and coupon logic are confirmed against real product data before implementation starts.

Zeo designs measurement systems that connect a business decision to governed collection and reporting you can check. The people shown here work on the part of that system this page covers.

Google Analytics
the revenue report checked order by order against what was actually paid
Google Tag Manager
reads the item array and ecommerce object the schema defines, field by field
Google Tag Assistant
checks the item array a real test order actually pushed, line by line

Bring the checkout flow and order export. We will build the dataLayer and verify the revenue match before sign-off.

Plan ecommerce tracking

Why doesn't our GA4 revenue match our order system today?

The cause is often a refund that does not reduce revenue, a duplicate purchase event after a retry, or a missing currency parameter on an international order. We identify the cause before recommending a fix.

Do you handle subscriptions or recurring billing?

We can if recurring charges pass through the same checkout dataLayer. Billing that happens entirely server-side, without a browser event, needs a server-side or API-based event instead. We will confirm which approach applies.

What if we're migrating checkout platforms?

That's a good time to do this properly. We build the new dataLayer schema alongside the migration so ecommerce tracking launches correct instead of getting patched after the fact.

What do you need to test purchases?

Access to your dataLayer or checkout code, a way to place test orders (or a sandbox), and your order export or admin panel for reconciliation.

By team

By industry

By tool

GA4 Ecommerce & dataLayer Implementation

Schema decisions are tested against representative orders

Map the commerce journey

Build the dataLayer schema

Implement and test with real orders

Reconcile against your order system

A technical specification paired with reconciliation evidence

Ecommerce dataLayer specification

Reconciliation report

Maintenance notes