Items from the last page show up on the next ecommerce event: clear the object before each push

The symptom: yesterday's product on today's event

A typical report of this fault is an add_to_cart whose items include a product from the page before, or a purchase that lists the wrong quantity. The tag is firing; the data it reads is wrong. Because the ecommerce object lives in the data layer between pushes, what the next tag reads depends on what was left there.

Google's Tag Manager ecommerce guide shows the safeguard in every example: a push that sets the ecommerce object to null, commented as clearing the previous ecommerce object, comes immediately before the push that carries the event. The page gives no longer explanation. Google's data layer page also does not describe how nested objects are combined, so the careful reading is to follow the example and clear first.

• Clear the object, then push the event, in that order and from the same code path.
• Do this for every ecommerce event, not just the first one on a page.

How values replace and queue

Two facts from Google's data layer documentation explain most surprises. Pushing a variable with an existing name replaces the old value. And pushes are processed in order: a push made by page code, a template or a custom HTML tag goes to the back of the queue, so Google says any updated data layer values are not guaranteed to be available for the next event.

The remedy Google gives is to include an event name in the push and listen for it with a Custom Event trigger, which is also how the ecommerce tag is wired. Keep the data and the event in one push.

• Put the event key and the ecommerce object in the same push.
• Never assign dataLayer a new array after load; use push.
• Declare the data layer above the container snippet, once per page.

A test that catches stale items

Walk a known journey with Tag Assistant or DebugView open: view product A, add one of A to the cart, view product B, add two of B, begin checkout, buy. After each step, expand the items parameter of the event in Tag Assistant or DebugView and compare it with the step. Stale data shows as A inside the add of B, or a quantity carried across steps.

Write the expected items for each step before you test, so you are checking against a specification and not against what you happen to see. The synthetic shop data layer example on this site shows the layout of such a specification.

• Use two products with different prices so a swap shows in the value.
• Check value equals the sum of price times quantity for the items, as Google's purchase sample states.

What does not fit, and how the paid outcome is accepted

This guide covers the data layer side. It does not cover duplicate purchase sending, platform checkouts that expose no events, or reconciling GA4 revenue. Hosted checkouts that offer no way to send events cannot be measured this way.

For one store, the fixed-floor outcome Shop funnel events starts from £795 as an untested proposal, quoted after we know the platform and templates, with payment only after sign-off. Acceptance is watchable: view_item, add_to_cart with quantity 2, begin_checkout with no earlier product, and purchase with a transaction ID and the right value all appear in DebugView, and, once Google has processed the data, the Ecommerce purchases report shows the test product and an exploration lists the test order by its transaction ID. Send the platform name and your three most important products; no logins or customer data.