Inheriting a GTM Container You Didn't Build
You open GTM and see 150 tags. Some have descriptive names (GA4 - Page View - All Pages). Some don't (Conversion Tag 3). Some are paused. A few have names that suggest they were temporary (test_conversion_v3_FINAL). The triggers follow at least three different naming conventions, suggesting three different people or agencies contributed at different times. The variables include constants with values that might be API keys or might be measurement IDs, and there's no documentation to clarify which.
This is the typical experience of inheriting a GTM container. It's the most common scenario in analytics operations: a new job, a new client, a new agency relationship, or a colleague leaving. The container is the product of years of accumulated work by people who aren't available to explain it.
The instinct is to start fixing things. The better approach is to understand the container first, then decide what needs fixing.
First pass: orientation
Before touching any tags, build an understanding of what the container does, who it serves, and what it's connected to.
What platforms are present? Scan the tag list for recognizable types: GA4 tags (measurement), Google Ads (paid search), Meta/Facebook (social advertising), LinkedIn (B2B advertising), Microsoft UET (Bing ads), Floodlight (CM360). This tells you which marketing platforms depend on this container and which teams will be affected by changes.
What's the consent situation? Check whether a CMP tag exists (OneTrust, Cookiebot, or a Custom HTML consent implementation). Check whether tags have consent settings configured. If native Google tags show consent as NEEDED, the template is handling it. If Custom HTML tags show NOT_SET, they're firing unconditionally. Also check the page source for CMP scripts loaded outside GTM, which is the more common deployment pattern.
What's active versus inactive? Paused tags are easy to identify (GTM marks them clearly). Dead tags are harder. Universal Analytics tags (type ua) are dead code since July 2023. Custom HTML tags loading scripts from vendors the company no longer uses are dead code even though they're active. Tags named with prefixes like [Remove], OLD_, TEMP_, or test_ are candidates for review.
What's in Custom HTML? Custom HTML tags are the black boxes of every container. They contain vendor scripts, utility functions, data transformations, and occasionally things that shouldn't be there (PII in the dataLayer, obfuscated code, legacy scripts from expired vendor relationships). For each Custom HTML tag, classify what it does: loads an external script, pushes to the dataLayer, reads/writes cookies, manipulates the DOM, or contains ad pixel code. This classification determines the consent requirements and security profile of each tag.
Second pass: the data flow
Once you know what platforms are present and which tags are active, map how data moves through the container.
Which triggers fire which tags? GTM's interface shows this per-tag, but the container-level view (which trigger fires the most tags, which tags share triggers) reveals the architecture. A single "All Pages" trigger firing 12 tags is different from 12 tags with individual page-specific triggers. The first is a broadcast architecture (every tag fires everywhere). The second is a targeted architecture (tags fire only where they're needed).
Which variables feed which tags? Constants containing measurement IDs, lookup tables mapping page paths to conversion values, data layer variables reading form fields or user properties. The variables are the data supply chain: they determine what values reach which tags. A variable with a misleading name or an outdated value can silently corrupt data across every tag that references it.
What's pushing to the dataLayer? Both the site's code (developers pushing events and user data) and Custom HTML tags (utility scripts transforming or enriching data) push to the dataLayer. Understanding what data is available and where it comes from is essential for knowing whether the tags are receiving the values they expect.
Third pass: the problems
With orientation and data flow understood, the findings surface naturally.
Dead code. UA tags still firing. Vendor scripts for tools the company no longer uses. Paused tags from projects that ended years ago. _gaq.push() calls from pre-2014 implementations. Each can be removed or paused without affecting active tracking, but should be verified individually before removal.
Consent gaps. Custom HTML ad pixels without consent configuration. Native tags that have consent set to NEEDED but no CMP exists to set consent state. Tags with consent types that don't match their function (an ad tag using analytics_storage instead of ad_storage).
Data quality issues. GA4 event names with inconsistent casing (page_view and Page_View as separate events). Events that duplicate Enhanced Measurement defaults. Parameters with legacy UA naming (event_category, event_label, event_action). Debugging parameters like gtm_tag_name still present in production.
Duplicate tracking. Multiple tags firing the same event on the same trigger. Hardcoded gtag.js in the page source alongside GTM-deployed GA4 tags. Two Meta Pixel tags initializing the same Pixel ID.
Organizational debt. Mixed naming conventions across tags, triggers, and variables. No folder structure or an inconsistent one. Tags that do the same thing for different pages instead of one tag with a conditional trigger. Variable names that don't describe their contents.
The hostage container problem
A specific scenario that deserves its own section: the container was created by a previous agency under their own Google account, and the client was given only View or Edit access, not Admin or Publish.
This is the "hostage container" pattern. When the agency relationship ends, the agency retains administrative control of the container, and the client can't publish changes, export the container, or transfer it to their own account without the agency's cooperation. In the worst cases, the agency cuts access entirely or demands payment for transferring ownership of a container that contains the client's own tracking infrastructure.
Google's official guidance is clear: the client should always own the GTM container. The proper structure is for the client to create the GTM account, then invite the agency with container-level Edit or Approve permissions. The agency should never be the account owner.
If you've inherited a hostage container, the options are: negotiate transfer with the previous agency (the easiest path), recreate the container from scratch (the hardest path but gives you clean ownership), or use the container recovery approach (export the public endpoint data and rebuild from that). For future agency relationships, ensure the GTM account and container are created under the client organization's Google account from the start.
What to document
The orientation and data flow passes produce knowledge that should be recorded for the next person. A container without documentation is a container that will be inherited blindly again.
The minimum useful documentation:
Platform inventory. Which analytics and ad platforms are connected, their account/property IDs, and which team manages each platform.
Tag purpose. For any tag where the purpose isn't obvious from the name and configuration, a one-line description of what it does and why it exists. This is especially important for Custom HTML tags where the code isn't self-explanatory.
Known issues. Findings from the third pass that haven't been fixed yet, with context about severity and priority. "UA tags still active, safe to remove, low priority" is more useful than silence.
Access and ownership. Who has Admin, Publish, Edit, and View access to the container, and who should be contacted for changes.
This documentation can live inside GTM (tag notes, container notes) or alongside it (a Notion page, a Google Doc, a README in the project repository). The format matters less than the existence. A container with documentation is a container the next person can understand without starting from scratch.
The ongoing habit
Inheriting a container is a one-time event. Maintaining it is ongoing. The habits that prevent the next person from facing the same archaeology:
Document every tag when it's added. The 30 seconds spent writing a tag note saves 30 minutes of investigation later.
Remove tags when their purpose is fulfilled. Campaign tracking tags, A/B test implementations, and vendor trial integrations should have a removal date or a review trigger, not an indefinite lifespan.
Review the container quarterly. A 15-minute scan of the tag list, checking for paused tags that should be removed, active tags that should be paused, and naming convention drift, prevents the slow accumulation that makes inheritance painful.
Name everything as if you're explaining it to someone who's never seen the container. Because eventually, someone who's never seen the container will need to understand it. That person might be you, six months from now, wondering why Conversion Tag 3 exists.