How to Add Users to Google Tag Manager the Right Way

How to Add Users to Google Tag Manager Without Losing Control

Last quarter I inherited a GTM container from a mid-market ecommerce brand. Fourteen people had publish access. Three of them had left the company over a year ago. One was an agency intern who had pushed a broken Facebook pixel to production in November — nobody noticed until January, when remarketing audiences quietly bled out. The fix took twenty minutes. The revenue lost in those two months was north of EUR 40,000.

This is not an edge case. It is what happens when teams treat Google Tag Manager user permissions as an afterthought — something you configure once during onboarding and never revisit.

This post walks you through how to add users to Google Tag Manager properly, how to structure permissions so they match real workflows, and how to keep your container audit-ready as your team grows.

Understanding the Permission Hierarchy

Google Tag Manager operates on two levels: account and container. Permissions are granted independently at each level, which is where most of the confusion starts.

Account-Level Permissions

Permission	What it allows
User	View account details, view containers in the account
Admin	Everything above, plus managing users and creating containers

Container-Level Permissions

Permission	What it allows
No Access	User cannot see the container at all
Read	View tags, triggers, variables, and versions — cannot edit
Edit	Create and modify workspace items — cannot publish
Approve	Edit plus approve versions, but cannot publish live
Publish	Full control: create, edit, approve, and push live

The "Approve" tier is often overlooked. It exists precisely for teams that want a review gate before anything goes live — and I strongly recommend using it. If your organisation spends meaningful budget on paid media, having at least one review step between editing and publishing is non-negotiable.

Step-by-Step: Add a User to Google Tag Manager

Here is the exact process to add user to Google Tag Manager at the container level:

1. Open tagmanager.google.com and select the account.
2. Click Admin in the top navigation.
3. Under the container column, click User Management.
4. Click the + button, then Add users.
5. Enter the user's Google account email address.
6. Set the container permission: Read, Edit, Approve, or Publish.
7. Click Invite.

The user receives an email and must accept the invitation before access takes effect. If you need to grant access to multiple containers within the same account, you can also manage this from the Account > User Management panel, where you set account-level and container-level permissions in one view.

Google's own documentation on managing user permissions covers the interface in detail. What it does not tell you is which permission each person on your team actually needs.

Mapping Permissions to Roles

Here is the framework I use when setting up Google Tag Manager permissions for clients:

Role	Account permission	Container permission	Rationale
Marketing manager / CMO	Admin	Approve	Oversight without accidental publishes
Performance marketer (in-house)	User	Edit	Creates conversion tags, someone else publishes
Analytics engineer	Admin	Publish	Owns the container, deploys reviewed changes
External agency	User	Edit	Works in a dedicated workspace, cannot push live
Developer (implementation)	User	Read or Edit	Depends on whether they build tags or just QA
Intern / new hire	User	Read	Learning, reviewing, cannot break anything

The principle: give the minimum permission that lets someone do their job, and nothing more. Google calls this the principle of least privilege in their IAM documentation. It applies equally to GTM.

If you are unsure whether your current permissions match this model, or if your container has accumulated users from past agencies and employees, a tracking audit will surface exactly who has access and whether their permission level still makes sense.

Common Mistakes I See With Google Tag Manager User Permissions

1. Everyone Gets Publish

The most frequent anti-pattern. When everyone can publish, nobody feels responsible for reviewing changes. I have seen containers where ten people had publish access and zero people routinely checked the activity log before a new version went live.

2. Using Personal Gmail Accounts

When employees use their personal email (e.g., john.smith.personal@gmail.com) instead of a company-managed Google account, you lose the ability to revoke access centrally through your identity provider. The moment they leave, you are hunting down personal addresses in multiple tools.

3. Never Revoking Access

Google Tag Manager does not automatically remove users who leave your organisation — even if you disable their Google Workspace account, GTM permissions granted to aliases or external emails persist. Schedule a quarterly review. I add it to the same calendar reminder as my clients' naming and governance review.

4. Granting Account-Level Admin to Agencies

An agency should almost never be an account-level admin. That permission lets them create new containers, invite other users, and modify account settings. Give them User at the account level and Edit (or at most Approve) at the container level.

5. Ignoring Workspaces Entirely

GTM workspaces exist to isolate parallel editing. If you grant Edit access to multiple people but do not enforce workspace discipline, you end up with conflicting changes and messy version histories. Workspaces are your safety net — pair them with proper permissions and your container stays clean. When workspace changes interact with triggers, misconfigurations can go undetected for weeks, which I cover in detail in this post on trigger misconfigurations.

Automating User Management at Scale

For organisations with dozens of containers — franchise brands, multi-market operations, agency groups — manual user management breaks down. Two options:

Google Tag Manager API: The GTM API v2 exposes account and container permissions programmatically. You can script user provisioning, bulk-remove departed employees, and generate access reports. I typically build a lightweight Python script that pulls current permissions into a spreadsheet, highlights anomalies (publish access for inactive users, personal emails, etc.), and flags containers with no admin.

Google Workspace integration: If your company runs Google Workspace, you can use Google Groups to manage access. Invite the group email to GTM, and membership changes propagate automatically. This is not natively documented for GTM, but it works because GTM resolves Google Group membership at the time of access — as confirmed in Google's Cloud Identity documentation.

An Audit Routine for GTM Permissions

I recommend a quarterly cadence:

1. Export the user list from Admin > User Management (or pull it via the API).
2. Cross-reference against your current employee roster and active agency contracts.
3. Remove any user who no longer needs access. Do not downgrade — remove.
4. Verify that no single container has more than two or three users with Publish.
5. Check that at least two people have Admin at the account level (bus-factor protection).
6. Document changes in a changelog — the same way you would for tag deployments.

If you pair this with a solid debug and QA checklist, your container stays healthy between audits rather than slowly decaying.

When Permissions Alone Are Not Enough

Permissions control who can do what. They do not control what gets done well. A user with Edit access can still create a poorly scoped trigger that fires on every page, or push a conversion tag that double-counts purchases.

That is why permissions are one layer of a broader governance model. You also need:

• A naming convention that makes every tag's purpose obvious at a glance.
• Folder structure that separates marketing platform tags from analytics and utility tags.
• A review process before anything is published — whether that is a Slack thread, a Notion checklist, or a formal approval workflow.

I build all of this during a full tracking audit. Permissions are usually the fastest fix, but they are rarely the only thing that needs attention.

FAQ

Not sure who has access to your GTM containers — or whether the permissions still make sense? Book a tracking audit and I will map every user, flag the risks, and hand you a clean permission structure you can enforce going forward.