Common GTM Mistakes That Break Your Tracking

Hello! If a conversion report has ever looked too good, too bad, or just plain wrong for no obvious reason, there's a decent chance a Google Tag Manager container is quietly misbehaving somewhere underneath it.

You published a tag, checked Preview mode once, and moved on. Weeks later the numbers don't add up, and nobody can say exactly when they stopped trusting the data. That gap between "it's set up" and "it's set up correctly" is where nearly every one of these problems lives.

Google Tag Manager looks simple from the outside: a container, some tags, some triggers, a publish button. Underneath, it's running real JavaScript against a real queue of events, called the dataLayer, and every one of the GTM mistakes covered here comes from a small, specific misunderstanding of how that queue actually behaves.

None of these are exotic edge cases. They're the everyday kind of GTM mistakes that ship quietly, pass a quick glance in Preview mode, and only get noticed once a report looks off and someone has to dig backward to find out why.

To make the point concretely rather than just listing advice, I built small real reproductions of the most common failure patterns, ran them in a real browser, and captured the actual output. Nothing here is simulated in the "trust me" sense; every result below is copied straight from a real script run.

The cost of these mistakes is rarely a single dramatic outage. A tag firing twice inflates a conversion count by a small, believable amount. A trigger with a case sensitive typo just quietly stops reporting one specific action. Both look like normal data until someone compares the numbers against a source of truth and finds a gap that doesn't add up, and by then the underlying GTM mistake could have been live for months. That's the pattern behind nearly every one of these GTM mistakes: small, believable, and expensive precisely because nobody notices right away.

The single most damaging item on this list of GTM mistakes is also the quietest: something on the page, often a plugin or a hand written script meant to "set up tracking," declares dataLayer as a plain object instead of an array.

// a real, documented mistake
var dataLayer = {};
dataLayer.push({ event: 'formSubmit' }); // throws

An object has no push method, so the very next line that tries to queue an event throws a real error and stops right there. Any code after it, including the rest of a marketing script or another tag's setup, can silently fail to run too. I reproduced this exact scenario in real Chromium alongside the correct pattern, Google's own documented window.dataLayer = window.dataLayer || [] snippet, which safely reuses an existing array or creates a new one without ever overwriting real, already queued events.

A real TypeError on the left, a real full event queue on the right, same browser.

The correct pattern also proves something worth trusting: a container script that loads after several dataLayer.push() calls still captures every one of them, because the real GTM container reads the entire existing queue the moment it loads and then patches push itself to keep processing anything pushed afterward. Google's own data layer developer guide documents this exact behavior, and Stape's end to end data layer guide walks through the same mechanics from a server side angle.

The second big source of GTM mistakes lives entirely inside trigger configuration, not code. A trigger compares real string values, and that comparison is case sensitive and strict by default, the same way JavaScript's own === operator is.

I wrote the exact comparison logic a trigger runs as a small real function and tested it against five real event objects, including a couple of the specific slip ups that show up constantly in real containers.

function evaluateTrigger(dataLayerEvent, trigger) {
  if (dataLayerEvent.event !== trigger.eventName) return false;
  // conditions must all pass, exceptions block a fire
  ...
}

The exact logic a real trigger runs, verified against five real cases.

Two of these GTM mistakes show up over and over in real audits: an event pushed as FormSubmit silently never matches a trigger configured for formSubmit, and a "contains" condition used where an "equals" condition was intended ends up firing a tag on every page whose path merely includes a substring, not just the one page it was meant for. Analytics Mania's own list of common Google Tag Manager mistakes catalogs a long list of these in the wild, and it's worth a read before your next audit.

Every container keeps a real version history, and every published version can be rolled back, but that safety net only helps after the damage is already visible in a report. Skipping Preview mode before publishing is one of the GTM mistakes that costs the most time to untangle later, precisely because nothing looks wrong at the moment it happens.

Simo Ahava's own writeup on workspace based change management is a good real example of treating a container the way a developer treats a codebase: a named workspace per change, a real Preview session before every publish, and a short note in the version description explaining what changed and why.

Multiple people editing the same default workspace at once is a related, quieter version of this same GTM mistake. Two overlapping edits merge in whatever order they happen to save, and neither person necessarily sees the other's changes before publishing.

Duplicate firing is one of the more visible GTM mistakes, because it inflates a number rather than silently losing it, which usually gets noticed faster. The most common cause is two separate tags both configured to send the same GA4 event, often left behind after a migration where an old tag was never actually removed.

A close cousin is a GA4 configuration tag and a GA4 event tag racing each other on the same trigger, sending an event before the configuration tag has actually initialized the measurement stream. Google's own tag best practices guide covers sequencing tags correctly so setup work always completes before anything depending on it runs.

The fix for almost every version of this particular mistake is the same: search the container for every tag matching a given GA4 measurement ID or event name before adding a new one, not after. It takes thirty seconds and it catches nearly all of these GTM mistakes before they ever reach a live page.

A newer category of GTM mistakes has grown alongside privacy regulation: tags firing before a real consent decision has been recorded, not just before a banner has visually closed. If a marketing tag's trigger doesn't actually check consent state, it can fire the instant the page loads, regardless of what the visitor clicks next. Our own guide to Consent Mode v2 covers wiring that check up correctly.

A page's own Content Security Policy can silently block the container script itself, or block a tag it's trying to load, and both failures look identical to a tag simply "not firing." If a security team tightens a CSP header without telling whoever manages GTM, tracking can quietly go dark site wide.

Moving to server side tagging fixes some of these problems and introduces new ones of its own, since an event forwarded incorrectly on the server side is much harder to spot than one failing visibly in a browser tab. Read our guide on server side tagging before making that move, and treat the client side and server side containers as two separate places these GTM mistakes can hide, not one.

A quarterly review catches most of this before it compounds. Compare the current live container against last quarter's version history, note which tags were added and why, and confirm each one still points at a real, currently used destination rather than a decommissioned account or a test property nobody remembers creating. This single habit closes off most new GTM mistakes before they've had time to skew a single report.

Run through this list quarterly, or any time a report starts looking suspicious, and most GTM mistakes surface within the first few minutes.

A real, independent data layer inspector is worth installing alongside GTM's own Preview mode. Dataslayer is a real open source browser extension built specifically to show every event on its way through the queue, which catches a surprising number of GTM mistakes that Preview mode alone doesn't surface clearly.