GDPR

The General Data Protection Regulation (GDPR) is the European Union law that since 25 May 2018 has governed how organizations collect, store, and process the personal data of people in the EU and EEA. For anyone running Google Analytics 4, the central questions are concrete: is GA4 GDPR-compliant out of the box? What data does it actually collect? When is consent required, and what happens if a user denies it? This guide answers those questions, walks through Google Consent Mode v2, the GA4 privacy settings that matter, and the six data subject rights every site must honor.

What Is GDPR?

GDPR is a single regulation with extraterritorial reach: it applies to any organization processing the personal data of people physically in the EU/EEA, regardless of where the organization itself is located. A US-based SaaS with European users is bound by it. A German shop selling only to Germans is bound by it. The law was adopted in 2016 and became enforceable on 25 May 2018, replacing the older 1995 Data Protection Directive.

The core idea is straightforward. Personal data must be processed lawfully, fairly, and transparently. Users have rights over their data. Organizations must be able to demonstrate compliance. The penalty ceiling is high: up to €20 million or 4% of global annual turnover, whichever is greater. For analytics teams the practical question becomes which parts of GA4 trigger the regulation, and how to keep collecting useful measurement without overstepping.

The official text lives on gdpr-info.eu and the European Commission’s data protection portal. Both are worth bookmarking.

GDPR vs ePrivacy vs CCPA: Distinctions That Matter

People mix these three regimes constantly and they are not interchangeable. GDPR is broad and EU-wide. The ePrivacy Directive (and its planned successor, the ePrivacy Regulation) is a separate EU law focused specifically on electronic communications and, critically for our work, on cookies and tracking technologies. CCPA/CPRA is California’s state law with a different philosophy: opt-out rather than opt-in.

The practical sequence for a European site is: ePrivacy says you need consent before you set non-essential cookies. GDPR then governs what you do with the data once you have it. CCPA layers on if you also have California traffic, usually solved by a “Your Privacy Choices” link plus the same consent infrastructure. When I’ve set up tracking for businesses serving both markets, treating GDPR as the strictest baseline keeps everything else simpler.

GDPR and Web Analytics: What Counts as Personal Data

This is where most analytics teams stumble. GDPR’s definition of personal data is wide. It includes any information that can identify a natural person, directly or in combination with other data. That sweeps in IP addresses, device IDs, advertising IDs, and persistent first-party cookie identifiers like the GA4 _ga cookie holding a Client ID.

The European Court of Justice settled the IP question in Breyer v. Germany (2016): even dynamic IPs are personal data when the controller has reasonable means to identify the user. So when GA4 receives a hit, the IP, the Client ID stored in the cookie, the User-Agent string, and any user_id you send via the Measurement Protocol all qualify as personal data under the regulation.

• Definitely personal data: IP address, GA4 Client ID, user_id, device advertising ID, email/phone hashes used for Enhanced Conversions.
• Personal data in context: page URLs containing usernames, custom dimensions carrying CRM IDs, search queries entered into your site.
• Generally not personal data: aggregated session counts, event counts at the property level, country-level reporting.

The takeaway is simple. Almost every GA4 hit contains personal data. That means you need a lawful basis, transparency about what you collect, and respect for user rights. Aggregated reports and post-collection rollups are not personal data, but the act of collection is.

The 6 Lawful Bases for Processing Data

Article 6 of GDPR lists six lawful bases. You must pick one (and only one) for each processing purpose, document it, and disclose it in your privacy notice. For analytics, the realistic candidates are consent and, in some scenarios, legitimate interests.

1. Consent: freely given, specific, informed, unambiguous opt-in. The standard basis for GA4 with cookies.
2. Contract: processing necessary to perform a contract. Rare for analytics; common for order processing.
3. Legal obligation: required by law (tax records, fraud prevention).
4. Vital interests: protecting life. Not relevant here.
5. Public task: only for public authorities.
6. Legitimate interests: your or a third party’s interest, balanced against user rights. Possible for very lightweight analytics; CNIL has rejected it for GA4.

For GA4 specifically, every major EU supervisory authority (CNIL in France, the Garante in Italy, the DSB in Austria) has held that consent is required before GA4 cookies are set or events fire. Legitimate interests does not work for the standard GA4 deployment because of the data transfers and the granularity of identifiers involved. If you want to operate without consent, you need an alternative tool (Plausible, Matomo on-prem, or Simple Analytics) configured for cookieless aggregate measurement.

Is GA4 GDPR-Compliant? The CNIL/Austria/Italy Rulings

Short answer: GA4 is not automatically GDPR-compliant. It can be deployed compliantly, but only with a specific configuration plus a working consent management platform. Here is the regulatory record that shaped the current state of affairs.

• Austria (DSB), January 2022: first regulator to rule that the use of Google Analytics violated GDPR, specifically Article 44 transfers to the US under the previous Privacy Shield framework.
• France (CNIL), February 2022: issued a formal notice stating that GA usage as configured was unlawful, and published guidance on making analytics compliant via proxyfication or alternatives.
• Italy (Garante), June 2022: reached the same conclusion as France and Austria: GA in standard configuration breached GDPR.
• EU-US Data Privacy Framework, July 2023: the European Commission adopted an adequacy decision for the new framework, restoring legal grounds for transferring personal data to certified US companies, including Google.

What this means in 2025-2026: the transfer issue has eased thanks to the new framework, but the consent issue has not gone away. Every EU regulator still requires opt-in before GA4 fires. Google’s own answer to that requirement is Consent Mode v2, which is now mandatory for advertisers using Google Ads or audience features for EEA traffic.

Google Consent Mode v2: How It Works

Consent Mode v2 is Google’s mechanism for letting GA4 (and Google Ads) behave differently depending on whether the user has consented. It does not replace your cookie banner. Your cookie banner still has to capture the choice. Consent Mode is the wire that carries that choice into every Google tag firing on the page.

Consent Mode v2 introduces four signals that travel with every Google tag hit. The first two existed in v1. The last two are mandatory for v2:

• ad_storage: permission to set advertising cookies (Google Ads, remarketing).
• analytics_storage: permission to set analytics cookies, including _ga and _ga_<MID>.
• ad_user_data: permission to send user data to Google for advertising purposes.
• ad_personalization: permission to use the data for personalized advertising.

The flow has two modes. Basic Consent Mode: tags fire only after the user grants consent, meaning no Google data at all when denied. Advanced Consent Mode: tags fire immediately with all signals set to denied, sending cookieless pings (no cookies, no Client ID, IP truncated, ad-click info hashed). Google then uses conversion modeling to estimate the conversions you would have measured with full consent.

// Default state — denied before consent banner resolves
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

// Update after user clicks Accept
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'analytics_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

Advanced mode gives you ~30-50% more measurable conversions versus basic mode, in my experience implementing it across multiple e-commerce data stream setups, because you keep aggregate visibility even from non-consenters. The catch is regulatory acceptance: French CNIL and the EDPB have not formally blessed cookieless pings yet, so legal teams in stricter jurisdictions sometimes prefer basic mode. Confirm with your DPO before flipping the switch.

GA4 Privacy Settings: IP Anonymization, Data Retention, Regional Data

GA4 ships with several privacy controls. Some are on by default, some are not. Here is the configuration checklist I run through on every new EU property.

• IP anonymization is automatic. Unlike Universal Analytics where IP anonymization was an opt-in flag, GA4 never stores or logs the full IP. It uses IP only briefly to derive geolocation, then discards it. There is nothing to enable; it is the default and only mode.
• Data retention in Admin → Data Settings → Data Retention. Default is 2 months, extendable to 14 months. After this period, user-level and event-level data is deleted, though aggregated standard reports remain forever. For GDPR, 2 months is the minimum-data-retention answer; 14 months is acceptable if documented.
• Reset on new activity: keep this off. When on, every new event resets the retention countdown, effectively keeping data forever for active users.
• Regional data restrictions in data stream settings. You can block collection of granular geo and device data for specific regions, useful if you want to keep continent-level traffic but skip city/precision-device for EU traffic.
• Google signals: cross-device tracking using signed-in Google account data. Off by default and should stay off for EU traffic without explicit opt-in.
• Account-level data sharing: there are four toggles (Google products & services, modeling & business insights, technical support, account specialists). Default-off for EU is the safer choice; review with legal.

Data Subject Rights: Access, Erasure, Portability, Objection

Articles 15-21 of GDPR grant six rights to every EU user whose data you process. These rights apply to the data sitting in your GA4 property, your Measurement Protocol ingestion endpoint, and any BigQuery export. You need a process to honor each one within the response window.

For the analytics-relevant rights:

• Access (Art. 15): give the user a copy of their data. In GA4, the User Explorer report lets you find all events tied to a Client ID; export them to CSV. Better still, if you have BigQuery export turned on, query events_* tables filtered by user_pseudo_id or user_id.
• Erasure (Art. 17): the most operational right. GA4 has a built-in Data Deletion Requests tool in Admin → Property Settings. Submit the user’s identifier (Client ID, user_id, App Instance ID) and Google deletes the matching events. Deletion completes within 63 days. For BigQuery, you delete the rows yourself.
• Portability (Art. 20): provide data in a structured, machine-readable format. JSON or CSV from User Explorer, or a BigQuery query result.
• Objection (Art. 21): stop processing when the user objects. In practice this means honoring the opt-out via the consent banner and never sending events for that Client ID again.

Acknowledge requests within 72 hours. Fulfill within 30 days (extendable to 90 for complex cases, with notification to the user). Free of charge except for clearly excessive requests. Keep a register. When CNIL or the ICO audit you, the first thing they ask for is your DSR log.

Frequently Asked Questions

Related Terms

• Cookie: what GDPR’s “non-essential cookies” actually means
• Cookie Banner: the consent capture UI
• First-Party Cookie: why GA4 cookies are first-party but still need consent
• Measurement Protocol: server-side ingestion that bypasses the browser
• Events: the unit of measurement in GA4
• Data Stream: where regional data restrictions are configured
• Cookieless analytics strategies: practical alternatives when consent rates are low