dataLayer timing & race conditions

Symptom and cause

Symptom

Parameters there one day, missing the next: items arrays empty, values intermittently zero. The same tag passes in testing and fails for real users.

Cause

Tags fire before the dataLayer is populated. The tag races the push, or fires on page view while the ecommerce object arrives a beat later.

Where it's caught

GTM Preview: variables resolving undefined on first fire; GA4 events arriving with missing parameters on a fraction of hits only.

How the tag outruns the data

A GTM tag reads its Data Layer Variables at the instant its trigger fires. If the dataLayer.push that populates those values has not yet run, the variables resolve undefined. GA4 then drops the undefined items and value parameters, so they are absent from the hit. Google's own documentation is explicit. A pushed value is queued and processed after all other pending messages, so updated values are not guaranteed to be available for the next event. Tag Manager evaluates messages in order, and a tag can only see what was in the model at or before its trigger. The common shape is a GA4 event tag bound to a page-load-family trigger (Consent Initialization, Initialization, Page View, DOM Ready, Window Loaded or All Pages) while the ecommerce object is pushed by the page template a moment later, so the tag out-races the push. Placement is the tell. If the push carrying the data sits below the GTM container snippet in the source, it is not in the model when Page View fires, though a synchronous inline push placed there will be in the model from DOM Ready onward. Note that Consent Initialization and Initialization fire before Page View, so Page View is not the earliest moment. The fault is intermittent by nature. Which async path wins on a given load decides the outcome, and a push may wait on framework hydration, an API or cart call, or a deferred script, so fast cached loads can flip the order relative to slow ones. The correct fix re-sequences the firing. A Custom Event trigger keyed to the event name of the push itself (purchase, view_item, the case-sensitive value of the event key) fires only when that key appears in a dataLayer.push, so the data and the trigger are guaranteed to coexist, and the push must carry the event key alongside the values it consumes. Only an event-key push can fire a tag, and an event key gives tags access to the state of the dataLayer at the time of that push, so a data-only push without an event key can be overwritten before any tag reads it. A second, related behaviour sits underneath this. GTM's data model is merged, not reset, between pushes (Data Layer Version 2 recursive merge), so a key from an earlier push can go stale and bleed into a later event. That produces wrong-but-present values, distinct from the fire-before-push race, which produces absent ones. The single-page-app version is the same mechanism. The History Change trigger fires after the URL updates but before the new route's content and its dataLayer.push have rendered, so a tag bound to it can fire before the route's dataLayer exists, and the dependable fix is a developer-emitted custom event at the moment the transition completes, not a GTM delay.

t+ms	step	dataLayer state	tag reads
0	Container Loaded (gtm.js)	no ecommerce key yet	—
+12	Page View trigger evaluated (on gtm.js)	no ecommerce key yet	trigger matches
+14	GA4 view_item tag fires	ecommerce still absent	items: undefined · value: undefined (dropped)
+90	dataLayer.push (view_item)	items[] + value now in model	too late, tag already shipped
+92	DOM Ready (gtm.dom)	items[] + value present	resolves here only because the push landed first

tag fires on Page View, one beat before the push

How to catch it

1. Confirm it flickers before anything else. In GA4 DebugView (Admin > Data display > DebugView), enable debug through Tag Assistant, then load the affected page several times and click the event in the Seconds stream each time. If items or value are present on some loads and absent on others, it is a timing race. If the parameter is missing on every single load, you are looking at F-301, not this.
2. In GTM Preview or Tag Assistant, select the specific firing event in the left-hand timeline rather than the Summary row (Summary shows the latest merged values and hides the race), open Variables, and confirm the Data Layer Variable for items or value shows undefined on that fire.
3. In the same Preview session open the Data Layer tab and check the order. The push carrying items and value must appear before the triggering event. A push that lands after the trigger is the positive confirmation that the tag out-raced the data.
4. Check the trigger type on the GA4 event tag. A page-load-family trigger (Consent Initialization, Initialization, Page View, DOM Ready, Window Loaded or All Pages) against a template- or app-pushed ecommerce object is the classic mismatch. Note where the dataLayer.push sits in the page source: below the GTM container snippet means it is not in the model at Page View.
5. Verify at the layer where timing is exact. In DevTools > Network, switch on Preserve log, filter for collect (GA4 hits go to google-analytics.com/g/collect, a 204 No Content confirms transmission), reload several times and read the request payload: items and value are populated on clean fires but missing on raced fires, on a fraction of loads only. This is practitioner practice. DebugView is Google's documented path but has processing latency, so corroborate the gap here.
6. Separate it from the report-only confusable. Read the outgoing /g/collect request directly. If items or value is genuinely missing from the request on the affected fires, it is F-103. If the parameter is present in every request but reads (not set) in standard reports, it was never registered as a custom dimension, which is F-601, a reporting fault that re-sequencing cannot touch.

What putting it right involves

1. Re-sequence the firing. Move the GA4 event tag off the page-load-family trigger and onto a Custom Event trigger keyed to the event name of the push itself (purchase, view_item, the exact case-sensitive value of the event key). The trigger then fires only when that key appears in a dataLayer.push, so the data and the trigger are guaranteed to coexist.
2. Push the event key and the values it consumes in the same object, or push the values before the event key. Only an event-key push can fire a tag, and it gives the tag the dataLayer state at the time of that push. A data-only push without an event key can be overwritten by a later push before any tag reads it, which is the same undefined-at-fire-time failure.
3. Do not rely on a later page-load trigger as the cure. Moving the tag to DOM Ready or Window Loaded only helps if the push reliably completes before that moment, and template, cart, API or single-page-app pushes can still lose the race. The reliable fix is the matching Custom Event trigger, not a later page-load trigger.
4. For single-page apps, do not bind to the History Change trigger. gtm.historyChange is dispatched after the URL updates but before the new route's content and its dataLayer.push have rendered, so a tag on it can fire before the route's dataLayer exists. Have the developer emit a custom event at the moment the transition completes and the data is ready, and key the trigger to that, and have that event push the route's values alongside the event key (or push them first), so the tag reads populated variables, exactly as on the page-load path.
5. Flush stale keys if you also see wrong-but-present values rather than absent ones. Because the data model is merged and not reset between pushes, a prior product's items can persist into a later event. Push the offending key as undefined, or push ecommerce: null before each ecommerce push, or read the array with a Version 1 Data Layer Variable. This is the secondary nuance, distinct from the fire-before-push race, so confirm which you have before applying it.
6. Verify the same way you diagnosed. Re-run several loads in DebugView and read /g/collect with Preserve log on: items and value now resolve on every fire, with the push appearing before the triggering event in the Data Layer tab. Re-sequencing recovers data that is genuinely pushed. It cannot conjure events or fields that were never sent, which stay F-301 or F-601.