IT had run a script audit on the company website. They found over 40 third-party scripts loading on every page and wanted answers: who authorized each one, what it does, and why several of them belong to ad partners the company stopped working with two years ago. Marketing couldn't answer most of those questions. The GTM container had been accumulating tags for four years across multiple agencies, platform migrations, and campaign experiments. Nobody had ever removed anything.
The container was sitting at nearly 80% capacity. Nobody had realized GTM containers had a size limit until the warning appeared. IT was treating it as a security incident. Marketing was treating it as an IT problem. Neither team had the full picture.
This is what poor GTM container hygiene looks like in practice. And it's far more common than most analytics teams realize, because the problem builds slowly and invisibly until something forces it into view.
What GTM container hygiene actually means
Container hygiene is the ongoing practice of keeping a GTM container intentional — knowing what every tag does, why it's there, whether it's still needed, and whether it's configured correctly. A well-maintained container has no orphaned tags, no redundant tracking, no scripts from vendors you no longer work with, and a clear ownership trail for everything that fires.
In practice, most containers don't look like that. They look like archaeological sites — layers of implementation decisions made by different people at different times, with nothing ever cleaned up. The agency that built the original implementation is long gone. The ad platform that needed four separate tags has been replaced by a different one that also needed four tags. The "temporary" test tag from eighteen months ago is still there, quietly firing on every page.
The container still works, in the sense that things fire. But what's firing, why, and whether any of it is still accurate — those questions don't have easy answers.
How containers get into this state
GTM makes it very easy to add tags and very friction-free to leave them. Publishing a new tag takes minutes. Removing an old one requires knowing what it does, confirming with whoever requested it that it's safe to remove, and taking the responsibility for anything that breaks — so most people don't bother.
The typical accumulation pattern looks like this:
- Each ad platform your team has ever tested requires its own pixel, conversion tag, and often a remarketing tag — typically 3–5 tags per platform
- Agencies add their own tracking on top of yours, often without documentation
- When you switch platforms, the old tags rarely get removed — you just add the new ones
- One-off tags for specific campaigns ("just add this for the trade show") never get cleaned up
- A/B testing tools, heatmap tools, chat widgets, and survey tools each bring their own tag requirements
- Nobody has a clear list of what was added when or by whom
After two or three years of this, it's not unusual to find a container with 80–120 tags where a quarter of them are no longer serving any business purpose — and another quarter where nobody can say for certain whether they're needed or not.
The four real costs of a neglected container
Every tag in your container is JavaScript that executes in the user's browser. Not all tags are equal — a simple analytics tag might be a few kilobytes, while a full-featured ad platform tag with audience syncing, conversion tracking, and cross-device matching can be significantly heavier. A container with four ad platform integrations, each with multiple tags, can easily add several seconds to page load on slower connections.
Tag load order matters too. Tags that fire synchronously block page rendering until they complete. Even asynchronous tags compete for network bandwidth and browser processing resources. The more tags you have, the more each user's session starts with a measurable performance cost — one that shows up in Core Web Vitals, bounce rates, and paid media quality scores.
The bloat compounds. It's not just the number of tags — it's that many ad platform tags pull in additional third-party scripts, pixels, and iframes dynamically. A single tag can be the entry point for four or five network requests you don't see in GTM's tag list.
Every third-party script you load is code you didn't write, running in your users' browsers, with access to everything on the page — form fields, DOM content, local storage, cookies. You're trusting the vendor not to change their script in ways that harm your users. Most of the time that trust is warranted. But the more vendors you have loaded, the larger the surface area for things to go wrong.
The specific risk with zombie tags — tags for platforms you no longer actively work with — is that you may not notice if those vendors are acquired, compromised, or simply start behaving differently. You're not monitoring them because you've forgotten they're there. You won't know there's a problem until something visible goes wrong.
IT's concern in this scenario is legitimate. A list of 40+ third-party scripts on every page, many of them unaccounted for, is a meaningful security question. The answer "we're not sure what some of those do" is not a comfortable position to be in, particularly under GDPR or CCPA.
Under GDPR, CCPA, and most other modern privacy regulations, you're required to have a lawful basis for each piece of tracking you run. For most ad and analytics tags, that means explicit user consent. Consent Mode and CMPs (consent management platforms) are supposed to gate tags based on user preferences — but that only works if every tag in your container is correctly mapped to a consent category.
In a cluttered container, this mapping is rarely complete. Tags added informally, by contractors, or during a period before consent infrastructure was in place often have no consent trigger at all — meaning they fire for everyone regardless of what they chose in the cookie banner. You may be running non-consensual tracking without knowing it.
The compliance exposure from unknown tags isn't theoretical. Regulators have issued fines specifically for tracking that continued despite users opting out, often because the technical implementation of consent was incomplete. A tag you've forgotten about is a gap in your consent coverage you can't see.
A bloated container degrades analytics data in ways that are easy to miss. Zombie tags that were once conversion tags may still be firing — creating duplicate or phantom conversions in platforms that are no longer actively managed. Tags that fire on incorrect triggers send events at the wrong time or on the wrong pages, inflating event counts and distorting funnel data.
Multiple overlapping analytics implementations — common when agencies layer their own tracking on top of an existing GA4 setup — create redundant data streams that can conflict with each other. Session counts, attribution, and conversion metrics become unreliable, and diagnosing why is difficult when you don't have a clear picture of everything that's firing.
The data quality problem is often invisible. Numbers in your reports look plausible. Nothing is obviously broken. But decisions made on that data are being made on inflated event counts, misattributed conversions, or engagement metrics that include developer sessions from a staging environment a zombie tag is still tracking.
The capacity problem — GTM has limits
GTM containers have a size limit. When you publish a container, all of its tags, triggers, variables, and configuration are compiled into a single JavaScript file that loads on every page. That file has a size ceiling, and as a container grows, you'll start to see a capacity indicator in GTM's interface warning you how close you are.
At 80% capacity, you're not just getting a warning — you're close to a situation where new tags can't be added without removing old ones first. For a marketing team in the middle of a campaign launch, hitting that ceiling at the wrong moment is a genuine operational problem.
The container limit is a symptom of the underlying problem, not the problem itself. A container at 80% capacity has almost certainly accumulated significant dead weight — but the right response is a structured audit and cleanup, not emergency deletion.
Warning signs your container needs attention
What a well-maintained container actually looks like
A clean container isn't necessarily a small one — a complex site with multiple analytics tools, a paid media program, and a CMP will legitimately have a lot of tags. What makes a container well-maintained isn't the tag count, it's the intentionality.
In a healthy container, every tag has a clear name that identifies the platform, purpose, and version. Every tag fires on an explicit trigger that someone made a deliberate decision about. Every tag is connected to a consent category. There are no tags from vendors the business no longer works with. And if someone asks why a specific tag is there, someone on the team can answer.
Achieving that state requires an audit of what's currently in the container, a structured process for removing what doesn't belong, and — critically — a governance model that prevents the accumulation from starting again. How to do each of those things is covered in the next posts in this series.
