The GTM Governance Playbook:
How to Keep Your Container Clean Long-Term

Most GTM cleanup projects end the same way. The container gets audited. Zombie tags get removed. Naming conventions get retroactively applied. Someone builds a spreadsheet of what's left. Everyone agrees to do better. Six months later, the container is already accumulating again — new tags added without documentation, naming conventions ignored by the next contractor, a departed agency's pixels still in there because nobody had the authority to remove them.

The audit addressed the symptom. Nobody addressed the system.

A GTM governance playbook is the operational model that prevents accumulation from happening in the first place. It defines how tags get added, who can approve them, what they must be named, and when the container gets reviewed. It's not glamorous work, but it's the difference between a container that stays clean and one that needs another emergency cleanup in a year.

Naming conventions — the foundation everything else builds on

Naming conventions matter more than most teams realize. A container where tags are consistently named is a container where anyone can do a quick scan and understand what's there — what platform it's for, what it does, and whether it's current. A container with inconsistent naming requires opening every tag individually to understand what it does, which means nobody ever does a full review.

The format that works consistently across containers of different sizes:

The convention only works if it's enforced. That means every new tag must follow it before it gets approved, and retroactively named tags from cleanup get updated to match. A single out-of-convention tag signals that the standard is optional — and optional standards are ignored.

Ownership — every tag needs an owner

The most common reason zombie tags survive cleanup is that nobody is sure who owns them and therefore nobody takes responsibility for removing them. Ownership rules prevent this by requiring that every tag in the container is associated with a named person or team before it can be published.

The ownership model that works in practice:

• Container owner — one person with ultimate authority over the container. They approve all additions, can override requests, and are responsible for the quarterly review. Usually an analytics lead or marketing ops manager.
• Tag requester — the person or team that wants the tag added. They're responsible for providing the brief, the business justification, and confirming when the tag is no longer needed.
• Technical implementer — the person who actually builds and publishes the tag. May be the same as the container owner or a developer/agency.

Ownership information should live in the tag's notes field in GTM. At minimum: who requested it, when it was added, what campaign or initiative it supports, and a review date if it was added for a time-limited purpose.

The change request process — no brief, no tag

Tags added informally — through a Slack message, a verbal request, or an agency just publishing directly — are tags without documentation. They're the origin point of every zombie tag problem. A lightweight change request process creates the paper trail that makes future audits tractable.

The process doesn't need to be bureaucratic. For most teams, a simple form or template is enough:

The key friction point is step one. Making it slightly effortful to add a tag — not impossible, just intentional — filters out casual additions and ensures every tag has a business owner from the moment it goes live.

Access permissions — who can publish

GTM's permission model gives you fine-grained control over who can do what in a container. Most teams don't use it. The typical setup is that anyone who needs to add a tag gets full publish access — which means there's no technical barrier to bypassing the change process.

A more controlled model:

• Read only — stakeholders, clients, anyone who needs to see what's in the container
• Edit (no publish) — agencies and contractors building tags. They can create and test but can't publish without approval.
• Publish — container owner and designated backup only. Every publication goes through one of these people.

Restricting publish access is the single most effective technical control you can add. If nobody can go live without the container owner, the change process becomes mandatory rather than advisory.

The quarterly review cadence

Even with a strong intake process, containers accumulate over time. Campaigns end. Platforms get replaced. Business priorities shift. A quarterly review is the mechanism that catches what the day-to-day process misses.

A quarterly review should take two to three hours and cover:

• Every paused tag — still needed, or can it be removed?
• Tags added in the previous quarter — are they all still serving their stated purpose?
• Tags with review dates that have passed — confirm with owners whether to keep or remove
• Container capacity — if it's grown significantly, identify what's driving it
• Consent coverage — any tags without consent triggers added since last review?
• Access audit — any users who no longer need access?

The quarterly review is also the right moment to run the automated container audit. It surfaces issues that are easy to miss manually — duplicate tags, trigger coverage gaps, legacy UA tags — and gives you a baseline to compare quarter over quarter.

What to put in the playbook document

The governance playbook itself should be a living document, not a one-time deliverable. The version that works in practice is usually a shared document (Google Doc, Notion page, or Confluence page) with the following sections:

• Container overview — what the container is for, what site(s) it covers, who the container owner is
• Naming conventions — the exact format for tags, triggers, and variables with examples
• Change request process — how to request a new tag, the approval process, expected turnaround
• Ownership rules — who can access the container, what each access level can do, how to request access
• Agency management — how agencies are onboarded, what they can access, the offboarding checklist
• Review cadence — when quarterly reviews happen, who runs them, what the checklist covers
• Container inventory — a link to the live spreadsheet of all current tags

The document only works if it's maintained. Assign ownership to the container owner and build the quarterly review into their calendar. A governance playbook that nobody reads is not governance.

Travis Gunn

Founder of GA4 Health Check. Working with Google Analytics since 2013, with over 250 clients audited across almost every industry vertical. 100% Job Success on Upwork for over a decade.