The GTM Data Layer: How to Push Events the Right Way

The GTM Data Layer Is Only as Good as What You Push Into It

Last week I reviewed a Shopify Plus store spending EUR 18,000 per month on Google Ads and Meta. They had a data layer. It was implemented by a developer twelve months ago. On paper, everything looked right -- GA4 ecommerce events were firing, the purchase tag showed in Tag Assistant, conversions appeared in Google Ads.

Then I compared the numbers. GA4 reported EUR 74,200 in July revenue. Shopify reported EUR 91,600. A 19 percent gap. The purchase event fired, but the value parameter pulled the subtotal before tax and shipping instead of the order total. And every add_to_cart event carried stale product data from the previous view_item because nobody cleared the ecommerce object between pushes.

The data layer existed. The pushes were wrong. Twelve months of Google Ads bidding data was optimized against understated revenue.

I wrote a companion post explaining what a data layer is and why tracking breaks without one. That post covers the concept. This one is the practical guide -- how to structure your dataLayer.push calls, when to fire them, what belongs in each push, and the mistakes I fix in almost every GTM container I audit.

Event Pushes vs. Variable Pushes

Not every dataLayer.push() call is the same. Understanding the two types is essential to getting the GTM data layer right.

Event pushes

An event push includes an event key. When GTM sees this, it evaluates every trigger in the container against the event name. If a Custom Event trigger matches, the associated tags fire.

dataLayer.push({
  event: 'generate_lead',
  lead_value: 1200,
  lead_source: 'demo_form'
});

This push does two things simultaneously: it sets the lead_value and lead_source values in the data layer state, and it fires any tag triggered by the Custom Event generate_lead.

Variable-only pushes

A push without an event key updates the data layer state silently. No triggers evaluate. No tags fire.

dataLayer.push({
  user_type: 'returning',
  customer_tier: 'premium'
});

This is useful for setting contextual information early -- user state, page metadata, experiment variants -- that tags will need later when an event push fires. The Google Tag Manager documentation calls this "pushing variables to the data layer."

The mistake I see most often: teams push variables without an event key and wonder why their tags never fire. Or the opposite -- they include event on every push, causing triggers to evaluate unnecessarily and sometimes double-fire tags. Use event pushes when you want a tag to execute. Use variable-only pushes when you are setting context.

Timing: When Your Push Fires Matters More Than What It Contains

A perfectly structured push is useless if it fires at the wrong time. In the data layer in Google Tag Manager, timing determines whether tags receive data or get undefined.

The initialization sequence

The correct order is:

1. Initialize the array: window.dataLayer = window.dataLayer || [];
2. Push any page-scoped variables (page type, user state, language)
3. Load the GTM container snippet
4. Push event-specific data when the interaction happens

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    page_type: 'product',
    user_logged_in: true,
    customer_tier: 'premium'
  });
</script>
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXXX');</script>

By pushing page-scoped variables before the container loads, GTM has access to them from the very first trigger evaluation. No race conditions.

Event timing on dynamic pages

On modern sites -- React, Next.js, Vue, headless Shopify -- the critical question is: when does the data become available? A purchase event should not fire on page load if the order data populates via an API callback. The push must happen inside that callback, after the data exists.

// Wrong: pushes on page load before data is available
dataLayer.push({
  event: 'purchase',
  ecommerce: { transaction_id: orderData.id } // orderData is undefined
});

// Right: pushes inside the callback when data is ready
fetchOrderConfirmation().then(function(orderData) {
  dataLayer.push({ ecommerce: null }); // Clear previous ecommerce data
  dataLayer.push({
    event: 'purchase',
    ecommerce: {
      transaction_id: orderData.id,
      value: orderData.total,
      currency: 'EUR',
      items: orderData.items
    }
  });
});

I covered trigger timing in depth in Google Tag Manager Triggers: 5 Silent Misconfigurations -- read that if your tags fire but with empty values.

Structuring the GTM Ecommerce Data Layer

The GTM ecommerce data layer follows a schema defined by Google for GA4. Implement it correctly and GA4's Monetization reports, product performance tables, and funnel visualizations populate automatically. Deviate from the schema and those reports show "not set" or zero.

The GA4 ecommerce guide documents the full funnel. Here is the minimum viable implementation I configure for most clients:

Event	When it fires	Required parameters
view_item	Product page loads	items[] with item_id, item_name, price
add_to_cart	User adds a product	items[], value, currency
begin_checkout	Checkout starts	items[], value, currency
purchase	Order confirmed	transaction_id, value, currency, items[]

Every ecommerce push shares the same items[] array structure. Use the same item_id and item_name across all events. If view_item calls the product "Wireless Headphones Pro" but purchase calls it "WH-Pro-BLK", your funnel analysis breaks -- GA4 treats them as different products.

The ecommerce null clear

Before every ecommerce push, clear the previous ecommerce object. Without this, data from a prior event leaks into the next one. Google explicitly documents this requirement:

// Clear the previous ecommerce data
dataLayer.push({ ecommerce: null });

// Then push the new event
dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    currency: 'EUR',
    value: 49.00,
    items: [{
      item_id: 'SKU-1042',
      item_name: 'Wireless Headphones Pro',
      price: 49.00,
      quantity: 1
    }]
  }
});

I find the missing null clear in about half the ecommerce implementations I audit. The symptom: purchase events carry inflated items[] arrays containing products from earlier view_item and add_to_cart events. Revenue totals look correct but product-level reporting is corrupted.

Setting Up Data Layer Variables in GTM

Once your site pushes structured data, you need data layer variables in GTM to read it. A data layer variable in GTM maps to a specific key path in the data layer object.

For a push like:

dataLayer.push({
  event: 'generate_lead',
  lead_value: 1200,
  lead_source: 'demo_form'
});

You create two variables in GTM:

Variable name	Variable type	Data Layer Variable Name
DLV - lead_value	Data Layer Variable	lead_value
DLV - lead_source	Data Layer Variable	lead_source

For nested ecommerce data, use dot notation. The transaction ID inside ecommerce.transaction_id maps to a data layer variable with the name ecommerce.transaction_id. Follow a consistent naming convention for your variables -- prefix them with DLV - so anyone opening the container knows what type they are and where the data comes from.

Your tags then reference these variables. The GA4 event tag uses {{DLV - lead_value}} as the parameter value. The Google Ads conversion tag uses {{DLV - ecommerce.transaction_id}} for deduplication. Every tag reads from the same source of truth -- no scraping, no CSS selectors, no DOM dependencies.

Seven Mistakes That Break Data Layer Pushes

After auditing over a hundred GTM containers, these are the mistakes I find most often. Most implementations have at least two.

1. Overwriting the array instead of pushing to it

// Wrong -- wipes GTM's internal listener
window.dataLayer = [{ event: 'purchase', ... }];

// Right -- preserves the existing array
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ event: 'purchase', ... });

Setting window.dataLayer to a new array after GTM has loaded destroys GTM's internal event listener. Every subsequent push is invisible to GTM. I see this when developers copy a snippet without understanding that = window.dataLayer || [] is for initialization only.

2. Pushing after the tag has already fired

Your confirmation page pushes ecommerce data in an API callback, but the GTM trigger is set to DOM Ready. The tag fires before the push happens and sends empty values. Use a Custom Event trigger that matches the event name in your push instead of a timing-based trigger.

3. Wrong data types

A value of "149.00" (string) instead of 149.00 (number) silently breaks value-based bidding in Google Ads. GA4 accepts it, but downstream systems expecting a numeric value will not process it correctly. Push numbers as numbers, not quoted strings.

4. Missing the event key

A push without event updates the data layer state but fires no triggers. If your tag relies on a Custom Event trigger, it will never execute. This catches teams that copy variable-only push examples and expect tags to fire.

5. Inconsistent key names across the codebase

One developer pushes transactionId. Another pushes transaction_id. A third pushes orderId. The GTM variable reads one specific key. The other two return undefined. The fix is a written specification -- I detail the process in the companion data layer post.

6. Skipping the ecommerce null clear

Covered above but worth listing because the failure mode is common and hard to catch. Product-level data corruption without any visible error.

7. Pushing PII into the layer

Email addresses, phone numbers, and full names pushed unhashed into the data layer are accessible to every tag in the container -- including third-party scripts. If you need user identifiers for enhanced conversions, hash them before they hit the layer. Pushing raw PII creates both a compliance risk and a data governance problem.

A Validation Checklist Before You Ship

Before publishing any implementation, run through this sequence. It takes twenty minutes and catches most issues.

1. Open GTM Preview mode and walk through every conversion path on the site.
2. For each event in the Preview timeline, click it and inspect the Data Layer tab. Confirm the keys, values, and data types match your specification.
3. Verify that ecommerce events have the ecommerce: null clear before each push.
4. Check that value parameters are numeric, currency is a valid ISO 4217 code, and transaction_id is unique per order.
5. Confirm that tags fire exactly once per user action -- not zero times, not twice. If you see double-firing, check for overlapping triggers.
6. Open the browser console and type dataLayer to inspect the full array. Look for unexpected overwrites or duplicate events.
7. Cross-reference at least five real transactions against your backend system or CRM after going live.

If you run server-side tracking, repeat the validation in your server container's Preview mode. The server container only receives what the web container sends.

If this checklist surfaces problems you are not sure how to fix, I can audit your implementation and hand you a prioritized fix list.

FAQ

Not sure your data layer is sending the right values to the right tags? Get in touch -- I will audit your implementation and tell you exactly what is broken and how to fix it.