Who Has Access to Your GA4 and GTM?

Ask an analytics team who has publish rights on their GTM container and you will usually get a confident answer that is wrong. Not because anyone is careless — because access accumulates through a series of individually reasonable decisions, and nothing ever prompts a review.

A contractor needs Edit for a two-week project. An agency needs Publish during a migration. A developer needs access to debug something urgent. Each grant is correct at the time. None of them expire, and three years later the container that controls every script on your production website is editable by eleven people, four of whom no longer work with you.

Why the container is the security boundary

It is worth being precise about what GTM Publish access actually is.

A published GTM container executes arbitrary JavaScript on every page of your website, in your users' browsers, with full access to the DOM, cookies, and any data on the page. A Custom HTML tag can read a form field. It can read a session token in localStorage. It can load a script from any third-party domain.

Publish access on your container is functionally equivalent to deploy access on your front end, without any of the controls that surround deploys. No code review, no CI, no approval gate, no rollback plan beyond GTM's own version history. Most organisations that would never grant production deploy access to an external agency have granted that agency GTM Publish, because it does not feel like the same thing.

It is the same thing. That framing is usually what gets an access review scheduled.

The roles, and which ones actually matter

GA4 property roles. Administrator, Editor, Marketer, Analyst, Viewer, plus separate data restrictions for cost and revenue metrics.

Administrator is the one to count. It can change data retention, delete the property, add and remove users, and modify filters. Editor cannot manage users but can change configuration in ways that affect data permanently — a data filter switched on incorrectly will drop traffic you never get back.

Access can be granted at the account level and inherited by every property under it. This is the most commonly missed piece of an access review: someone with Account Administrator has Administrator on every property in that account, and they will not appear when you look at a single property's user list without checking inheritance.

GTM roles work in two layers.

Account level: No access, User, or Admin. Account Admin can create containers and manage account users.

Container level: No access, Read, Edit, Approve, Publish. Publish is the one that ships code to production. Approve without Publish is a genuinely useful middle ground for agencies — they can prepare a version and someone on your side ships it — and it is almost never used.

Running the review

Enumerate everything. Every GA4 account and property, every GTM account and container. Missing one is the norm rather than the exception: a legacy property from a site migration, a container someone created for a landing-page test in 2023.

Then, for each, list every user with their role — including account-level grants that inherit down.

Classify each person. Four buckets:

• Current staff who need this level. Fine.
• Current staff with more than they need. A marketer with Property Administrator. Reduce.
• External parties. Agencies, contractors, freelancers, partners. Each needs a live engagement justifying it.
• People who should not be there at all. Departed staff, finished agencies, personal accounts of people you cannot identify.

That last bucket is not a hypothetical. On a first review of an account older than two years it is routinely non-empty.

Look for the specific patterns.

Personal Gmail addresses. Someone used their own account instead of a work one. When they leave, offboarding does not touch it, and you may have no way to identify who it is.

Shared or generic accounts. analytics@company.com with Administrator, used by four people. No attribution, no offboarding, and the password is in a shared document.

Former agencies. The engagement ended, the access did not. Very common, and it is a live third-party dependency on a company you have no current contract with.

Account-level grants. Someone with Account Administrator on the GA4 account, which inherits Administrator on all fourteen properties. They probably needed it on one.

Nobody with Administrator. The opposite failure. The only Admin left the company and the account is now unmanageable. Every account needs at least two Admins, on work accounts, documented.

Produce a decision list. Not observations — actions. Each row: who, what they have, what they should have, who decides, by when.

Make the changes, and record them. A change log matters here specifically because access is a compliance question. "We reviewed access on 19 March and removed four external parties" is an answer. "We do it periodically" is not.

Keeping it current

A one-off review decays immediately. Three lightweight habits keep it from decaying.

Tie removal to offboarding. GA4 and GTM go on the same checklist as email and the VPN. This is the single highest-leverage change and it is usually just a line added to an existing document.

Tie access to engagements. When an agency contract ends, access ends with it — same day, in the contract. Not "we will get around to it."

Review quarterly. Fifteen minutes if you did it last quarter. The first one is an hour; every subsequent one is a diff.

Two structural changes are worth considering if you grant external access regularly:

Use Approve instead of Publish for agencies. They build and stage; you review and ship. This is the same control model as a pull request, and it exists in GTM already.

Use environments for testing access. GTM environments let someone test in a non-production context without production Publish rights.

The other half: what they can reach

Access to a container is access to what the container touches. Two containers with identical user lists can carry very different risk depending on what is inside them.

A container full of Custom HTML tags loading third-party scripts is a materially larger surface than one built entirely from native templates. If you are reviewing access, review the container's contents in the same pass — dependency mapping covers what is actually in there, and the Custom HTML inventory is the part that matters here.

The same applies on the GA4 side. Editor access matters more on a property with a 2-month retention setting than one on 14 months, because the window for noticing and reversing a bad change is shorter.

What the deliverable looks like

An access review that ends in a spreadsheet nobody opens is a wasted afternoon. The version that works is three short sections:

The current state, as a table of person, resource, role, and classification. This is the evidence.

The removals, as a list with a date and an owner. This is the action.

The standing rules — offboarding integration, contract clauses, review cadence, the two-Admin minimum. This is what stops the next review finding the same things.

Then put the next review in the calendar before you send it.

How Tagfire helps

The tedious part of this is enumeration. Clicking through fourteen properties and nine containers, copying user lists into a spreadsheet, then cross-referencing account-level grants that inherit down, is an afternoon of work that produces a document out of date the following week.

Access Governance does the enumeration in one pass. Connect your Google account and it reads user and role assignments across every GA4 property and every GTM container you can see, then presents them as one list you can pivot three ways:

• By user — everything one person can reach, across every property and container. This is the offboarding view, and it is the one that is hardest to build by hand.
• By resource — everyone who can touch this property or container. The risk view.
• By role — everyone with Administrator, or everyone with Publish. The fastest way to answer the question this article opens with.

Filter, then export the whole thing to CSV so the review has an artefact you can attach to a compliance record or hand to a client. Re-run it next quarter and the diff is your report.

It uses read-only Google scopes for the audit itself — analytics.manage.users.readonly and tagmanager.readonly — so running the review cannot change anything.

Two companions worth running in the same session: the GTM Audit covers the container contents side, including Custom HTML security risks and tags loading third-party scripts, and the GA4 Audit covers the property configuration that Editor access can change.

The documentation covers running an access audit and exporting the report.