Permissions
GTM’s permission model is straightforward but frequently misconfigured — usually in the direction of too much access. Every GTM publish deploys code to your production website. The people who can publish should be a short, deliberate list.
Account vs. container permissions
Section titled “Account vs. container permissions”GTM has two permission levels:
Account level:
- Administrator — can manage account settings, add/remove users, create containers. Admin at the account level gets admin access to all containers in the account.
- User — can access containers within the account based on their container-level permissions.
Container level (what most people configure):
- No access — Can’t see the container at all
- View — Can browse the container and use Preview mode, but cannot make changes
- Edit — Can create and edit tags, triggers, variables, and workspaces, but cannot publish
- Approve — Can edit and create versions, but cannot publish directly. Must use the approval workflow.
- Publish — Can edit and publish. This is the highest level of container access.
Who should get what
Section titled “Who should get what”Publish access — Reserved for people who understand the security implications. Publishing runs arbitrary code on your production site. Limit this to senior analytics engineers, lead developers, or designated analytics leads. The goal is a very short list.
Edit access — The working level for most implementers. Developers adding dataLayer pushes can verify their work with Preview mode. Analytics team members can build tags and triggers. Neither group needs publish.
View access — For stakeholders who need visibility: product managers who want to understand what’s tracked, developers who need to check existing tag configurations, or analysts who need to debug their GA4 reports without editing capabilities.
Admin access — One or two people. Never give admin to contractors or external agencies. Admin can export your entire container, delete containers, and add new users with any permission level.
Recommended permission structures
Section titled “Recommended permission structures”Small team (startup, 1-5 person analytics team):
Admin: Analytics Lead (1 person)Publish: Senior Analytics Engineer (1-2 people)Edit: Analytics team, developers who implement dataLayerView: Product managers, data analystsMid-size company:
Admin: Analytics Lead + IT AdminPublish: Analytics Lead + Senior Analytics EngineerApprove: Analytics Engineers (changes go through a review before publish)Edit: Analytics team, contractors, development teamView: Marketing team, product teamEnterprise (separate GTM containers per team or brand):
Account Admin: IT/Governance team onlyContainer Admin: Per-container ownersPublish: Approved list per container (goes through change management)Edit: Platform-specific teamsView: Broad stakeholder accessAdding users
Section titled “Adding users”-
In GTM, go to Admin → User Management (at the account level) or the container-specific user management.
-
Click + to add a user.
-
Enter their Google account email address.
-
Set account-level permissions (User or Administrator).
-
Under Container Permissions, select the container(s) and the permission level for each.
-
Save.
The user receives an email invitation and gains access immediately on acceptance.
Agency access
Section titled “Agency access”When working with an external agency:
-
Never give admin access to agencies. They don’t need it, and it creates unnecessary risk.
-
Create a dedicated workspace for agency work so their changes are isolated and reviewable before publishing.
-
Give Edit-only access to their team. Only your internal lead should have Publish access.
-
Grant access at the container level, not account level — the agency only needs to see the specific container(s) they’re working on.
-
Time-box the access. Document when the access was granted. Set a calendar reminder to review quarterly.
-
Revoke access immediately when the engagement ends. This is the step most often forgotten. The day the contract ends, remove the users.
Agency team: Edit access on Container A onlyNo account-level accessNo access to Container B (other brands/products)The approval workflow (GTM 360 only)
Section titled “The approval workflow (GTM 360 only)”Standard GTM doesn’t enforce an approval workflow — anyone with Publish can publish without review. GTM 360 adds an Approve permission tier that enforces a review step before publishing:
- Users with Edit access can create changes
- Users with Approve access can review and create versions (but not publish)
- Only users with Publish access can push versions live
For standard GTM, approximate this with process: require that all changes be reviewed in Preview mode by a second person before the author submits. Make this a team norm, not an enforced technical control.
Audit trail
Section titled “Audit trail”GTM maintains a change history that shows who changed what and when. Access it via Admin → Activity History at the container level.
Each entry shows:
- What changed (tag name, trigger type, etc.)
- Who made the change (Google account email)
- When it happened
This is invaluable for debugging (“why is this tag different from last week?”) and for accountability in regulated environments. GTM’s audit history cannot be deleted or edited.
Two-factor authentication
Section titled “Two-factor authentication”GTM uses Google account authentication. If someone’s Google account is compromised, their GTM access is compromised. Require that all users with Edit or Publish access to GTM have two-factor authentication enabled on their Google account.
This is not enforceable from within GTM — it’s a Google account security setting. Make it a team requirement and verify during access reviews.
Quarterly access review
Section titled “Quarterly access review”Schedule a quarterly review of GTM permissions:
- Export the user list (you can do this via the GTM API or by manually checking Admin → User Management)
- Remove anyone who has left the company
- Remove anyone whose role no longer requires GTM access
- Downgrade anyone who has more access than they currently need
- Document the review
This sounds like overhead, but a former employee’s GTM account being used after they leave is a real security risk. Their account may have been compromised, or they may still have access through shared credentials.
Common mistakes
Section titled “Common mistakes”Giving agencies admin access
Section titled “Giving agencies admin access”Admin access lets them create new users, export the container, and manage your account structure. They need Edit access to do their job. They don’t need admin.
Everyone in Edit because it’s easier
Section titled “Everyone in Edit because it’s easier”When everyone has Edit access, anyone can accidentally publish (if they meant to click something else) or make changes that affect other people’s work. Maintain distinct tiers — it takes two minutes to set up and prevents significant problems.
Not revoking access when contractors leave
Section titled “Not revoking access when contractors leave”This is the most common security gap in GTM implementations. Build a process: when a contractor’s engagement ends, the access removal is part of the offboarding checklist.
Shared logins for GTM access
Section titled “Shared logins for GTM access”Some agencies share a single Google account for all GTM access. This means you can’t distinguish between team members in the audit log and you can’t revoke one person’s access without revoking the whole agency’s. Require individual accounts.