GTM User Permissions and Governance for Agencies and Teams

GTM is a powerful tool precisely because it lets non-developers publish code to a live website without going through a deployment pipeline. That power is also a risk: a misconfigured tag published by someone who doesn't understand its implications can break conversion tracking, duplicate events, or fire scripts on pages they shouldn't reach. Governance is how you get the benefit of GTM's flexibility without the downside of unchecked changes.

GTM Permission Levels

GTM has two levels of access control: Account and Container.

Account-Level Permissions

• User — can access containers they've been granted access to within the account
• Administrator — can manage account settings and add/remove users

Container-Level Permissions

• No Access — cannot see or interact with the container
• Read — can view the container configuration but cannot make changes
• Edit — can create and modify tags, triggers, and variables but cannot publish
• Approve — can review and approve changes submitted by Edit-level users for publishing
• Publish — can publish the container to live without approval

The Approve level is a GTM feature that many teams don't use but should: it creates a mandatory review step before changes go live. An Edit-level user submits a workspace for approval; a Publish-level user reviews and publishes it.

Recommended Permission Structure for Agencies

Client Controls the Account

The client should own the GTM account. This means the client's Google account is the account administrator, not the agency's. If the agency relationship ends, the client retains full access to all their containers without needing to request a transfer. Agency access should be granted at the container level, not account level.

Agency Gets Edit or Approve Access, Not Publish

Agencies typically don't need Publish access. With Edit access, they can build and test everything in a workspace; the client or a designated senior team member holds Publish access and reviews before anything goes live. This creates a natural QA checkpoint and gives the client visibility into what's being published.

For agencies that do have Publish access (because the client isn't technically capable of reviewing), compensate with rigorous internal approval processes and thorough preview testing before publishing.

Using Workspaces for Parallel Development

Workspaces let multiple team members work on different changes simultaneously without conflicting. Each workspace is an isolated copy of the container where changes can be made and tested independently.

Best practices:

• Create a workspace per task or project: "GA4 Ecommerce Setup", "Black Friday Tags", "Meta CAPI Migration"
• Name workspaces descriptively — the default workspace should only be used for emergency hotfixes
• Delete workspaces after merging to keep the workspace list clean
• Don't let workspaces accumulate stale changes — a workspace that's been open for 3 months without publishing is a source of future merge conflicts

Version Management

Every time you publish, GTM creates a container version. These are invaluable for rollbacks. The version history should tell a coherent story about what changed and why:

• Always add a version description when publishing — "Added GA4 purchase event", "Removed old AdWords remarketing tag"
• Never publish without a description. A list of "Version 47", "Version 48", "Version 49" with no notes is useless when debugging
• If a publish breaks something, use Publish → Revert to Published Version to immediately roll back

GTM Environments

GTM Environments let you publish different container versions to different environments (staging, dev, production) simultaneously. Create a Staging environment and give your developers the staging GTM snippet to use on their test site. This lets you test full tag configurations against real data before pushing to production — more reliable than GTM Preview mode alone.

Security Considerations

• Audit user lists regularly — remove access for former employees and ended agency relationships immediately
• Don't share a single Google account among team members — each person should have individual access so the audit trail shows who made which change
• Review custom HTML tags before publishing — custom HTML tags can execute arbitrary JavaScript. A tag from an unfamiliar source should be reviewed by someone who can read JavaScript before it goes live
• Be cautious with template permissions — community templates can request broad permissions (injecting iframes, accessing globals). Review what permissions a template requests before installing it

Documenting Your GTM Container

Governance isn't just about permissions — it's about making the container understandable to anyone who works on it. Minimum documentation requirements:

• A naming convention document that explains how tags, triggers, and variables should be named
• Notes on each tag explaining what it does, who requested it, and when it was added
• A container changelog (beyond GTM version descriptions) that links to tickets, campaigns, or project references

Conclusion

GTM governance is an investment in reliability. The 20 minutes spent setting up correct permissions, naming conventions, and version description habits saves hours of debugging when something goes wrong — and prevents the more catastrophic scenario where an unreviewed tag breaks conversion tracking on a high-traffic day.

Adslytics helps clients establish GTM governance frameworks that work for their team structure — whether in-house, agency, or hybrid. Reach out to discuss how we can help.