Web Analytics · Google Analytics & GA4

GA4 Ecommerce & dataLayer Implementation

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.

A GA4 ecommerce setup that reconciles with your order system and accounts for the edge cases you already know about.

Plan ecommerce trackingAll Google Analytics & GA4 Consulting tasks
A Zeo builder loading product boxes onto a dataLayer conveyor feeding into a GA4 cart report

Some of the 500+ brands we've worked with

See all references
  • Findeks
  • Abdi İbrahim
  • Isuzu
  • Sina Pırlanta
  • Country Floors
  • Quick Sigorta
  • DLive

How we run it

Schema decisions are tested against representative orders

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.

  1. 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.

    Commerce event map

    AI assist
    Parses existing cart and checkout payload logs against GA4 item schema standards.
    Human gate
    Ecommerce lead confirms item array properties, currency codes, and coupon logic.
    Owners
    Analytics Engineer, Ecommerce Developer
    Illustrated figure stepping across a page of listed links

  2. Build the dataLayer schema

    We specify the exact item and event payloads, including currency, value, and any custom parameters your catalog needs.

    dataLayer specification

    AI assist
    Drafts item and event payload fields from the event map.
    Human gate
    Developer checks the schema against real product data.
    Owners
    Analytics Engineer, Ecommerce Developer
    Illustrated figure sketching plans at a drafting table

  3. 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.

    Journey test log

    AI assist
    Flags orders where GA4 and the dataLayer disagree.
    Human gate
    Analyst reviews each flagged mismatch before sign-off.
    Owners
    Analytics Engineer, QA Analyst
    Illustrated figure stacking patterned building blocks

  4. Reconcile against your order system

    We compare GA4 revenue and item counts against your actual order data and explain any remaining gap.

    Reconciliation summary

    AI assist
    Calculates the revenue gap between GA4 and orders.
    Human gate
    Analyst decides whether the remaining gap is acceptable.
    Owners
    Analytics Engineer, Finance Contact
    Illustrated figure examining a search result row through a large magnifier

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.

What you get

A technical specification paired with reconciliation evidence

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.

    Accepted when

    A developer can implement it without asking what a field should contain.

    Cadence: Revised with each catalog change

  • QA report

    Reconciliation report

    How GA4 revenue and item counts compare to your order system, with any explained variance.

    Accepted when

    Every remaining variance has a stated cause, not just a percentage.

    Cadence: Rerun after every release

  • Runbook

    Maintenance notes

    What to check the next time your catalog, pricing, or checkout flow changes.

    Accepted when

    The notes name which parts of the schema a catalog or checkout change puts at risk.

    Cadence: Reread before a checkout change

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.

Fit and readiness

A working dataLayer is only useful if the numbers reconcile.

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.

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.

People who build your measurement system

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.

Tools we use

Tools behind this work

  • 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

Next step

Get GA4 revenue numbers you can hand to finance

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

Before we start

Questions teams ask before booking

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.