GA4 User Groups and the Admin API: Managing Team Access at Scale

Google added a User Groups Admin API to Analytics on 5 October 2026. The changelog entry is four bullets long, which is why most teams will skip it. If you manage Analytics access for more than a handful of people, it is the most practically useful thing Google has shipped this quarter.

Most companies still hand out GA4 access one email address at a time. That works fine at three users. It stops working at thirty. A contractor finishes, an agency hands an account back, a client adds someone from a newly acquired team, and a year later nobody can say who still holds Administrator on the property. User groups exist to solve that, and the API now lets you maintain them without clicking through the interface every time.

What the October release adds

The release covers three operations. You can create a group, edit its details, or delete it using its unique identifier. You can add users to a group and remove them again. You can assign each member a permission level of either Member or Owner.

To use any of it you need the User Admin or Org Admin permission on the organization that owns the Analytics account. A property-level Editor role is not enough to touch groups, no matter how much you can do inside the property.

User groups are an organization feature

This is the first thing that catches people out. A user group does not belong to an Analytics account or a property. It belongs to the organization the account sits under. If your Analytics account is not linked to an organization, Analytics will walk you through creating and linking one the first time you try to make a group.

Groups are visible only inside the organization that created them. Organization admins and product admins can see every group in their own organization, and nobody outside it sees anything. When you create a group you become its owner, and you can designate other owners.

Membership is cumulative. A member inherits the group's permissions and keeps whatever permissions they hold separately. If someone is already an Editor on a property and you add them to a Viewer group, they are still an Editor. Groups add permission, they never subtract it. Any access review that assumes joining a group normalises someone's access is built on a wrong assumption.

Groups can hold users, and they can hold other groups, so you can nest them. Google's own example is an All Employees group containing North America Employees, Europe Employees and Asia Employees. Nesting is genuinely useful and it is also the fastest route to an access structure you cannot audit. Build one layer at a time and only where a real difference in access exists.

The permission model you are wiring up

Five roles apply across the Analytics hierarchy. Administrator has full control and can manage users, including granting any role for any account or property they administer. Editor has full control of property-level settings but cannot manage users, though they can view them. Marketer can create and edit audiences, events and key events, import key events into Google Ads and edit attribution settings. Analyst can share explorations and, on Analytics 360, request unsampled ones. Viewer can see settings and data and create explorations. None means no role at that level.

Permissions inherit downward. Grant Editor at account level and that person is Editor on every property in the account, and you cannot take it away at the property level. The effective permission for a resource is the most permissive role a user holds for it. You can add permission as you move down the hierarchy. You cannot remove it. If that sounds like a trap, it is the single most common reason an access cleanup fails halfway through.

Two data restrictions sit alongside the roles: No Cost Metrics and No Revenue Metrics. You can apply a restriction as a direct permission, but you cannot lift one that is inherited. Put No Cost Metrics on someone at account level and no property-level setting will give it back. Restrictions are enforced in the interface and in the equivalent API calls, and in reports the restricted values render as zero rather than disappearing. A user under a restriction may not realise the number they are reading is not the real one.

Two group types and one naming standard

Google's guidance in the Marketing Platform documentation is to build only two shapes of group. People-oriented groups model who reports to whom. Role-oriented groups model which permissions a job needs. Alongside that, pick a naming standard so you can tell the two apart and avoid duplicates.

The examples in the documentation are Direct Reports: Jane Smith for the people-oriented shape and Data Analysts: EMEA for the role-oriented one. For most Analytics setups the role-oriented group is the one to build first, because roles change slowly and people change often. Use people-oriented groups only where a reporting line genuinely carries different access, not to mirror an org chart.

What you cannot put in a group

Some permissions cannot be assigned to a group at all. In Google Tag Manager, the account-level Admin permission and the container-level Approve and Publish permissions have to stay on individual users. The same help page carries an equivalent note for Google Optimize, which is legacy text, but the Tag Manager restriction is current and enforced.

The practical effect is that your group of everyone who works on the container cannot publish. Publishing stays a named person's responsibility. Treat that as a control rather than an obstacle. Every container change then has a human who can be asked about it.

What the API covers, and what it does not

The API manages group objects and group membership. It does not change the permission model and it does not replace the resource that manages individual user permissions. If your goal is to reconcile who holds Viewer on a specific property, that work belongs to the access binding surface of the Admin API, not to this one. The changelog links to the reference documentation for the group endpoints.

The realistic automation targets are the chores that go stale. A joiner script that adds a new analyst to the role group. A leaver script that removes them and then lists every group they still appear in. A quarterly job that flags groups with no members and members who belong to no group. Each of those is short code once the group structure exists.

One detail belongs in the joiner process itself. When you add a user to a group, they become a member of the organization if they were not one already. That is an identity change with its own consequences, so it should be a deliberate step with a log entry, not a side effect of a permission update.

Who can create, own and change a group

Three separate rights sit around a group, and they are easy to confuse. Creating a group is open to user admins for an organization and to user administrators for Analytics products. Changing who is inside a group is broader: user admins for an organization can add or remove users from any group in the organization, while a group owner can do the same only for the groups they own.

Ownership is the part worth assigning deliberately. When you create a group you become its owner, and you can name other owners. The API exposes the same split through the two permission levels it offers, Member and Owner. Treat Owner as an administrative role rather than a membership badge. A group with no owner and no user admin watching it will drift until someone notices that a departed contractor is still inheriting Editor across every property in the account.

A five-step access review you can run this week

1. List every user at account level and sort by role. For each Administrator, write down the name and the reason. Anything you cannot account for is a finding.
2. List every user group and match each one to a real team or role. A group with no owner, or with no members, is either noise or a risk.
3. Find duplicated access. Anyone holding a direct role and a group role inherits the union of both, and the audit needs to record the union, not the two lines separately.
4. Check restrictions. Anyone who should not see revenue or cost should carry the matching restriction, and an inherited restriction cannot be removed further down the hierarchy.
5. Check the users you did not add. Linked Firebase projects and linked Google Ads accounts create linked users automatically, and those carry roles on your property that nobody in your team assigned.

Why this matters under UK GDPR

Access control is an accountability question before it is a tidy-up question. UK GDPR requires appropriate technical measures to protect personal data, and analytics reports are full of it. Being able to show who can see what, and to remove that access when someone leaves, is the evidence a supervisory authority asks for. A group structure with named owners is that evidence in a form you can actually maintain.

Two mechanical details matter for offboarding. Removing a user from a source property also removes them from its subproperties, while removing them from a subproperty only removes them there. And any user with permission can delete any other user, with a single safeguard: if you are the last remaining Administrator, you cannot delete yourself. That safeguard is exactly why a group carrying Administrator access needs at least one named owner who is not shared with a team that might leave.

The API itself is small, and the value is not in the endpoints. It is in the structure you build with them. Define your role groups, name them consistently, put the data restrictions where they belong, and automate the joiners and leavers. Do that once and access stops being an annual panic.