Home›Guides›dataLayer testing

dataLayer testing: how to validate ecommerce events before they corrupt your reports

By Sam ParkinsonUpdated 18 September 202610 min read

The dataLayer is the contract between your site and your tags. When a developer, a theme update or an app changes its shape, every tag that reads it keeps firing, on the wrong data. Nothing errors. The numbers just drift.

What breaks in a dataLayer (the failure patterns we built around)

These are the defects that pass a casual check and still corrupt reporting:

Step 1: look at what the page pushes

On any page, open the browser console and type dataLayer. You will see every push so far. For a readable view, open Google Tag Manager › Preview: Tag Assistant lists each push as a step, with every variable's value at that moment. Walk the purchase path and check each ecommerce event appears, in order, with a populated ecommerce object.

A well-formed GA4 purchase push looks like this:

dataLayer.push({ ecommerce: null });  // clear the previous ecommerce object
dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "1234",
    value: 59.98,          // a number, not "59.98"
    currency: "GBP",       // ISO 4217, uppercase
    items: [
      { item_id: "SKU-1", item_name: "Canvas tote", price: 29.99, quantity: 2 }
    ]
  }
});

Step 2: write the contract down as a schema

Checking by eye does not scale past one page on one day. Write the rules down once, as a JSON Schema, and let a validator enforce them. The rules that matter most for GA4 ecommerce:

• event is one of the ecommerce events you implement (view_item, add_to_cart, begin_checkout, purchase, refund…).
• ecommerce.currency matches ^[A-Z]{3}$.
• ecommerce.value is a number, zero or above.
• ecommerce.items is an array with at least one item, each with a non-empty item_id and item_name; where present, price is a number and quantity an integer of at least 1.
• For purchase: transaction_id, value, currency and items are all required.
• For refund: transaction_id and currency are required.

Those are exactly the rules AuditTag's own ecommerce schema enforces. We deliberately validate the fields that cost money when they break, not every optional GA4 parameter, so a failure always means something worth fixing.

Step 3: capture the dataLayer automatically

To test without a person clicking, a headless browser does the walking. With Playwright, for example, a script loads a product page, clicks add to cart, moves through checkout on a test payment method, and reads window.dataLayer at each step. The captured array is then passed to the validator. Each violation comes back with its exact path, such as $.ecommerce.items[0].price: expected number, got string, so a developer can go straight to the line.

Step 4: run it at the moments things change

• In CI, against staging, before release. A failing purchase schema should fail the build, the same way a failing unit test does.
• After every deploy, against production. Staging and production drift; confirm the release that shipped is the one you tested.
• On a schedule. Apps, tag manager publishes and platform updates change the dataLayer without going through your deploys at all.

Severity should follow money: a malformed purchase or refund is critical, because ad platforms bid on it; a drifted view_item is a warning worth fixing before it reaches checkout.

How AuditTag handles it