A Practical Guide to gdpr compliant web analytics

In practice, gDPR compliant web analytics is possible, but it requires more than adding a cookie banner. The analytics setup must have a legal basis, respect ePrivacy rules, minimize personal data, handle transfers lawfully, and give users clear information.

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 usually 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 may 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 often 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 may be easier to justify in some jurisdictions. Analytics that sets identifiers, tracks users across sessions, shares data with advertising platforms, or enables profiling usually needs consent under ePrivacy rules and may be 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.