Grant User Access in Google Analytics 4

The dangerous click in Analytics is not Add; it is choosing the account level when someone only needs one property. That small scope mistake quietly exposes every current property—and every property created later. I treat each invitation as an access-control change: identify the job, choose the narrowest resource, then verify what the person can actually do.

Account access versus property access

• Account-level role: inherited by every property in the account, including broader administration appropriate to that role.

• Property-level role: limited to the selected GA4 property, unless another account/group/organization assignment adds more access.

• A property cannot subtract a role inherited from the account; permissions are additive toward the most permissive effective role.

• Data restrictions can also be inherited and cannot simply be removed at the child property.

• For an agency, analyst, contractor, or product team working on one site/app, property scope is usually the safer starting point.

Decide the job before the role

• Read standard reports/dashboards → Viewer.

• Build personal explorations or change report display for their own analysis → Viewer may be enough; validate exact workflow.

• Share explorations with property users → Analyst.

• Create/manage audiences, events, key events and attribution-related marketing settings → Marketer.

• Change property settings, data streams, product links, custom definitions, retention and reporting configuration → Editor.

• Manage users and all configuration → Administrator, reserved for a very small accountable set.

What the five GA4 roles mean

Viewer

• Can see settings and data available to the user.

• Can change how data appears during report use, such as comparisons or secondary dimensions.

• Can see shared assets through the UI/APIs.

• Can create, edit, and delete their own explorations.

• Cannot administer property configuration or other users.

Analyst

• Includes Viewer capabilities.

• Can share created explorations with other property users.

• Fits analysts collaborating through explorations without property-wide configuration authority.

• Does not imply permission to change data collection, streams, users, or product links.

Marketer

• Includes Analyst capabilities.

• Can create, edit, and delete audiences, events, and key events.

• Can import key events as conversions into Google Ads through supported interfaces.

• Can edit attribution-model settings.

• Carries material activation/measurement risk and should not be a default reporting role.

Editor

• Includes Analyst capabilities.

• Has broad control of property settings and configuration.

• Can affect streams, integrations, reporting definitions, retention, filters, and downstream measurement depending on feature.

• Cannot manage user access, though Editors can view users across a property.

• Use for accountable implementation owners, not every analyst or agency contact.

Administrator

• Includes Editor capabilities.

• Can manage users and roles at the resource level where the Administrator role applies.

• Can create severe confidentiality, availability, and configuration impact.

• Keep at least two durable organization-controlled administrators, but keep the group small.

• Do not grant solely because someone could not find a report.

Before adding a person

• Confirm the exact Analytics account/property name, property ID, web/app streams, and business owner.

• Use the person’s organization-managed Google/Workspace account, not a shared login.

• Ask for their task and end date; map it to a role and scope.

• Check whether a user group already represents their team.

• Review whether cost or revenue metrics need restriction.

• Create an access ticket/approval record and owner for periodic review.

• Ensure the requester and approver are authorized to expose this analytics data.

Add a user to one GA4 property

1. Sign in to Google Analytics with a Google Account that has Administrator at the target property.

1. Use the account/property selector to choose the intended GA4 property; verify its numeric property ID.

1. Open Admin.

1. Under Property, select Access Management.

1. Select +, then Add users.

1. Enter the email registered to the person’s Google Account or Google Workspace account.

1. Leave Notify new users by email enabled unless onboarding is coordinated another way.

1. Select the minimum role required.

1. Apply No Cost Metrics and/or No Revenue Metrics when appropriate.

1. Select Add.

1. Search for the user, open their details, and inspect direct/effective roles and restrictions.

1. Have the recipient sign in and validate only the approved property and tasks.

Add at account level only when intended

1. In Admin, verify the correct Analytics account—not only the property.

1. Under Account, open Access Management.

1. Select + → Add users and enter the organization-managed Google Account email.

1. Choose a role justified across every property in this account.

1. Add inherited cost/revenue restrictions if they should apply everywhere.

1. Review all existing properties and the impact on future properties before confirming.

1. After adding, inspect the user’s effective access at representative properties.

Cost and revenue data restrictions

• No Cost Metrics hides cost-related metrics across reports, explorations, audiences, insights, and alerts.

• No Revenue Metrics similarly hides revenue-related metrics.

• Restrictions include custom metrics classified as cost/revenue and metrics derived from restricted metrics.

• A restriction is narrower than removing report access; the user can still work with allowed dimensions/metrics.

• Inherited restrictions cannot be removed at a child property.

• Restrictions are not row-level security and do not isolate data by brand, geography, business unit, or hostname.

Direct roles versus effective roles

The role shown on one assignment is not necessarily the user’s real power. Effective access is the sum of direct roles plus inherited account, group, organization, and other applicable assignments. GA4 uses the most permissive role available for that resource.

• Account Editor + property Viewer → effective property access remains Editor.

• Account Viewer + property Analyst → effective role for that property is Analyst.

• Property role removed + group role remains → the user can still have access through the group.

• Direct No Revenue restriction removed + inherited restriction remains → revenue stays restricted.

• To reduce access, remove/change the upstream assignment that grants it; a weaker child role does not override it.

Use groups for stable teams

• Groups reduce individual role drift and simplify onboarding/offboarding.

• GA user groups require the Analytics account to belong to a Google Marketing Platform organization.

• Grant the group at the narrowest account/property level, then manage group membership through the organization.

• Nested groups and organization roles can add effective permissions; document ownership and review paths.

• Do not make a broad “all employees” group Administrator.

• Test removal from every nested/source group during offboarding.

External agencies and contractors

• Prefer named individual accounts over agency-shared credentials.

• Grant one property, not the entire Analytics account, unless the contract/owner explicitly requires all properties.

• Start with Viewer/Analyst and elevate only for a scoped implementation task.

• Use an expiry/review date and offboarding owner.

• Restrict cost/revenue data based on actual need and contractual confidentiality.

• Review Google Ads, Search Console, GTM, Looker Studio, BigQuery, Cloud and CMS permissions separately—GA access does not automatically govern them.

Verify the invitation

1. Search the target Access Management list for the full email.

1. Open the user and distinguish direct from inherited/effective roles.

1. Confirm resource scope and data restrictions.

1. Ask the recipient to use the intended Google account in a private browser profile.

1. Confirm the approved property appears and unrelated properties do not.

1. Test the intended task: report viewing, exploration sharing, marketing asset change, or administration.

1. Confirm disallowed actions/settings/data are unavailable.

1. Record evidence and next review/offboarding date.

The user did not receive an email

• Search Access Management first; notification delivery is not the source of truth for whether access exists.

• Confirm the exact email is registered as a Google Account and contains no typo/alias mismatch.

• Ask the user to sign directly into analytics.google.com with that account.

• Check spam/quarantine and Workspace email policies.

• Remove/re-add only after understanding existing roles; duplicate/inherited access can confuse diagnosis.

• Never ask for the user’s password or one-time code.

The person sees the wrong property—or too many

• Confirm they selected the intended Analytics account/property.

• Inspect account-level inheritance and group membership.

• Search their email at both account and property Access Management.

• Check whether multiple Google accounts are signed into the same browser.

• Remove broad upstream access rather than assigning None/Viewer at the child.

• Review organization-admin/product permissions where Analytics is linked to a Marketing Platform organization.

You cannot add or edit users

• You need Administrator at the account/property level where you are making the change.

• An Editor can view property users but cannot manage them.

• You may be in the wrong account/property or signed into another Google account.

• Organization policies or policy violations can affect user management.

• Request the smallest required administrative action from an existing accountable Administrator; do not share their login.

• Preserve at least two durable Administrators so staff departure does not orphan access.

Remove or reduce access safely

1. Identify the reason, approver, user, scope, and required effective end time.

1. Search at account and property levels; inspect group/organization inheritance.

1. For a role change, edit the direct assignment and Save.

1. For complete removal, remove every relevant direct/group source rather than one visible row.

1. Google’s current help states account-level Administrator is required to delete users and users are deleted at account level; follow the UI/current scope carefully.

1. Have the person retest after sessions/cache settle and verify every relevant property.

1. Record the removal and review linked systems separately.

Do not delete the last Administrator

GA4 prevents the last Administrator from deleting themselves as a safety measure, but governance should not depend on that guardrail. Keep two named organization-controlled administrators with recovery and 2-Step Verification, and test ownership continuity before offboarding either one.

Access reviews that stay useful

• Quarterly or risk-based review of users, groups, roles, restrictions, owners, and last-known business need.

• Immediate review on staff/agency offboarding, merger, property transfer, incident, or contract end.

• Flag personal emails, shared accounts, dormant contractors, broad account roles, and unexplained Administrators.

• Review Change History and permission changes where available.

• Match GA roles to GTM, Ads, Search Console, BigQuery, Looker Studio and Cloud access.

• Verify break-glass/recovery accounts are controlled, monitored, and not used for daily work.

• Document exceptions with owner and expiry.

GA4 roles are not data segmentation

• Roles control capabilities at account/property level; they do not provide general row-level security.

• Report comparisons/filters change presentation, not durable confidentiality boundaries.

• Data filters modify incoming property data and are not per-user access controls.

• Analytics 360 subproperties can support governance for subsets under their documented constraints.

• For confidentiality boundaries, design separate properties/subproperties/export datasets and governance deliberately rather than hiding a report menu.

A practical role-selection checklist

• Does the person need one property or every property?

• Must they only read, share explorations, manage marketing assets, edit configuration, or manage users?

• Do they need cost and revenue metrics?

• Can a managed group grant the same access consistently?

• What stronger role could be inherited from account/group/organization?

• Who approved access and when does it expire?

• How will you test effective access and offboard linked systems?

Related measurement operations

• If the property is not collecting yet, follow the GA4 website installation and verification workflow.

• When retiring a site/property, distinguish stopping collection, deleting a stream, trashing a property, and removing user access in Remove a Website from Google Analytics.

• Treat Analytics and Tag Manager permissions as separate controls; a GA4 role does not automatically authorize publishing website tags.

Primary references

• Google’s current add, edit, and delete Analytics users/groups guide documents scope, required Administrator role, Google Account emails, notifications, editing, removal, groups, and last-admin safety.

• The official GA4 access and data-restriction reference defines every role, cost/revenue restrictions, inheritance, and effective permissions.

• Google’s concise roles reference distinguishes direct and effective roles.

• For governance beyond roles, Google compares roles, report filters, data filters, and Analytics 360 subproperties.