GA4 Privacy Settings Audit: Every Setting That Affects Your GDPR Compliance

GA4 has more privacy-relevant settings than most analytics admins realize. They're scattered across property-level configuration, data collection toggles, sharing agreements, and account-level contracts. Some are on by default. Some changed recently. Several can put you on the wrong side of the GDPR without any visible warning in the interface.

This guide walks through every GA4 setting that touches privacy or GDPR compliance, tells you where to find it in the Admin panel, explains what it does from a data-protection standpoint, and ends with a concrete audit checklist you can run against any GA4 property. If you run GA4 for a site with EU visitors, this is the reference you work from.

For the broader question of whether GA4 can be GDPR-compliant at all, see our dedicated guide on whether Google Analytics is GDPR-compliant. This article assumes you've decided to use it and want to make sure every knob is turned the right way.

1. Data Collection Settings

These settings control what GA4 collects from visitors in the first place. They're the front line of your privacy posture because they determine what personal data enters the system.

Google Signals

Where: Admin > Data collection and modification > Data collection

Google Signals associates GA4 session data with signed-in Google users, enabling cross-device reporting and demographics/interest data within GA4's own reports. Until recently it also served as a gate on advertising data flowing from GA4 to linked Google Ads accounts.

That changed on June 15, 2026. Google demoted Signals to a reporting-only control. It still governs whether GA4 itself can associate sessions with signed-in users for its internal reports, but it no longer has any authority over the GA4-to-Google Ads advertising data flow. That responsibility moved entirely to the ad_storage parameter in Consent Mode. We covered this shift in detail in our Google Signals removal guide.

GDPR implication: Even in its reduced role, Signals increases the personal data GA4 processes. Cross-device association and demographic profiling based on Google account activity are processing operations that need a lawful basis. If you don't have a clear reason to use demographics and cross-device reports, turning Signals off is the simplest way to minimize data collection.

Granular Location and Device Data

Where: Admin > Data collection and modification > Data collection

This toggle controls whether GA4 collects city-level geolocation, detailed device models, and specific browser versions. When disabled, GA4 still collects country-level location but drops the finer-grained data.

GDPR implication: City-level location combined with device fingerprint attributes can increase re-identification risk. Disabling this is a straightforward data-minimization measure under Article 5(1)(c). If your analytics needs are met by country-level geo data, turn it off.

User-ID and Cross-Device Tracking

Where: Admin > Data collection and modification > Data collection (User-ID collection toggle); implementation in your tag/code

User-ID lets you assign your own persistent identifier to users, typically from your authentication system. When active, GA4 stitches sessions across devices for the same logged-in user. This is separate from Google Signals: User-ID uses your own identifier, while Signals uses Google's.

GDPR implication: A User-ID that maps to a real account is unambiguously personal data. If you enable it, your privacy policy needs to disclose the cross-device tracking, and you need consent (or another lawful basis) for it. The identifier itself should be pseudonymized: use a hashed or opaque ID, never a raw email address or username.

Ads Personalization Signals

Where: Admin > Data display > Ads personalization (being migrated to Google Ads UI later in 2026)

This setting controls whether GA4 data can be used to personalize ads shown to your visitors. It works alongside the Consent Mode parameters ad_personalization and ad_user_data.

GDPR implication: Ads personalization involves profiling under the GDPR. If you're using consent as your legal basis, this setting should only be active for visitors who've opted into marketing/advertising purposes. After the June 15, 2026 changes, the ad_storage and ad_personalization Consent Mode signals are what actually gate this data flow. See our guide on the June 2026 GA4 and Google Ads consent changes for the full picture.

2. Data Retention Settings

Where: Admin > Data collection and modification > Data retention

GA4 offers two retention periods for event-level data: 2 months (the default) or 14 months. GA4 360 properties have additional options up to 50 months. This controls how long individual event data (including user-level data used in Explorations) is kept. Aggregated reports are unaffected and remain available regardless of this setting.

What "reset on new activity" does: There's a toggle labeled "Reset user data on new activity." When enabled, the retention clock restarts every time a user generates a new event. When disabled, data expires strictly from the date of collection. From a GDPR standpoint, disabling this option creates a clearer, more predictable retention period.

GDPR implication: The GDPR's storage limitation principle (Article 5(1)(e)) requires that personal data isn't kept longer than necessary. A 2-month retention period is conservative and defensible. If you extend to 14 months, you should be able to articulate why you need event-level data that old. "We might want to look at it later" isn't a purpose under Article 5(1)(b). If you're keeping 14 months of data, document the business justification in your records of processing activities.

3. Data Sharing Settings

GA4 has several data-sharing toggles that control whether Google can use your analytics data for purposes beyond your own reporting. Each one is a separate GDPR consideration.

Where: Admin > Account settings > Account details > Data Sharing Settings (account level)

Google Products & Services

When enabled, your GA4 data can be shared with other Google services (like Google Ads, Google Cloud) to improve those services. If your GA4 property is linked to Google Ads, some data sharing happens through those product links regardless of this toggle. But this setting enables broader sharing beyond what the product links require.

GDPR implication: Sharing analytics data with Google for Google's own product improvement changes the purpose of processing. If your legal basis is consent for analytics, that consent probably doesn't cover Google using the data to improve its ad products. Review this carefully. Many DPOs disable it as a precaution.

Benchmarking

Contributes your data (anonymized and aggregated) to industry benchmarking reports. Other GA users can see aggregated statistics for your industry vertical, and you can see theirs.

GDPR implication: Google claims this data is anonymized before contribution. If that's genuinely the case, anonymized data falls outside the GDPR's scope. The practical risk is low, but some organizations disable it on principle under data minimization.

Technical Support

Allows Google's support team to access your analytics data when you file a support ticket. Without it, Google support operates blind.

GDPR implication: This is a processing activity that should be covered by your Data Processing Amendment with Google (see section 6). Google's support agents accessing your data constitutes processing by a sub-processor. The DPA covers this, but know it's there.

Account Specialists

Lets Google's sales and account specialists access your data to provide optimization recommendations. This is the most commercially-motivated sharing option.

GDPR implication: Google's account specialists reviewing your analytics data to suggest products or optimizations is a commercial purpose. If you're running on consent-based processing, this goes beyond what users consented to when they clicked "Accept analytics cookies." Consider disabling it unless you have a specific need.

4. Consent Mode Integration

Where: Configured in your tag management setup (GTM, gtag.js, or CMP), not in the GA4 Admin itself

Consent Mode isn't a single GA4 setting; it's a protocol that sits between your consent management platform and Google's tags. But it's the most consequential privacy configuration affecting your GA4 data, and several GA4 Admin settings interact with it.

The Four Consent Signals

Consent Mode v2 uses four parameters that your CMP must set on every page load:

• analytics_storage: controls whether GA4 can read and write analytics cookies (_ga, _gid). When denied, GA4 sends cookieless pings instead.
• ad_storage: controls advertising cookie access. After June 15, 2026, this is the single authority over whether advertising data flows from GA4 to Google Ads.
• ad_user_data: controls whether user-provided data (email addresses in Enhanced Conversions, for example) can be sent to Google for advertising.
• ad_personalization: controls whether collected data can be used for personalized advertising and remarketing audiences.

For visitors in the EEA and UK, all four must default to denied before any consent choice is made. For a thorough comparison of how Advanced and Basic Consent Mode differ, see our Advanced vs Basic Consent Mode guide.

Advanced vs Basic Consent Mode

Advanced Consent Mode sends cookieless, anonymous pings to Google even when consent is denied. Google uses these to build behavioral models that estimate conversions and fill reporting gaps. No cookies are set, and no identifiers are written, but data does leave the browser.

Basic Consent Mode blocks all Google tags entirely until consent is granted. No pings, no data, no modeling. It's cleaner from a privacy standpoint but leaves bigger gaps in your reports.

GDPR implication: Whether Advanced Consent Mode's cookieless pings constitute personal data processing is debated. They include a truncated timestamp, the page URL, and a randomly generated per-page-view identifier. Some DPAs treat any data transmission to a third-country processor as requiring consent. Others consider it sufficiently anonymized. Your choice here should reflect your risk posture and the guidance from your supervisory authority. For the full analysis, see our guide on how Consent Mode v2 affects GA4 reporting.

5. Data Deletion Requests

Where: Admin > Data collection and modification > Data deletion requests

GA4 provides a mechanism to delete user-level data for specific date ranges. You can delete data based on user properties, event parameters, or for all users within a time window. Deletion requests are processed within 7 days and are irreversible once completed.

What it can do:

• Delete all user-level data for a date range
• Delete specific user properties (e.g., User-ID values)
• Delete specific event parameters across all events in a range

What it can't do:

• Delete data for a single identified user by their GA client ID or User-ID. GA4 doesn't have a "delete this specific user" button like some analytics platforms do. You delete by parameter values across a time range.
• Delete aggregated report data. Standard reports built from pre-aggregated data survive deletion requests.

GDPR implication: Under Article 17 (right to erasure), data subjects can request deletion of their personal data. GA4's deletion tool is blunt: you can't target an individual user's analytics record without affecting others in the same time range. This is a known limitation. If you receive an erasure request, you may need to delete a broader range of data than strictly necessary to comply, or rely on the fact that the data is pseudonymized and will expire under your retention setting. Document your approach in your DSAR handling procedures. For a deeper treatment, see our DSAR handling guide.

6. BigQuery Export and Privacy Implications

Where: Admin > Product links > BigQuery links

GA4 can export raw event-level data to BigQuery, Google's data warehouse. This is a powerful feature for custom analysis but introduces a separate privacy surface that many teams overlook.

What gets exported: Every event, every parameter, user properties, session data, geo information, device metadata, and (if configured) User-ID values. This is the rawest form of your GA4 data, and it includes pseudonymous identifiers that qualify as personal data under the GDPR.

GDPR implications:

• Separate data store, separate obligations. Data in BigQuery is no longer subject to your GA4 retention settings. If you set GA4 retention to 2 months but export to BigQuery indefinitely, you've created a data store that may violate the storage limitation principle. Set BigQuery table expiration policies that match your documented retention period.
• Access control. BigQuery data is accessible to anyone with the right IAM permissions in your Google Cloud project. Audit who has access. Analytics data containing pseudonymous identifiers shouldn't be readable by everyone in your organization.
• Processing location. Choose a BigQuery dataset location that aligns with your data transfer obligations. If you're subject to the GDPR, use an EU multi-region dataset (europe-west or EU) so analytics data stays within the European Economic Area.
• Consent-denied data. If you're using Advanced Consent Mode, BigQuery exports include the cookieless ping events from non-consenting users. These rows have null client IDs and limited parameters, but they're still in your data warehouse. Make sure your retention and access controls cover them.

7. GA4 Data Processing Amendment (DPA)

Where: Admin > Account settings > Account details > Data Processing Amendment (or via the Google Ads account's Terms and Conditions page)

The Data Processing Amendment is the GDPR-required contract between you (the data controller) and Google (the data processor). It establishes Google's obligations when processing personal data on your behalf through GA4.

What the DPA covers:

• Google's commitment to process data only on your instructions
• Sub-processor transparency (Google maintains a list of sub-processors)
• Data security obligations and incident notification
• Audit rights (limited, but present)
• Data transfer mechanisms for international transfers (Standard Contractual Clauses)
• Deletion obligations when the processing relationship ends

GDPR implication: Under Article 28, you must have a data processing agreement in place before processing personal data through a third-party processor. If you haven't accepted Google's DPA, you're technically processing personal data through Google without the required contractual safeguards. It takes 30 seconds to accept. Check your account settings and confirm it's in place.

For a broader overview of what DPAs require and how they work, see our DPA guide for website owners. For the specific question of EU-to-US data transfers via Google, see our EU-US Data Privacy Framework guide.

8. Additional Privacy-Relevant Settings

Reporting Identity

Where: Admin > Data display > Reporting identity

GA4 offers three reporting identity modes: Blended (uses User-ID, Google Signals, device ID, and modeling), Observed (User-ID, Signals, device ID without modeling), and Device-based (device ID only). Each mode changes how GA4 counts unique users and stitches sessions.

GDPR implication: Blended mode involves the most personal data processing, including modeled data from non-consenting users. Device-based is the most privacy-conservative option. If you've disabled Google Signals and don't use User-ID, switching to device-based reporting identity ensures your reports align with what you're actually collecting.

Product Links (Google Ads, Search Console, etc.)

Where: Admin > Product links

Each product link creates a data-sharing relationship. A Google Ads link enables audience sharing and conversion import. A Search Console link shares search query data. A BigQuery link exports raw event data. Each is a separate processing operation with its own disclosure requirements.

GDPR implication: Every active product link should be documented in your records of processing activities and disclosed in your privacy policy. Don't link services you aren't actively using. An active Google Ads link with ad_storage granted means advertising data flows whether you intended it to or not.

Unwanted Referrals and Internal Traffic Rules

Where: Admin > Data collection and modification > Data streams > [stream] > Configure tag settings

These aren't privacy settings per se, but they affect data accuracy, which in turn affects the personal data you hold. Misconfigured referral exclusions can inflate session counts, creating unnecessary duplicate records of user activity. Internal traffic filters prevent your team's visits from polluting analytics data, which is a data-minimization measure.

9. How CookieBeam Ensures GA4 Only Fires with Proper Consent

Every setting above is only as good as the gate that decides whether GA4 fires in the first place. If your analytics tag loads before consent is obtained, none of these configurations matter: you've already collected personal data without a lawful basis.

CookieBeam handles this at two levels:

Script blocking until consent. CookieBeam blocks GA4 tags (and all other non-essential scripts) from executing until the visitor makes a consent choice. This isn't a race condition: the tag doesn't load, then get suppressed. It doesn't exist in the DOM until consent is granted. No cookies are set, no network requests are made, no data leaves the browser. For a technical walkthrough of how this works, see our guide on how to block scripts until consent.

Consent Mode v2 signal management. CookieBeam sets all four Consent Mode v2 parameters (analytics_storage, ad_storage, ad_user_data, ad_personalization) to denied by default for visitors in regions that require prior consent (EEA, UK, and others configured in your regional rules). When a visitor consents, CookieBeam fires the gtag('consent', 'update', ...) call with the correct granted/denied state for each category they accepted or refused. When they refuse, the signals stay denied.

Regional defaults. CookieBeam's regional consent system adapts the default consent state based on the visitor's location. EEA visitors get denied defaults (opt-in). US visitors in states with opt-out laws get different treatment. Visitors in regions with no cookie law can get granted defaults. This means your Consent Mode signals are always legally appropriate for the visitor's jurisdiction, without manual per-region tag configuration.

The result: GA4 only collects data from visitors who've explicitly consented to it, the Consent Mode signals accurately reflect what was consented to, and the configuration happens once in your CookieBeam dashboard rather than being maintained across tag managers and site code.

Putting It All Together

GA4's privacy surface is wider than a single toggle or settings page. It spans data collection, retention, sharing, consent integration, deletion capabilities, export pipelines, and the legal contract underpinning all of it. Getting one right while ignoring the others leaves gaps, and DPAs and supervisory authorities look at the system as a whole.

The common failure mode isn't a single dramatically wrong setting. It's a combination of defaults that were never reviewed: 14-month retention nobody asked for, Google Signals left on by habit, data sharing enabled because it was pre-checked, a BigQuery export with no expiration policy, and a consent implementation that technically fires the right signals but doesn't actually block tags before consent. Each one is individually defensible as an oversight. Together they describe a property that isn't being managed with privacy in mind.

Run through the checklist above against every GA4 property you manage. Document what you find, record the justifications for settings you choose to keep, and put the audit on a quarterly cadence. The GDPR doesn't require perfection, but it does require you to demonstrate that you've thought about it. A completed audit with documented rationale is that demonstration.

For the related question of how consent choices affect your GA4 data quality, see our guide on how Consent Mode v2 affects GA4 reporting. For the consent infrastructure that makes all of this work, see our Consent Mode v2 implementation guide.