What Is GA4 Permission Setup? Differences in Access Levels and Safe Granting Steps
Published:
Last Updated:
Category: Web Analytics
Published:
Last Updated:
Category: Web Analytics

Authors: Shusaku Yosa
When you run GA4 with several people or share data with an agency or external partner, permission settings (managing access rights and data restrictions) are indispensable. Granting permissions too broadly raises the risk of mistaken operations and information leaks, while restricting them too tightly leaves people unable to do the analysis they need. This article organizes the types and differences of GA4 permissions (permission levels), the procedure for granting them, and the points for sharing externally in a safe way.
The first thing to grasp in understanding GA4 permissions is the two levels of "account" and "property." The account is the top-level container, and within it are multiple properties (units of a site or app being measured). Permissions can be granted at each of these levels—per account and per property.
What matters is that a permission granted at the upper level (account) is inherited by the lower level (property). For example, if one account has three properties—the official site, an e-commerce site, and an app—and you want to ask an external company to set up only the e-commerce site, you grant the permission to the e-commerce site's property rather than to the whole account. The first step in keeping the sharing scope to the necessary minimum is using these levels appropriately.
GA4 permissions are divided into five roles: Administrator, Editor, Marketer, Analyst, and Viewer (six types if you include "None," which grants no permission). These form a nested structure in which an upper role includes all the operations of the lower roles, and permissions narrow from the top down.
This is the top-level permission that can access all settings and data, and can even add and remove other users and assign roles (user management). It's the permission that should be held by the person managing all of GA4—that is, the internal business owner or account owner. It must be handled most carefully, and as a rule you don't hand it to external parties.
This is the Administrator permission minus user-management rights. Including property and data-stream settings, you can edit data and settings across the board, but you can't change other users' permissions. It suits an internal web person entrusted with maintaining tags, events, and the measurement environment, or a trusted external person you ask to do setup work.
This is the Editor permission minus property and data-stream settings. You can create, edit, and delete audiences, key events, events, attribution models, lookback windows, and the like. Because it can handle the settings needed for ad integration and customer analysis, it's a permission often granted to an internal marketing person or an agency you ask to run ads.
This is the Marketer permission with the setting rights for events, key events, audiences, and so on removed. In addition to viewing standard reports, you can create, edit, and share reports in the exploration tool, but you can't change settings related to measurement or data collection. It's ideal, whether internal or external, for someone responsible for analysis, report creation, and improvement proposals.
This is a view-focused permission that can display settings and data and change the data shown in reports. You can't change settings or create new reports. It suits cases like sharing a dashboard with executives or management, or an external writer or a trainee employee—counterparts for whom just viewing is enough.
Note that for any role you can separately set a "data restriction," and choosing "No cost metrics" or "No revenue metrics" lets you operate without showing that counterpart highly confidential data such as cost and revenue. You can use it flexibly—showing ad spend to an ad agency, showing only behavioral data to a production company, and so on.
Permission design is easier to judge by working backward from "what you want them to do (the purpose)" than by choosing from role names. The rough guide is as follows.
Just viewing reports (executives, sales, trainee employees, and so on) → Viewer
Creating exploration reports to analyze and propose improvements (external analysts, and so on) → Analyst
Handling ad integration, audiences, and key events (marketing staff, ad agencies) → Marketer
Setting up tags, events, and data streams (measurement staff) → Editor
Entrusting even user management (internal management lead) → Administrator
For external sharing, it's safe to make Viewer and Analyst the baseline, and consider an upper role only when setting changes are needed. There's usually no need to hand over Administrator right away for ordinary SEO improvement or ad operation.
The flow for actually granting a permission is the following procedure. Note that the counterpart needs a Google account (the email address tied to it).
Open the GA4 admin screen (gear icon) and select "Access management" for the level (account or property) you want to grant permission at
Click "Add users" from the "+" at the top right
Enter the email address of the counterpart's Google account
Choose the role (Administrator through Viewer) and, as needed, set a data restriction (No cost metrics, No revenue metrics)
Confirm the details, click "Add," and complete the grant
Because a mistyped email address means the permission won't be granted correctly, checking the counterpart's account in advance makes it go smoothly. After granting, always confirm that it's reflected at the intended role and level.
Permissions aren't finished once granted; operation to keep them safe is important. Especially when there's external sharing or member turnover, keep the following points in mind.
The principle of least privilege: grant only the minimum role needed for the work. Don't hand edit rights to someone for whom viewing is enough
Inventory of individual accounts: when granting to an individual Google account rather than a company shared address, record who, at what level, and until when it was granted
Prompt removal on contract end or departure: leaving the permissions of an agency whose support contract has ended, or of a departed employee, becomes an information-leak risk. Review immediately when there's a change of personnel
Periodic inventory: check periodically, such as once a month, who has which permissions and whether there are any removal omissions
Check other tools too: inventory not just GA4 but also the permissions of linked tools such as Search Console and GTM at the same time
In reality, an accident can happen where Administrator rights were left with a production company from before a renewal, the person in charge then left the company, and access remained possible for a long time. Deciding at the time of granting "who, at what scope, until when, and what the return procedure is" helps prevent such risks.
GA4 permissions are managed at the two levels of account and property, and from the five roles—Administrator, Editor, Marketer, Analyst, and Viewer—you choose and grant the scope needed for the counterpart's work. The roles are a nested structure in which an upper role includes the lower ones, and by combining data restrictions, you can finely adjust whether cost and revenue data are shown.
The granting procedure itself is simple, but what determines the outcome is operation. Keep least privilege, make Viewer and Analyst the baseline for external sharing, and remove promptly at the timing of a contract's end or a departure—turning this cycle together with a periodic inventory lets you make use of GA4 while sharing data safely.

A screen-by-screen guide to reading GA4 standard reports: the snapshot, realtime, the life-cycle reports (acquisition, e...

A technical breakdown of when a GA4 session starts and ends, how events are aggregated into one session via session_star...

What the GA4 API (Data API) is, what you can do with it, and how it differs from BigQuery export. Covers examples of app...