A Google Analytics 4 property holds behavioural data about every visitor, links into advertising accounts and spend, and is usually administered by a marketing agency nobody has reviewed in years. GA4 has a small, clear permission model, two data restrictions, a two year change history, a data access report and a set of collection controls for personal data, but few organisations use them deliberately. This guide covers how access works in GA4, how to contain the Administrator role, how to govern service accounts, Measurement Protocol secrets and product links, what to monitor, and a hardening baseline with the misconfigurations that keep recurring. It is for security, privacy and analytics engineers who own or audit GA4 properties. The legal side of consent and tracking is covered in the Cookie and Tracking Technology Compliance Guide; this page stays on the platform controls. Facts were checked against Google's documentation on 8 November 2026.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
Key takeaways
- Administrator is the only role that matters for takeover. It can add, remove and change anyone's role, including its own, so treat it like a privileged role with a named owner list of two or three people.
- Effective access is the most permissive role across all sources. An account level grant flows to every property, and a property level grant can raise but never lower it, so reviews must look at effective permissions, not only direct ones.
- Linked products create virtual users. Google Ads and Firebase links appear as virtual users holding GA4 roles, and they are easy to miss in an access review.
- Two audit sources, two different roles. Change history (Editor and above, 2 years) shows who changed configuration; Data Access reports (Administrator only, up to 2 years) show who read data, including from which IP address.
- Personal data control starts at collection. Google's policy forbids sending personally identifiable information; data redaction, retention settings and deletion requests reduce the damage when it happens, but none of them is a substitute for clean tagging.
How identity and access work in Google Analytics 4
GA4 has no local user store. Every person signs in with a Google Account, either a managed account in Google Workspace or Cloud Identity, or a consumer account. That has a direct consequence for single sign-on and multi-factor authentication: GA4 has no setting of its own that forces either. SSO through your identity provider and 2-Step Verification are enforced by the policy of the Google identity that owns the account, so a managed account inherits your organisation's controls and a consumer Gmail account inherits whatever its owner chose. The single most useful identity control for GA4 is therefore to grant roles only to managed accounts in your own domain or in a contractually bound agency's managed domain. See the Identity Provider and SSO Security Guide and the Phishing-Resistant MFA Guide for the controls that then apply.
Access is granted on two resources, the account and the property, and roles are inherited downwards. Google describes the resulting permission as the most permissive role across all sources: an account level Viewer who is a property level Editor is an Editor on that property. Data restrictions behave the other way. A restriction set on the account cannot be removed for a property, though an additional restriction can be added lower down. GA4's user management screen shows both direct permissions (granted on this resource) and effective permissions (combined with grants from the organisation, user group or account).
| Role | What it can do | Security view |
|---|---|---|
| Administrator | Full control, including managing users and assigning any role or data restriction to anyone, including itself; includes Editor | Privileged. Keep to a short named list; never give to agencies by default |
| Editor | Controls property settings (data streams, links, retention, redaction, deletion requests); can view users but not manage them; includes Analyst | Can change what is collected and where data flows. Treat as change authority |
| Marketer | Creates, edits and deletes audiences, events and key events; imports key events into Google Ads; edits attribution settings; includes Analyst | Can alter conversion data that drives ad spend |
| Analyst | Shares explorations with other users; includes Viewer | Read access plus sharing |
| Viewer | Views settings and data, works with report content, creates and deletes own explorations | Read access to all non restricted data |
| None | No role on this resource (may still hold one elsewhere) | Use to confirm removal, then check effective access |
The two data restrictions, No Cost Metrics and No Revenue Metrics, hide those figures across reports (shown as 0), explorations (not shown), audiences, insights and alerts. They are the right tool when an agency or a junior analyst needs behavioural data but has no business seeing revenue.
Admin roles and privileged access
An attacker or a departing agency that holds Administrator can add their own accounts, remove yours, change retention, redirect data through new links and export everything. Contain the role with these rules:
- Named owners: two or three Administrators at account level, all managed accounts in your domain, recorded as asset owners in your SaaS inventory. One owner is a single point of failure; ten is no control at all.
- Grant at the lowest level: agencies and contractors get property level roles, not account level, because account grants flow to every property including future ones.
- Prefer Editor or Marketer for agencies: most agency work (tagging, audiences, key events, Ads import) needs Marketer or Editor, not Administrator. If an agency insists on Administrator, time box it and review monthly.
- Use restrictions with roles: pair Viewer or Analyst with No Revenue Metrics or No Cost Metrics where commercial data is not needed.
- Remove at both levels: removing a direct property grant does nothing if the person also holds an account level or group grant. Confirm the effective permission shows None.
- Joiner, mover, leaver: because roles attach to Google Accounts, suspending a managed account in Workspace blocks GA4 access immediately; a consumer account in your property is untouched by your offboarding process. This is the strongest argument for managed accounts only.
| Persona | Recommended grant | Level | Restrictions |
|---|---|---|---|
| Analytics platform owner | Administrator | Account | None |
| Internal analytics engineer | Editor | Property | As needed |
| Paid media agency | Marketer | Property | No Revenue Metrics if not required |
| Reporting consumer | Viewer | Property | No Cost Metrics, No Revenue Metrics where possible |
| Admin API automation (service account) | Lowest role the job needs | Property | As needed |
Integrations, API tokens and service accounts
Most of GA4's non-human access comes from four directions. Each needs an owner and an entry in your inventory. See the NHI lifecycle automation guide for the general process.
Admin API and Data API automation
Reporting pipelines, dashboards and access management scripts call the Analytics Data API and Admin API with OAuth scopes such as analytics.readonly, and the Admin API's access binding methods require https://www.googleapis.com/auth/analytics.manage.users. An access binding grants roles to a user email using values such as predefinedRoles/viewer, predefinedRoles/editor, predefinedRoles/admin, predefinedRoles/no-cost-data and predefinedRoles/no-revenue-data. Automation usually runs as a Google Cloud service account added to the property by its email address. Two rules follow:
- Scope and role: a reporting job needs a read scope and Viewer; only an access management tool needs
analytics.manage.usersand Administrator. A service account with Administrator and a downloaded JSON key is a credential that can take over the property. - Keys: avoid service account keys where the job runs on Google Cloud or can use workload identity federation. Where a key exists, store it in a secrets manager and rotate it. See the Google Cloud Service Account Keys Security Guide.
Measurement Protocol API secrets
The Measurement Protocol lets servers send events into a data stream using an API secret created in the stream's settings. The secret only writes events, but anyone holding it can inject fake events, distort conversion data that feeds Google Ads, or push personal data into your property. Keep secrets server side, never in client code or public repositories, create one per sending system, and delete unused secrets. Google's documentation notes the protocol is meant to complement tagging and recommends the Data Manager API for new server-to-server integrations.
Product links
Links to Google Ads, BigQuery, Search Console, Firebase and other Google products move data out of GA4 or bring audiences back in. Linked Google Ads and Firebase users appear as virtual users with GA4 roles, and Administrators can change those roles, which affects everyone in that linked group. A BigQuery export copies raw event data into a Cloud project with its own IAM, retention and sharing, outside GA4's retention setting. Review every link at least quarterly and record the destination owner.
Tags and tag managers
Whoever can publish your Google Tag Manager container or edit the site's gtag code controls what GA4 receives. Govern the tag layer as part of GA4 security: see the Google Tag Manager Security guide and the Third-Party JavaScript Management Guide.
Personal data, retention and deletion controls
Google prohibits sending data to Analytics that Google could use or recognise as personally identifiable information, such as email addresses, personal phone numbers and national identifiers. The policy calls out the places PII usually leaks: URL paths and query strings, page titles, search terms, form input, User-ID values, custom dimensions, UTM campaign parameters, event parameters and imported data. It also forbids precise location finer than about one square mile and notes that postcodes can identify people in places such as the UK.
| Control | What it does | Limits |
|---|---|---|
| Data redaction | Removes likely email addresses from event parameters and listed query parameters from page_location, page_referrer, page_path, link_url, video_url and form_destination before data is sent | Web streams only; best effort; not applied to Measurement Protocol or Data Import; HTTP header values not evaluated. On by default for new properties, Editor and above can configure |
| Data retention | User and event level data kept 2 or 14 months (26, 38 or 50 months on Analytics 360); reducing the period deletes data in the next monthly run | Standard aggregated reports are not affected, only explorations and funnels. Age, gender and interest data always 2 months; Google signals capped at 26 months |
| Reset on new activity | When on, each new event extends the user identifier's expiry, so active users persist indefinitely | Turn off if your retention schedule is a hard maximum |
| Data deletion requests | Removes parameters or user properties from collected data across five request types | Editor and above; 7 day grace period, then 7 to 63 days to complete; only data older than 12 days; at most 12 active requests; irreversible |
| Consent mode | Passes consent state for analytics_storage and ad_storage; when denied, no analytics cookies are read or written and cookieless pings are sent | Basic mode blocks tags until consent; advanced mode loads tags and enables behavioural modelling. Legal choice belongs with your privacy team |
A retention change waits 24 hours before it takes effect and can be reverted in that window without losing data, which gives a short safety net against a malicious or mistaken change. Set retention to match your records of processing under GDPR Article 5(1)(e) (storage limitation), and document the choice. For handling a leak of personal data into GA4, the order is: fix the tag, enable or extend redaction, raise a deletion request for the affected parameters and date range, then check BigQuery exports and other linked destinations, which a GA4 deletion request does not clean. See the Consent Management Guide: Cookies, CMPs and GPC for the consent side.
Logging and detection
GA4 has two audit sources and neither is streamed to a SIEM by default, so plan how you will pull them.
| Source | What it records | Who can see it | Retention |
|---|---|---|---|
| Change history (Admin, account or property) | Time, account or property, item type (for example data stream or Google Ads link), action (created, modified, deleted), the user, and before and after state in Admin API format | Editor and above | 2 years |
Data Access reports (Admin API runAccessReport) | Each read of GA4 data, with dimensions such as userEmail, userIP, reportType, revenueDataReturned, costDataReturned and epochTimeMicros | Administrator only | Up to 2 years |
Useful detections, run weekly through a scheduled job or reviewed by the platform owner:
- New Administrator or user grant: change history entries for user or access changes, especially to consumer domains or unknown agency domains.
- Data flow changes: new or modified Google Ads, BigQuery or other product links, new data streams and new Measurement Protocol secrets.
- Privacy setting changes: data retention reduced or extended, reset on new activity toggled, redaction disabled, deletion requests created.
- Unusual reading: a Data Access report spike in
accessCountfor one user, access from new IP ranges, orrevenueDataReturnedtrue for a user who should be restricted. - Deleted accounts: change history entries showing [deleted user] mean the Google Account behind a change no longer exists; check what that account still owned.
Account takeover of an Administrator maps to ATT&CK T1078.004 Cloud Accounts, and an attacker adding their own users maps to T1098 Account Manipulation. For identity side signals, use Workspace login audit events: see the Google Workspace Audit Log Detection Guide.
Metrics that show the programme is working:
- Number of Administrators per account (target 2 or 3).
- Percentage of GA4 grants held by managed accounts (target 100 percent).
- Days since last access review per property (target under 90).
- Count of Measurement Protocol secrets and service accounts with no recorded owner (target 0).
- PII findings per quarter from tag reviews and redaction tests, trending down.
Hardening baseline
- Inventory: list every GA4 account and property, its business owner, Administrators, agencies, service accounts, links and BigQuery destinations.
- Identity: require managed Google Accounts with enforced 2-Step Verification or SSO for every grant; migrate consumer accounts and remove any you cannot attribute.
- Roles: reduce Administrators to a named few; move agencies to property level Marketer or Editor; add No Cost Metrics and No Revenue Metrics where commercial data is not required.
- Non-human access: review service accounts and their keys, scopes and roles; delete unused Measurement Protocol secrets; record an owner for each that remains.
- Collection: enable data redaction on every web stream, list query parameters that carry personal data, and test with the built in preview and DebugView.
- Retention and consent: set retention to your documented schedule, decide on reset on new activity, and confirm consent mode signals reach GA4 as your privacy team intends.
- Monitoring: schedule a change history and Data Access report review, and export results to your SIEM where possible.
- Test and roll back: make role reductions in one property first and confirm reports, audiences and Ads imports still work before rolling out. Role changes are reversible immediately; retention reductions are reversible only within 24 hours, so stage those last and announce them.
Common misconfigurations
- Agency holds account level Administrator: the agency can see and change every property, including new ones, and the relationship ends without anyone removing it.
- Personal Gmail accounts with access: former employees keep access because offboarding disables their work identity, not the consumer account they used for GA4.
- Removing direct grants only: the user still has effective access through the account level or a group, so the review shows a removal that did not happen.
- Email addresses in URLs: password reset, newsletter and checkout pages put addresses into query strings, which land in page_location. Redaction helps on the web stream but not for Measurement Protocol events or BigQuery exports created before it was switched on.
- Measurement Protocol secret in front end code: anyone can then inject events and corrupt conversion data used for bidding.
- Assuming retention covers everything: standard reports, BigQuery exports and linked products keep data under their own rules, so a 2 month setting is not a 2 month data lifetime.
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | CIS Controls v8.1 |
|---|---|---|---|
| Role design and least privilege | PR.AA-05 | AC-6 | 6.8 Define and maintain role-based access control |
| Account lifecycle, managed identities | PR.AA-01 | AC-2, IA-2 | 5.3 Disable dormant accounts; 6.2 Establish an access revoking process |
| Change history and data access review | PR.PS-04, DE.CM-09 | AU-2, AU-6 | 8.2 Collect audit logs |
| PII minimisation and retention | PR.DS-01 | PT-2, SI-12 | 3.1 Establish and maintain a data management process |
| Agency and product link oversight | GV.SC-07 | SA-9 | 15.1 Establish and maintain an inventory of service providers |
For ISO/IEC 27001:2022, the relevant Annex A controls are 5.15 Access control, 5.18 Access rights, 8.15 Logging and 5.34 Privacy and protection of PII.
Practitioner checklist
- Every GA4 account has two or three named Administrators using managed Google Accounts.
- No consumer accounts hold roles; agencies use their managed domain accounts at property level.
- Effective permissions, not only direct ones, are reviewed at least every 90 days, including Google Ads and Firebase virtual users.
- Service accounts have the lowest role and scope needed, an owner, and no unmanaged JSON keys.
- Measurement Protocol secrets are server side only, one per sending system, with unused secrets deleted.
- Data redaction is on for every web stream with personal data query parameters listed and tested.
- Retention and reset on new activity match the documented retention schedule, and BigQuery exports have their own retention.
- Change history and Data Access reports are reviewed on a schedule, with alerts for new Administrators and new links.
- A PII leak runbook exists covering tag fix, redaction, deletion request and downstream exports.
Standards and references
- Google: Access and data restrictions management (GA4)
- Google: View the history of account and property changes (GA4)
- Google for Developers: Data Access reports with the Admin API
- Google: Best practices to avoid sending personally identifiable information
- Google: Data redaction (GA4)
- Google: Data retention (GA4)
- Google: Data deletion requests (GA4)
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Cookie and Tracking Technology Compliance Guide · Google Tag Manager Security · Google Ads Account Security · Google Workspace Security Guide · Google Cloud Service Account Keys Security Guide