When The Data You Need Isn'T In The Event

A subtler mess: you have a good, targetable event, but it doesn't carry the value you need to send. The submit fires, but there is no plan or value on it. The value almost always exists somewhere — your job is to find which source holds it at the instant the event fires, and read it from there.

The five places a value can live

• An earlier dataLayer push: it was set on page load or on a previous step (see below).
• A sibling event: a different event firing around the same time carries it.
• The DOM: it is printed on the page — a price, a plan badge, a total.
• The URL: a query parameter or a path segment like /pricing/pro.
• A cookie or storage: stashed earlier in the journey.

Why an earlier push is still readable

This surprises people, so it matters: GTM keeps a single merged model of the data layer. Each push is merged on top of the last, and a Data Layer Variable reads from that combined state — not just from the push that fired the event. So a value set at load is still there when a later event fires.

dataLayer.push({ plan: "pro", planValue: 500 });   // on the pricing page, at load
// …user fills the form…
dataLayer.push({ event: "form_submit", formId: "demo-request" });

// On the form_submit event, a DLV named "plan" still returns "pro".
// GTM merged the earlier push into its model; the value persists.

So the fix for "the submit has no plan" is often nothing more than a Data Layer Variable called plan — it reads the value the page set earlier. The richest data isn't always on the event you trigger on; it may be sitting in the merged state, waiting.

Capturing from a sibling event

When the value rides a different event, capture it into a variable when that event fires and read it back later. The merge model does this for you for dataLayer values; for DOM-only or computed values, a Custom JS variable that "remembers" the last seen value (the next lesson) bridges the gap.