Google Analytics User Management Guide

• Model type: role-based
• Description: GA4 uses a hierarchical role-based model across three levels: Organization (Google Marketing Platform), Account, and Property. Roles assigned at a higher level are inherited downward unless explicitly overridden with a lower-level role assignment (including 'None'). There are five named roles: Administrator, Editor, Marketer, Analyst, Viewer. Data restrictions (cost data, revenue data) can be layered on top of any role to limit metric visibility.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role assigned at account or property level; data restrictions (cost metrics, revenue metrics) available as add-on restrictions per user. No row-level or dimension-level filtering beyond data restrictions.

1. Sign in to Google Analytics at analytics.google.com.
2. Click 'Admin' (gear icon) in the bottom-left navigation.
3. To add at account level: in the 'Account' column, click 'Account Access Management'. To add at property level: in the 'Property' column, click 'Property Access Management'.
4. Click the blue '+' (plus) button in the top-right of the access management panel.
5. Select 'Add users'.
6. Enter the user's Google Account email address in the email field.
7. Select the desired role: Administrator, Editor, Marketer, Analyst, or Viewer.
8. Optionally, enable data restrictions (No Cost Metrics, No Revenue Metrics) if applicable.
9. Optionally, check 'Notify new users by email' to send an invitation email.
10. Click 'Add' to confirm.

Required fields: Valid Google Account email address, Role selection (at least one role must be assigned)

Watch out for:

• The invitee must have an existing Google Account (Gmail or Google Workspace). Non-Google email addresses cannot be added directly.
• Account-level role assignments automatically propagate to all properties under that account unless overridden at the property level.
• There is a limit of 400 users per account and 400 users per property. Attempting to add beyond this limit will fail.
• The person adding users must hold the Administrator role at the level where they are adding the user.
• There is no email domain whitelisting; each user must be added individually by email address.
• Users added at the property level do not automatically get account-level access.

• Can delete users: Yes
• Delete/deactivate behavior: GA4 supports full removal of a user from an account or property. There is no 'deactivate' or 'suspend' state within GA4 itself-removal is permanent at the GA4 level. The underlying Google Account is not affected. To block access without full removal, an Administrator can set the user's role to 'None' at a specific property level to override inherited permissions.

1. Sign in to Google Analytics at analytics.google.com.
2. Click 'Admin' (gear icon) in the bottom-left navigation.
3. Navigate to 'Account Access Management' (account level) or 'Property Access Management' (property level).
4. Locate the user in the list (use the search bar if needed).
5. Click on the user's row to open their access details.
6. Click 'Remove access' (or the trash/delete icon) to revoke all access at that level.
7. Confirm the removal when prompted.

Watch out for:

• Removing a user at the account level removes their access to all properties under that account. Removing at the property level only removes access to that specific property.
• If a user was granted access at the account level, removing them only at the property level will not fully revoke access-they will still have account-level access. You must remove them at the account level or set property role to 'None'.
• The removed user's Google Account is not deleted or suspended; they retain access to other Google services.
• There is no audit log of who removed a user natively within GA4 Standard; GA4 360 via Google Marketing Platform may offer additional audit capabilities.
• Personal explorations belonging to the removed user may be lost permanently with no recovery option.

• Where to check usage: Admin → Account Access Management or Property Access Management → view user list with roles. No built-in 'last login' or 'last active' timestamp is displayed in the GA4 UI for individual users.
• How to identify unused seats: GA4 does not natively display last-login dates or activity timestamps for users in the Access Management UI. Identifying unused accounts requires cross-referencing with Google Workspace admin logs or Google Cloud audit logs if the organization uses those tools. There is no built-in inactive-user report in GA4.
• Billing notes: GA4 Standard is entirely free with no per-seat or per-user billing. GA4 360 billing is based on monthly event volume, not number of users. Adding or removing users has no direct impact on GA4 360 billing. Rollup and sub-properties in GA4 360 are billed at 150% of their contributing event count toward the quota.

GA4 has no built-in last-login or last-active timestamp for users in the Access Management UI. Identifying stale accounts requires cross-referencing Google Workspace admin logs or Google Cloud audit logs - neither of which is surfaced inside GA4 itself.

Without external tooling, every app in your stack that relies on GA4 access faces the same blind spot: you cannot confirm who is actively using their access from the GA4 console alone.

Bulk provisioning is not supported natively. Each user must be added individually by Google Account email address, with no CSV import and no domain whitelisting. For large teams or frequent onboarding cycles, this creates compounding manual overhead.

Account-level Administrator assignments automatically propagate to all properties under that account. Over-provisioning is a consistent operational risk because correcting it requires manually setting the 'None' role at each affected property - there is no bulk override.

Practitioners consistently flag the absence of last-login visibility as the most high-impact gap in GA4's access management. Without activity timestamps, access reviews require external log correlation rather than a native audit report.

The 400-user hard limit per account and per property is a documented ceiling that blocks access additions for large organizations until existing users are removed. There is no grace period or overflow mechanism.

The lack of custom roles is a recurring friction point. Teams are constrained to five preset roles plus two data restrictions (No Cost Metrics, No Revenue Metrics), with no row-level or dimension-level filtering beyond those options.

Common complaints:

• No native 'last login' or 'last active' date shown for users in the Access Management UI, making it difficult to audit inactive users without external tooling.
• No CSV import for bulk user provisioning; each user must be added individually by email address, which is time-consuming for large teams.
• No domain whitelisting or automatic provisioning of users based on email domain.
• The 400-user limit per account/property is a hard ceiling that can block access for large organizations.
• Account-level role inheritance is a common source of unintended over-provisioning; administrators must manually override at the property level using the 'None' role.
• No custom roles or fine-grained permission scoping beyond the five preset roles and two data restrictions.
• Removing a user at the property level does not revoke account-level access, which confuses administrators expecting a single removal to fully cut off access.
• SCIM provisioning is not available natively within GA4; it operates only at the Google Cloud Organization level, requiring separate configuration outside of GA4.

Use account-level role assignments only when a user genuinely needs access to every property under that account. The inheritance model means that every app and property downstream of an account-level Administrator grant is exposed - making it the highest-risk assignment and a common source of unintended over-provisioning.

For property-scoped access, assign roles at the property level directly. Use the 'None' role at the property level to explicitly block inherited account-level access for specific users without removing them from the account entirely.

Data restrictions (No Cost Metrics, No Revenue Metrics) can be layered on top of any role and are the only mechanism for limiting metric visibility below the role level. There is no finer-grained scoping available in GA4 Standard or GA4 360.

Bottom line

Google Analytics 4's access model is straightforward for small teams but operationally demanding at scale. The absence of last-login data, bulk provisioning tools, and custom roles means that access hygiene depends entirely on manual processes or external log infrastructure.

The hierarchical inheritance model is powerful but requires deliberate role assignment at every level - account-level grants carry significant blast radius, and the only native correction mechanism is the 'None' role applied property by property.