GA4 privacy settings are not a single switch. This guide explains how data retention, user deletion, Google signals, reporting identity, consent, and connected exports fit together, then provides a reusable audit checklist for analytics, engineering, and compliance teams.
Overview
A useful GA4 privacy review starts by separating four questions:
- How long is data available? This includes the retention setting for event-level and user-level data used in analyses, plus the separate retention policies of connected systems.
- Which data is collected? Consent choices, Google signals, user-provided identifiers, advertising features, and custom parameters all affect the data entering a property.
- Who can access it? Property permissions, linked products, exports, and saved reports determine where analytics data can be viewed or copied.
- How are individual requests handled? A user-deletion workflow must identify the right property, identifier, systems, owner, evidence, and completion criteria.
GA4 data retention settings should therefore be documented alongside your privacy notice, consent configuration, measurement plan, and data inventory. They are operational controls, not a substitute for deciding what your organization is permitted or required to collect. Regional privacy expectations and contractual obligations can differ, so treat this article as an implementation checklist rather than legal advice.
GA4 settings reference
| Control or area | What it affects | What to record during an audit |
|---|---|---|
| Data retention | How long certain event-level and user-level data remains available for supported analyses and explorations. | Selected period, property, date changed, owner, and reason. |
| User deletion | A request process for removing data associated with an identified user or identifier from the relevant Analytics property. | Request ID, identifier type, scope, approver, submitted date, and completion evidence. |
| Google signals | Additional signals and advertising-related features, subject to eligibility, configuration, and consent requirements. | Whether enabled, applicable regions, consent dependency, and review owner. |
| Reporting identity | How GA4 chooses available identifiers when presenting users, sessions, and related reporting views. | Selected identity, rationale, known limitations, and reporting documentation. |
| BigQuery and other exports | Copies of analytics data managed outside the GA4 reporting interface. | Destination, export scope, warehouse retention, access roles, and deletion procedure. |
Checklist by scenario
Scenario 1: Initial GA4 privacy setup
- Confirm the property, data streams, domains, and environments included in scope.
- List every event parameter that could contain personal, confidential, or free-text information. Remove unnecessary values before they reach GA4; retention settings do not make inappropriate collection acceptable.
- Choose a data retention period that matches the documented business need and internal policy. Record the setting rather than relying on an administrator's memory.
- Review Google signals and advertising-related features separately from ordinary measurement. Confirm that their use is consistent with the consent design and approved purpose.
- Choose a reporting identity deliberately. Explain whether the property relies on User-ID, device-based signals, or a blended approach, and document how gaps in consent or identifiers affect interpretation.
- Check that the consent implementation sends the intended states before analytics or advertising tags run. For implementation help, use the Consent Mode V2 and GA4 setup and testing guide.
- Assign an owner for user-deletion requests and a backup owner for absences.
Scenario 2: Processing a user-deletion request
Use a controlled, role-based process. Do not place an email address, phone number, or other sensitive identifier in a ticket title or shared spreadsheet unless your approved process explicitly requires it.
- Receive and authenticate: Confirm the requester's identity using the organization's approved privacy workflow.
- Translate the request: Determine which Analytics property, data stream, date range, and identifier type are relevant. A customer ID, User-ID, client ID, or app instance identifier may lead to different search requirements.
- Check scope: Establish whether the request concerns GA4 only or also includes a CRM, data warehouse, ad platform, server-side tagging endpoint, or offline conversion store.
- Authorize: Have the designated privacy or data owner approve the scope before an administrator performs the action.
- Submit in GA4: Use the current user-deletion workflow available in the relevant property. Record the request reference, selected deletion option, timestamp, and operator.
- Handle connected copies: Follow the separate deletion procedures for BigQuery, CRM records, exports, backups, and other systems where applicable. GA4 deletion does not automatically establish that every downstream copy has been removed.
- Close with evidence: Record completion status, exceptions, systems not covered, retention-based limitations, and the response sent to the requester.
Scenario 3: Quarterly or pre-release audit
- Compare the GA4 retention setting with the approved retention-policy template.
- Review administrator and analyst access, including linked products and warehouse permissions.
- Test consent states in a browser or staging environment and confirm that tags, events, and modeled reporting behave as documented.
- Inspect recent event names and parameters for accidental personal data, debug values, or new fields introduced by a release.
- Review user-deletion requests for overdue, incomplete, or inconsistently documented cases.
- Reconcile GA4 data with exports and dashboards so stakeholders know which systems follow different retention rules.
What to double-check
Retention is not the same as deletion. A shorter retention setting governs the availability of certain Analytics data; it does not by itself remove records from your CRM, warehouse, backups, or advertising platforms. Maintain a system-by-system data inventory.
Reporting identity is not an erasure control. Changing from blended to device-based reporting can change how reports are assembled, but it should not be treated as a way to remove a person's data or satisfy a deletion request.
Consent and retention solve different problems. Consent controls should govern whether and how measurement is initiated or configured. Retention controls how long eligible data remains available. Neither control repairs data collected before the correct configuration was deployed.
Google signals require separate review. Check whether the feature is enabled, where it is used, which reports depend on it, and whether consent and regional requirements have been addressed. Do not assume that a general GA4 consent setting documents every advertising-related use.
Exports create an independent control surface. For BigQuery or another destination, document table retention, partition expiration, access, backups, and deletion handling. The same principle applies to server-side tracking and conversion APIs: an event routed through another system needs its own privacy and deletion review.
Use least privilege. Limit property administrators and deletion operators to the people who need those capabilities. Review access after team changes, agency changes, migrations, and ownership transfers.
Common mistakes
- Choosing the longest period by default: More historical detail is not automatically more useful. Tie the choice to a documented analysis need.
- Assuming standard reports show every retained record: GA4 reporting surfaces use different processing and aggregation rules. Document which reports and explorations depend on event-level data.
- Sending free-text form fields: Data-layer values, URLs, page titles, and custom parameters can unintentionally expose personal information. Inspect real payloads during QA.
- Deleting only the Analytics record: A deletion request may involve CRM, support, email, warehouse, and advertising records. Assign owners across the full data flow.
- Changing settings without recording the change: Save the previous value, new value, effective date, reason, approver, and expected reporting impact.
- Using dashboards as the source of truth: A dashboard may cache, aggregate, or combine data. Link each dashboard to its source, retention rule, and data owner.
- Testing only the consent banner: Validate network requests, tag firing, consent updates, event parameters, and downstream destinations—not just the visible interface.
For broader implementation checks, pair this privacy review with the GA4 implementation audit checklist and the GTM data layer guide.
When to revisit
Review this checklist at least before seasonal planning cycles, major site releases, property migrations, consent-management changes, and new advertising or warehouse integrations. Also revisit it when Google changes GA4 administrative controls, reporting behavior, connected-product settings, or published guidance.
A practical recurring schedule is:
- Monthly: sample events and parameters, check consent behavior, and review unusual access or deletion activity.
- Quarterly: confirm retention settings, reporting identity, Google signals, user-deletion records, and connected-system policies.
- Before a release: run tag and data-layer QA, compare payloads with the measurement plan, and confirm no new personal data is introduced.
- After a tool or workflow change: update the data inventory, owners, runbooks, privacy notice references, and deletion procedure.
Keep a dated audit record with the property ID, settings snapshot, consent test results, access review, open exceptions, and next review date. That small amount of evidence makes the next privacy review faster and gives analytics teams a clear path from GA4 configuration to accountable data governance.
