Google Analytics User Management

Google Analytics (GA4) permissions are layered across accounts, properties, and data streams. Use this guide to standardize how the collaborator is onboarded, updated, and removed.

How GA4 Structures Access

Google Analytics 4 uses a hierarchical permission model with multiple layers. Understanding this structure is critical for secure collaborator access management.

Account, Property, and Data Stream Hierarchy

Google Analytics Account:

• Top-level container for your organization's analytics setup
• Contains one or more properties
• Account-level permissions grant access to all properties underneath
• Billing and admin settings managed at account level

Properties:

• Individual websites or apps (e.g., "Company Website", "Mobile App")
• Each property has its own data streams, reporting, and configurations
• Property-level permissions grant access only to that specific property
• Most collaborator access should be scoped at property level

Data Streams:

• Sources of data within a property (web, iOS app, Android app)
• Not independently permissioned; access controlled at property level
• Can be hidden from specific users via data filters or restrictions

Permission Levels

GA4 offers four standard permission roles plus customizable roles.

Administrator:

• Full control over account or property
• Add/remove users and modify permissions
• Edit property settings and data collection configuration
• Delete property or account
• Link to Google Ads, Search Console, BigQuery
• Create audiences and conversions

Editor:

• Modify property settings and configurations
• Create and edit reports, explorations, and audiences
• Configure data streams and events
• Cannot add/remove users or modify permissions
• Cannot delete the property

Analyst:

• View and analyze data
• Create personal reports and explorations
• Cannot modify property settings
• Cannot create shared assets (audiences, conversions)
• Cannot access admin features

Viewer:

• Read-only access to reports and data
• Cannot create or modify anything
• Cannot access configuration settings
• Ideal for stakeholders who only need visibility

None:

• Explicitly removes access (useful for inheritance blocking)

Account vs. Property Access

Account-level permissions:

• Grant access to all current and future properties in the account
• Include account-wide settings (user management, billing, property creation)
• Use sparingly for collaborators (risk of over-provisioning)

Property-level permissions:

• Scoped to a single property
• Don't inherit from account level
• Recommended approach for collaborators

Best practice: Grant collaborators property-level access only. Reserve account-level access for internal administrators and senior collaborator leads managing multiple properties.

Data Restrictions

GA4 allows restricting access to specific types of data within a property.

Metric restrictions:

• Hide cost and revenue data from specific users
• Applies to metrics like "purchase revenue", "total revenue", "ROAS"
• Useful when collaborators should analyze traffic but not financial data

Direct user identifier restrictions:

• GA4 doesn't collect PII by default, but can restrict if custom dimensions contain sensitive data
• Limit access to user-scoped custom dimensions
• Configure via property-level user permissions

Permissions Matrix

Account Types and Capabilities

Account Administrators

Granted at the account level, Administrators control all properties and account settings.

Capabilities:

• Create, delete, and configure properties
• Access billing and payment information
• Manage all users across all properties
• Configure organization-wide settings
• Link products (Google Ads, Search Console, BigQuery) at account level

When to grant to collaborators:

• Collaborator is implementing GA4 from scratch and needs to create properties
• Statement of work includes managing multiple properties
• Collaborator handles billing coordination (rare)
• Document heavily in DPA and limit to senior collaborator contacts only

When to avoid:

• Work is scoped to specific properties
• Collaborator doesn't need to create new properties
• Billing visibility is restricted
• Default to property-level access

Property Administrators

Most powerful role at the property level.

Use property Administrator for:

• Collaborators configuring data collection and events
• Implementation consultants setting up GA4 tracking
• Senior analysts managing audiences and conversion configuration
• Partners who need to link Google Ads or BigQuery

Capabilities at property level:

• Full configuration access (events, conversions, audiences, data streams)
• User management for that property
• Link to Google Ads, BigQuery, Search Console
• Cannot delete the property without account-level access
• Cannot access billing

Security considerations:

• Can modify data collection, affecting data quality
• Can add other users to the property
• Can export all data via UI or BigQuery
• Limit to collaborators who need configuration access

Property Editors

Editors can configure but not manage users.

Use property Editor for:

• Analysts who need to create audiences and conversions
• Collaborators configuring enhanced measurement or custom events
• Team members who need to modify filters and data settings
• When you want to separate configuration access from user management

Key difference from Administrator:

• Cannot add/remove property users
• Cannot modify some advanced settings (data retention, Google Signals)
• Cannot delete the property
• Ideal for trusted collaborators who don't need to manage team access

Property Analysts and Viewers

Standard roles for consuming analytics without configuration access.

Analyst role for:

• Collaborator team members building reports and explorations
• Data analysts performing deep-dive analysis
• Users who need to create personal explorations but not shared assets

Viewer role for:

• Client stakeholders who need read-only visibility
• Collaborators during post-implementation monitoring phase
• Compliance or audit teams requiring data access verification
• Temporary access for demos or reviews

Cost considerations: All roles consume the same resources in GA4. No licensing difference between Viewer and Administrator (unlike GA Universal Analytics).

Service Accounts for API Access

GA4 API access uses Google Cloud service accounts with OAuth 2.0.

Service account pattern:

1. Create a Google Cloud project
2. Enable Google Analytics Data API and Admin API
3. Create a service account in that project
4. Generate service account key (JSON credentials)
5. Grant the service account access to GA4 properties (treat as a user)
6. Store service account key in secure vault

For collaborator integrations:

• Use collaborator-controlled Google Cloud projects when possible
• Grant minimal property access (Viewer for read-only API, Editor for configuration API)
• Rotate service account keys annually
• Document which integrations use which service accounts

Access Control and Data Governance

Property-Level Data Segmentation

GA4 properties are the primary data isolation boundary.

Single property per brand/app:

• Clearest security boundary
• Grant collaborators access only to properties in engagement scope
• Simple to audit and document
• May result in many properties to manage

Multi-property with roll-up:

• Separate properties for each brand/region/app
• Optionally use roll-up property for aggregate reporting
• Grant collaborators access to specific child properties only
• Recommended for multi-brand clients

Subproperties (GA4 feature):

• Create filtered views of a source property
• Not yet widely available; check latest GA4 documentation
• When available, use to scope collaborator access to regions or segments

Data Streams and Cross-Platform Tracking

Data streams represent individual data sources (web, iOS, Android).

Data stream visibility:

• All streams in a property are visible to users with property access
• Cannot hide individual streams from users
• If collaborators should only see web data, create separate mobile app property

Cross-platform tracking:

• User ID and Google signals enable cross-device tracking
• All users with property access can see cross-platform data
• Consider compliance implications (GDPR, CCPA) before granting collaborator access to user-level data

Mitigation:

• Use separate properties for different platforms if access must be isolated
• Configure data retention carefully (14 months default; reduce if needed)
• Apply metric restrictions to hide specific data types

Metric and Dimension Restrictions

GA4 allows restricting cost/revenue metrics from specific users.

Cost and revenue metrics:

• Includes: total revenue, purchase revenue, ROAS, ad cost, ad click cost
• Apply restrictions when collaborators shouldn't see financial data
• Configured per user in property user management

Implementation:

1. Navigate to Admin → Property Access Management
2. Select user to restrict
3. Enable "Restrict metrics" option
4. Save changes

Limitations:

• Only cost/revenue metrics can be restricted
• Cannot hide custom dimensions/metrics selectively
• For broader data hiding, use separate properties or subproperties

Linked Products and Cross-Platform Access

Google Ads Linking

Linking GA4 to Google Ads allows importing cost data and exporting audiences.

Permission requirements:

• Property Editor or Administrator to create the link
• Google Ads account must grant GA4 admin access

Collaborator considerations:

• If collaborator manages Google Ads, grant Editor to create/manage links
• Linked Google Ads data is visible to all property users
• Unlinking doesn't retroactively remove imported cost data
• Document links created by collaborators for offboarding

Google Search Console Linking

Linking GA4 to Search Console imports organic search performance data.

Permission requirements:

• Property Editor or Administrator in GA4
• Search Console owner or full user in Search Console

For collaborators:

• Collaborators need Search Console access separately
• Link persists independently of user permissions
• Document which collaborator created the link

BigQuery Export

GA4 properties can export raw event data to BigQuery for advanced analysis.

Setup requirements:

• Property Editor or Administrator to configure export
• Google Cloud project with BigQuery enabled
• Billing account attached to Cloud project

Collaborator patterns:

• Client-controlled: Client owns GCP project; collaborator queries BigQuery with separate permissions
• Collaborator-controlled: Collaborator's GCP project receives exports; client has no visibility
• Hybrid: Both receive exports to separate projects

Security considerations:

• BigQuery exports include all event-level data (no metric restrictions apply)
• Access control managed in Google Cloud IAM, not GA4
• Exports continue until disabled; outlive user permissions
• Document export configurations for offboarding

Recommendation for collaborators: Use client-controlled GCP projects. Grant collaborators BigQuery dataset access separately from GA4.

SSO and Google Workspace Integration

Google Accounts and Identity

GA4 users must have Google accounts (personal or Workspace).

Google Account types:

• Personal Gmail accounts: Owned by the user (e.g., user@gmail.com)
• Google Workspace accounts: Managed by an organization (e.g., user@company.com)
• Cloud Identity accounts: Enterprise identity without Workspace apps

For collaborators:

• Collaborators use their own Google accounts
• If collaborator has Google Workspace, they authenticate via their organization
• No separate GA4 passwords; Google account credentials apply

Workspace Domain Policies

If your organization uses Google Workspace, domain admins can enforce policies.

Policies affecting GA4 access:

• Require 2-Step Verification (MFA) for all users
• Restrict which external domains can be granted access
• Session length and re-authentication requirements
• Data access restrictions

For collaborator access:

• Collaborators authenticate with their own Workspace/Google account
• Your Workspace policies don't apply to external collaborators (they use their own organization's policies)
• Ensure collaborators enable 2FA on their Google accounts

No Native SSO/SCIM for GA4

GA4 doesn't support SAML SSO or SCIM provisioning independently.

Workarounds:

• If your organization uses Google Workspace with SSO federation, internal users benefit
• External collaborators log in with their own Google accounts (Workspace or personal)
• No automated provisioning; user management is manual

Audit approach:

• Manually review user access quarterly
• Export user lists from GA4 Admin → Property Access Management
• Compare against active contracts and SOWs

API Access and Service Accounts

Google Analytics Data API (GA4)

Programmatic access to GA4 reporting data.

Authentication methods:

• OAuth 2.0 user credentials (for user-delegated access)
• Service account credentials (for server-to-server integrations)

Service account setup:

1. Create Google Cloud project (cloud.google.com)
2. Enable "Google Analytics Data API (GA4)"
3. Create service account in IAM & Admin
4. Generate JSON key for service account
5. Grant service account email address access to GA4 property (as a user with Viewer, Analyst, Editor, or Admin role)
6. Use JSON key in your application for authentication

Scoping service account access:

• Grant Viewer role for read-only data extraction
• Grant Editor for configuration API access (create audiences, modify settings)
• Service accounts inherit metric restrictions applied to them

Google Analytics Admin API

Programmatic access to GA4 configuration and user management.

Use cases:

• Create/modify events, conversions, and audiences via API
• Automate user management (add/remove users programmatically)
• List properties and data streams

Permission requirements:

• Editor role for configuration changes
• Administrator role for user management API calls

For collaborator integrations:

• Rarely needed; most collaborator APIs use Data API only
• If required, document explicitly in SOW
• Monitor API usage for unexpected configuration changes

API Quotas and Limits

Google Analytics APIs enforce quotas to protect platform stability.

Data API (reporting) quotas:

• 25,000 tokens per day per property (default)
• Higher quotas available for Google Analytics 360 customers
• Tokens consumed based on request complexity (more dimensions = more tokens)

Admin API quotas:

• 500 requests per day per project (default)
• Lower limits because configuration changes are less frequent

For collaborator integrations:

• Share quota documentation to prevent overuse
• Implement exponential backoff on quota errors
• Consider requesting quota increases if needed (via Google Cloud Console)
• Monitor API usage in Google Cloud Console

OAuth Scopes for APIs

When using OAuth 2.0, request only the scopes needed.

Read-only scopes:

• https://www.googleapis.com/auth/analytics.readonly - View GA4 data

Read-write scopes:

• https://www.googleapis.com/auth/analytics - View and manage GA4 data
• https://www.googleapis.com/auth/analytics.edit - Edit GA4 configuration
• https://www.googleapis.com/auth/analytics.manage.users - Manage users

For collaborators:

• Use read-only scope for reporting integrations
• Grant edit scope only when collaborators need to create audiences/conversions via API
• Avoid manage.users scope unless explicitly required

Audit Logging and Monitoring

Google Analytics Change History

GA4 tracks configuration changes within the property.

What's logged:

• Event creation/modification/deletion
• Conversion changes
• Audience creation and updates
• Data stream configuration changes
• User permission changes (additions, removals, role changes)
• Filter and comparison modifications

Accessing change history:

1. Navigate to Admin → Account or Property (depending on scope)
2. Click "Account change history" or "Property change history"
3. Filter by date range, user email, or change type
4. Export to Google Sheets for archival

Retention:

• Google retains change history for 6 months in the UI
• Export monthly for long-term compliance storage
• Include in SOC 2, ISO 27001, or GDPR documentation

Limitations:

• Change history doesn't track data views or report creation
• API usage not detailed in change history (use Google Cloud Audit Logs for API calls)

Google Cloud Audit Logs (for API activity)

If collaborators use GA4 APIs via Google Cloud, audit logs are available.

Accessing Cloud Audit Logs:

1. Navigate to Google Cloud Console (console.cloud.google.com)
2. Select the project containing service accounts
3. Go to Logging → Logs Explorer
4. Filter by "Google Analytics Data API" or "Google Analytics Admin API"
5. View logs for API calls, including service account identity

For collaborator monitoring:

• Enable Cloud Audit Logs for projects used by collaborators
• Alert on unexpected Admin API calls (configuration changes)
• Review logs quarterly for anomalous data extraction patterns

Access Management Auditing

GA4 doesn't provide detailed user activity logs (who viewed what reports).

What you CAN track:

• User additions and removals (in change history)
• Permission changes (in change history)
• Last login date (not available natively; Google accounts don't expose this to GA4)

Workarounds:

• Review user lists quarterly and ask collaborators to confirm who still needs access
• Rely on contractual terms and trust for data access governance
• For high-security needs, use BigQuery exports with your own access logging

Access Requests at a Glance

• Start with Add User Access when the collaborator needs account-level or property-level roles.
• Apply Update Access & Roles when scopes shift, such as enabling BigQuery exports or adding data streams.
• Follow Remove User Access when the engagement closes or legal directs access removal.

Add, Update, Remove at a Glance

• Add: Invite the collaborator's Google identity, pick the right level (account vs. property), and apply data restrictions if cost/revenue data should stay hidden.
• Update: Rebalance roles as new properties launch, conversion ownership shifts, or BigQuery exports move. Confirm linked product permissions match the new scope.
• Remove: Drop property and account access, unlink any shared BigQuery or Ads connections, and verify the change in Change History for audit proof.

Platform Notes and Practical Steps

• Account vs. property is the first fork: Decide whether the collaborator needs account-level control (billing, property creation) or just property-level work. Start at the narrowest level and only elevate if setup tasks require it.
• Data restrictions are your guardrails: Cost and revenue visibility can be restricted per user. Use them when the collaborator should analyze traffic but not see sensitive commerce metrics, and log the choice in your access tracker.
• Linked products multiply permissions: Adding GA4 access alone may not give the collaborator what they need. Confirm Google Ads, Search Console, and BigQuery links also include the collaborator where required, and remove those links during offboarding.
• Evidence to retain: Download the Access Management list (before/after), capture Change History entries, and note any BigQuery dataset ACL updates whenever roles change.

Roles to Maintain

• Account Administrators: Manage billing, linked products, and property creation. Limit to core client owners plus the collaborator's admin when necessary.
• Property Editors/Analysts: Build reports, audiences, and conversions. Assign the collaborator this role for day-to-day analytics work.
• BigQuery / API Users: Service accounts for exports or offline processing. Store credentials securely and rotate on schedule.

Best Practices for Team Access Management

Start with Property-Level Access

Default to granting access at the property level, not account level.

Benefits:

• Limits collaborator visibility to only relevant properties
• Reduces risk of accidental changes to other properties
• Clearer audit trail for compliance

When to elevate to account level:

• Collaborator manages multiple properties and needs centralized access
• Implementation requires creating new properties
• Document account-level access explicitly in SOW

Use Viewer/Analyst for Post-Implementation

After implementation is complete, downgrade collaborators from Editor to Analyst or Viewer.

Pattern:

• Implementation phase: Property Editor (configure events, audiences, conversions)
• Monitoring phase: Property Analyst (create explorations, review data)
• Client handoff: Property Viewer (read-only for occasional check-ins)

Benefits:

• Reduces risk of accidental configuration changes
• Aligns permissions with actual work being performed
• Demonstrates least-privilege principle for compliance

Separate Production and Development Properties

Use different properties for development/staging vs. production.

Access pattern:

• Development property: Property Editor for collaborators (freedom to experiment)
• Production property: Property Analyst or Viewer (limits configuration risk)
• Clearly label properties (e.g., "Company Website - Production", "Company Website - Dev")

Testing before production:

• Collaborators test event configurations in dev property
• Client reviews and approves
• Collaborator replicates to production property

Apply Metric Restrictions Proactively

If collaborators don't need cost/revenue data, restrict it from the start.

Implementation:

1. Determine which collaborators need financial metrics
2. Apply cost/revenue restrictions to those who don't
3. Document restrictions in access tracker
4. Review annually as roles change

Benefits:

• Aligns with data minimization principles (GDPR, CCPA)
• Reduces risk of financial data exposure
• Simplifies compliance reporting

Common Access Issues and Solutions

Issue: Collaborator Can't See Property

Symptoms:

• User logs in to GA4 but sees "No properties available"
• Specific property missing from dropdown

Resolution steps:

1. Verify collaborator accepted the email invitation
2. Confirm collaborator is logged into the correct Google account (check email address)
3. Check property access management to verify user is listed
4. Ensure user has at least Viewer role (not "None")
5. Try incognito/private browsing mode to rule out browser cache issues

Prevention: After adding users, ask them to confirm they can see the property before the onboarding meeting ends.

Issue: Linked Product Access Doesn't Work

Symptoms:

• Collaborator has GA4 access but can't see Google Ads data
• BigQuery export configured but collaborator can't query the dataset

Resolution steps for Google Ads:

1. Verify GA4 and Google Ads are actually linked (Admin → Property → Google Ads Links)
2. Confirm collaborator has access to the linked Google Ads account separately
3. Check that enough time has passed for data import (24-48 hours after linking)

Resolution steps for BigQuery:

1. Verify BigQuery export is configured and running (Admin → Property → BigQuery Links)
2. Confirm collaborator has IAM permissions in Google Cloud to query the BigQuery dataset
3. Check that export has run at least once (exports are daily)

Prevention: Document all linked products and their separate permission requirements. Test collaborator access to linked products, not just GA4.

Issue: Service Account API Calls Return 403 Errors

Symptoms:

• Service account authenticates successfully but API calls return "User does not have sufficient permissions"

Resolution steps:

1. Verify service account email is granted access to the property in GA4 Admin → Property Access Management
2. Confirm service account has appropriate role (Viewer for read-only, Editor for configuration)
3. Check that Google Analytics Data API is enabled in the Google Cloud project
4. Verify service account key is not revoked or expired
5. Test with a different API endpoint to isolate permissions vs. configuration issues

Prevention: Document which service accounts are used for which integrations. Test service account access immediately after creation.

Issue: User Can't Create Audiences or Conversions

Symptoms:

• "Save" button greyed out
• "You don't have permission to create" error

Resolution steps:

1. Verify user has Editor or Administrator role (Analyst and Viewer cannot create audiences)
2. Check for audience/conversion limits (GA4 has caps: 100 audiences, 30 conversions per property)
3. Ensure user is creating in the correct property (not a linked property where they lack permissions)

Prevention: Grant Editor role explicitly when collaborators need to create audiences/conversions. Document GA4's limits.

Issue: Cost/Revenue Data Still Visible Despite Restrictions

Symptoms:

• User has metric restrictions enabled but can still see revenue data
• Restrictions applied but not taking effect

Resolution steps:

1. Verify restrictions were saved correctly in user management
2. Have user log out and log back in (permissions may be cached)
3. Check that user doesn't have access via a different permission grant (e.g., account-level access overriding property-level restriction)
4. Test in incognito mode to rule out browser caching

Prevention: Test metric restrictions immediately after applying. Document which users have restrictions for quarterly reviews.

Security Recommendations

Require 2-Step Verification (2FA)

Google accounts support 2-Step Verification (2FA) for enhanced security.

For collaborators:

• Require collaborators to enable 2FA on their Google accounts
• Verify during onboarding (ask for screenshot or confirmation)
• If collaborator uses Google Workspace, their org may enforce 2FA centrally

Verification methods:

• Authenticator app (Google Authenticator, Authy)
• SMS codes (less secure but better than nothing)
• Hardware security keys (highest security, recommended for high-value properties)

Cannot enforce via GA4: GA4 doesn't have settings to require 2FA. Rely on contractual requirements and periodic checks.

Use Google Workspace Accounts When Possible

Encourage collaborators to use Workspace accounts instead of personal Gmail.

Benefits:

• Organization-level security policies (2FA enforcement, session management)
• Easier to verify account ownership (domain-based email)
• Professional audit trail (vs. personal @gmail.com)

For client teams:

• If your organization has Workspace, use those accounts for GA4 access
• Simplifies internal user management and access reviews

Rotate Service Account Keys Annually

Service account JSON keys are long-lived credentials.

Rotation schedule:

• Production integrations: Rotate annually
• High-privilege keys (Editor/Admin): Rotate every 6 months
• When collaborator team changes: Rotate immediately

Rotation process:

1. Generate new service account key in Google Cloud Console
2. Update collaborator integrations to use new key
3. Test integrations to ensure they work
4. Delete old key in Google Cloud Console
5. Document rotation in secrets management system

For collaborator engagements:

• Rotate all service account keys when engagement ends
• Provide new keys via secure transfer (not email)
• Monitor for usage of old keys after rotation (indicates missed integration update)

Review Linked Products on Offboarding

When removing collaborator access, check for linked products they configured.

Audit checklist:

• Google Ads links created by collaborator (review in Admin → Google Ads Links)
• BigQuery exports pointing to collaborator-controlled GCP projects
• Search Console links to collaborator-managed properties
• Measurement Protocol API secrets (if used for server-side tracking)

Actions:

• Unlink products that should not persist after engagement ends
• Transfer ownership of necessary links to client team members
• Document all links in offboarding report

Monitor for Anomalous Configuration Changes

Set up processes to detect unexpected changes.

Monitoring approach:

1. Review Change History monthly
2. Alert on changes by collaborator accounts outside normal business hours
3. Investigate audience/conversion deletions (may indicate accidental or malicious activity)
4. Check for new user additions by collaborators (if they have Admin role)

Response workflow:

1. Detect anomaly in change history
2. Contact collaborator to verify legitimacy
3. If unauthorized: Immediately revoke access and assess impact
4. Document incident and update access procedures

Governance Checklist

Before granting access:

• Data Processing Agreement signed and filed
• Collaborator's Google account email obtained and verified
• Access level determined (account vs. property, role)
• Metric restrictions applied if hiding cost/revenue data
• 2FA confirmed enabled on collaborator's Google account
• Service account credentials generated and stored in vault (if API access needed)
• Access expiration date recorded in calendar
• Linked products documented (if collaborator will create links)

Quarterly review:

• Confirm property access aligns with active contract/SOW
• Review change history for unexpected configuration changes
• Verify collaborator's Google account is still active (attempt login or ask for confirmation)
• Check for dormant access (no changes in 90+ days, consider downgrading to Viewer)
• Export and archive change history and access management lists
• Review linked products (Google Ads, BigQuery, Search Console) for accuracy

When engagement ends:

• Remove collaborator from all properties and accounts
• Revoke service account access (remove from property access management)
• Delete service account keys in Google Cloud Console (if client-managed)
• Unlink products configured by collaborator (or transfer ownership)
• Export final change history showing removal
• Confirm collaborator deleted local data exports per DPA
• Archive access documentation and change history exports
• Update access tracker to mark engagement closed

Annual compliance:

• Review all GA4 access against current contracts
• Audit account-level vs. property-level access for over-provisioning
• Test BigQuery export configurations and access controls
• Review and update service account key rotation schedule
• Update documentation for new GA4 features or changes

Related Documentation

• Add User Access - Step-by-step guide for inviting collaborators and assigning permissions
• Update Access & Roles - How to modify access levels and apply metric restrictions
• Remove User Access - Offboarding workflow including linked product cleanup
• Google Analytics Help Center - Official product documentation
• Google Analytics Data API Documentation - Technical reference for API access

Additional Resources

• Google Analytics: analytics.google.com
• Google Cloud Console: console.cloud.google.com (for service accounts and API enablement)
• GA4 Change History: Admin → Account/Property Change History
• Google Analytics API Quotas: console.cloud.google.com → APIs & Services → Quotas

Document which Google accounts or service accounts represent the collaborator and keep them in your access tracker. Review GA4 Access Management quarterly to confirm roles and remove unused accounts. Capture evidence of consent for data sharing with the collaborator where required by privacy agreements. Confirm the collaborator is added to the Google Cloud project used for BigQuery exports when relevant.