A Practical Overview - GDPR Web Analytics

A cookie banner does not make GDPR web analytics lawful: you still need a legal basis, ePrivacy compliance, real data minimisation, a defensible transfer story and clear information for visitors.

The issue became more visible after Schrems II, when the Court of Justice invalidated Privacy Shield and made organizations responsible for assessing third-country transfer risks (CJEU C-311/18). Several European regulators later found particular Google Analytics implementations unlawful because data was transferred to the United States without adequate safeguards, including the French CNIL's formal notice analysis (CNIL anonymized decision) and the Austrian DSB case summarized by noyb (Austrian DSB Google Analytics decision).

What compliant analytics must solve

A GDPR-ready setup needs answers to five questions.

What data is collected? IP addresses, cookie IDs, user IDs, device data, URLs, search terms, and event properties may be personal data.

Why is it collected? Define purposes such as performance measurement, content improvement, conversion tracking, or security. Avoid vague reuse.

What legal basis applies? Consent is often required for cookies and advertising trackers. Legitimate interests may be considered for low-risk first-party analytics, but it requires a balancing test and may not satisfy ePrivacy consent rules in every country.

Where does data go? Map processors, subprocessors, support access, logs, backups, and transfers.

How long is it retained? Raw event data should have a defined retention period.

Google Analytics risk areas

GA4 includes stronger controls than older Universal Analytics, and Google says GA4 does not log or store IP addresses (Google safeguards). But website owners still need to evaluate cookies, device data, Google Signals, advertising features, data sharing settings, Consent Mode, contracts, regional controls, and international transfers. The EU-US Data Privacy Framework may be relevant where a certified US recipient is involved, but it does not replace ePrivacy consent, minimization, transparency, or purpose-limitation work.

The main compliance mistake is treating Google Analytics as automatically legal or illegal in every situation. The right answer depends on configuration, country, transfer mechanism, consent behavior, and whether advertising features are enabled. For many privacy-first teams, the simpler choice is to avoid much of that complexity.

Safer analytics architecture

A privacy-first analytics stack includes:

• No third-party cookies.
• No cross-site tracking.
• No fingerprinting.
• No storage of full IP addresses.
• No personal data in event properties.
• EU or adequacy-country processing where possible.
• Aggregated reports by default.
• Short retention for raw events.
• A clear DPA and subprocessor list.

This does not exempt the organization from legal analysis, but it reduces risk and makes the analysis easier.

Practical setup checklist

1. Audit current scripts with browser dev tools.
2. Remove unused tags and pixels.
3. Decide which metrics are actually necessary.
4. Choose a tool that supports cookieless measurement.
5. Strip query parameters that can contain personal data.
6. Write an event naming policy.
7. Document legal basis and consent behavior by country.
8. Review data transfers and vendor contracts.
9. Set retention periods.
10. Update the privacy notice.

What to avoid

Avoid session replay on sensitive pages, collecting free-text inputs, sending logged-in user IDs to advertising platforms, enabling every "enhanced" measurement feature by default, and assuming anonymization when data is merely pseudonymous.

GDPR compliant analytics is mostly disciplined restraint. Measure the things that improve the website, not everything a browser can reveal.

Consent vs legitimate interests

Teams want a universal answer on whether analytics can run under legitimate interests. There is no universal answer. A first-party, cookieless, aggregate analytics setup used only to understand website performance is easier to justify in some jurisdictions. Analytics that sets identifiers, tracks users across sessions, shares data with advertising platforms, or enables profiling needs consent under ePrivacy rules and is harder to justify under GDPR legitimate interests.

Document your reasoning. If you rely on legitimate interests, keep a balancing test. If you rely on consent, make refusal as easy as acceptance and ensure tags do not fire before consent.

DPIA triggers

Consider a DPIA when analytics involves vulnerable people, sensitive pages, large-scale profiling, precise location, children's data, health or finance contexts, or cross-border transfers with high-risk vendors. A DPIA is not just a legal artifact; it forces the team to define whether the data is worth the risk.

A practical implementation example

For a typical SaaS marketing site, start by allowing only page views, referrers, UTM parameters, device class, country, and a small set of conversion events such as signup_started, demo_requested, and checkout_completed. Strip email addresses, account IDs, search text, and invite tokens from URLs before analytics sees them. Keep campaign parameters, but define an allowlist so accidental values such as ?email= or ?customer_id= are dropped.

Then test the implementation in a clean browser profile. Reject optional cookies, reload the site, and inspect Network and Application storage. The result should match the privacy notice and the legal basis you documented. If the browser still shows third-party calls or persistent identifiers, the compliance story is not finished.

Compliance Evidence To Keep

Keep an analytics evidence pack: event inventory, purpose for each event, storage and consent behavior by region, transfer mechanism, vendor contracts, retention settings, enabled advertising features, and screenshots or logs from browser testing. Treat GDPR wording as an implementation target, not a blanket legal conclusion about a tool name.

Then test the page in a clean browser profile and compare the result with the privacy notice. If the browser still shows unplanned third-party calls, persistent identifiers, or query-string data after rejection, the compliance story is unfinished.

Frequently Asked Questions

Does a cookie banner make Google Analytics GDPR compliant?

A banner alone does not establish a legal basis, satisfy ePrivacy rules, or account for data minimization and international transfers. The post treats a banner as one piece of a larger compliance picture that also includes contracts, retention periods, and clear information for visitors.

Is GA4 automatically illegal under GDPR?

No single answer applies. Whether GA4 is lawful depends on configuration, country, transfer mechanism, consent behavior, and whether advertising features like Google Signals are switched on.

Does GA4 store IP addresses?

Google states that GA4 does not log or store IP addresses, an improvement over Universal Analytics. That claim does not cover everything else worth reviewing: cookies, device data, Google Signals, advertising features, and international transfers still need evaluation.

Can legitimate interest replace consent for analytics cookies?

Legitimate interest can be considered for low risk, first-party analytics, but it requires a documented balancing test and can still fail ePrivacy consent rules depending on the country. Analytics that sets identifiers, tracks users across sessions, or shares data with advertising platforms usually needs consent instead.

What did the CNIL decide about Google Analytics?

The CNIL issued a formal notice analysis finding that a Google Analytics implementation transferred data to the United States without adequate safeguards. Its published decision is one of several European regulator findings that followed the Schrems II ruling.

Does the EU-US Data Privacy Framework fix analytics transfers?

The framework can be relevant when a certified US recipient is involved, but the post is explicit that it does not replace ePrivacy consent, minimization, transparency, or purpose limitation work. A certified transfer mechanism handles one piece of the compliance picture, not all of it.

What should trigger a DPIA for website analytics?

Consider a DPIA when analytics touches vulnerable people, sensitive pages, large scale profiling, precise location, children's data, health or finance contexts, or cross border transfers with high risk vendors. The post frames a DPIA as a way to force the team to decide whether the data is worth the risk, not just paperwork.

How long should raw analytics event data be kept?

The post calls for raw event data to have a defined retention period and for teams to set retention periods explicitly as part of the setup checklist. It doesn't prescribe a fixed number of days, since the right length depends on purpose and the earlier data minimization analysis.

What should be stripped from URLs before analytics sees them?

Strip identifying values such as email addresses, account IDs, search text, and invite tokens before analytics tools capture the page URL. The post also recommends an allowlist for campaign parameters so accidental values like ?email= or ?customer_id= get dropped automatically.

What belongs in an analytics compliance evidence pack?

Keep an event inventory, the purpose for each event, and storage and consent behavior by region. Add the transfer mechanism, vendor contracts, retention settings, enabled advertising features, and screenshots or logs from browser testing. The post treats this pack as proof that the configuration matches the privacy notice, not a one-time checklist.