GDPR-Compliant Analytics: What It Actually Requires (and How to Get There Without US Data Transfers)

Last updated: June 2026. This is a practical guide, not legal advice. For binding answers, talk to a lawyer; for a faster setup that minimizes the questions a lawyer needs to answer, read on.

"GDPR compliant" is the most abused phrase in the analytics market. Every vendor claims it, few explain what it means, and the explanations that exist tend to be either lawyer-grade unreadable or vendor-grade oversimplified. This guide takes the middle path: what the rules actually require from web analytics, in plain language, with the reasoning visible so you can check it.

The four questions GDPR asks your analytics

1. Are you processing personal data?

GDPR applies to personal data: anything that can identify a person directly or indirectly. For analytics, the usual suspects are IP addresses (explicitly personal data under EU case law), cookie IDs and device fingerprints, and user IDs you attach yourself.

This is the most underused lever in the whole discussion. An analytics tool that never stores IPs, sets no identifiers, and aggregates everything has a radically smaller GDPR surface than one that builds visitor profiles. Not zero (the collection moment still counts and pseudonymized data can still be personal data) but the difference between "we process personal data, here is our whole apparatus" and "our analytics is designed to avoid it" is the difference between a compliance project and a paragraph in your privacy policy.

2. Do you need consent? (the cookie banner question)

Two separate laws get mixed up here, and the distinction is the answer:

• GDPR governs the processing of personal data and offers several legal bases, of which consent is only one (legitimate interest is another).
• The ePrivacy rules (implemented nationally, like France's article 82 or the UK's PECR) govern storing or accessing information on the user's device: cookies, localStorage, and similar. That storage/access generally requires consent unless it is strictly necessary for the service.

So the honest version of the famous claim: a tool that stores nothing and reads nothing on the device avoids the ePrivacy consent trigger for analytics, which is the trigger that built the cookie banner industry. Several regulators (notably France's CNIL) also maintain explicit exemptions for limited audience measurement under conditions: aggregate-only output, no cross-site tracking, no data reuse.

The dishonest version is "cookieless = no banner needed, guaranteed, everywhere": interpretations differ between member states, fingerprinting-adjacent techniques are explicitly targeted by regulators, and vendor marketing is not case law. What a well-designed cookieless tool gives you is a strong, documented, good-faith position, not magic immunity. That is also why this article says "GDPR-friendly by design" and never "100% compliant out of the box": anyone selling the second phrase is selling something.

3. Where does the data go? (the transfers question)

Personal data leaving the EU needs a legal basis: an adequacy decision (like the EU-US Data Privacy Framework), Standard Contractual Clauses, or derogations. This is the layer with the turbulent history: the frameworks covering US transfers have been invalidated twice (2015, 2020), each invalidation made US analytics tools the immediate enforcement target ↗, and the current framework is under appeal at the CJEU right now ↗.

The strategic insight: transfers are the only compliance layer you cannot fix with configuration. Anonymization settings and proxies have already been rejected by regulators as insufficient for US tools in the 2022 rulings. The only answers that hold are: data that never leaves EU jurisdiction ↗, or data that is not personal in the first place. Both at once is better.

4. Can you demonstrate it? (accountability)

GDPR is an evidence regime. The practical artifacts for analytics: the tool listed in your records of processing, a data processing agreement (DPA) with the vendor, retention periods defined, and your privacy policy describing what is measured. Good vendors hand you most of this; the audit below tells you whether yours did.

The 10-minute audit of your current setup

Answer honestly for each analytics-adjacent tool on your site (analytics, heatmaps, session replay, A/B testing):

1. Does it set cookies or read device storage? (DevTools → Application → Cookies/Storage)
2. Does it collect IP addresses, and are they stored or truncated?
3. Is data processed by a US-owned company? Under which transfer mechanism?
4. Do you have a signed DPA? A retention period?
5. If a regulator asked "why no consent banner for this", do you have a written answer?
6. Could you export everything and leave in a week if a court ruling forced you to?

Scores of 6/6 are rare, and questions 3 and 6 are where US-tool setups usually fail.

The architecture that makes the questions easy

If you were designing analytics for GDPR from scratch in 2026, you would arrive at: no cookies or device storage (no ePrivacy trigger), no stored IPs or persistent identifiers (minimal personal data), aggregate reporting, EU-owned infrastructure (no transfer question), first-party collection (resilient and transparent), with a DPA and data export built in.

That is the design brief Datalenk was built against, France-based and EU-hosted, and the same brief several good EU tools follow ↗. The point of this guide is not that you must pick ours: it is that the architecture, not the marketing page, is what makes an analytics tool defensible. Check the architecture.

FAQ

Is Google Analytics GDPR compliant in 2026? It is lawful to use under the Data Privacy Framework, with proper configuration, DPA and disclosures. Its compliance position depends on that framework surviving its CJEU appeal (decision expected 2027-2028); it was found unlawful by multiple EU regulators in 2022 when the previous framework lapsed.

Does cookieless analytics need a cookie banner? If the tool genuinely stores and reads nothing on the device, the ePrivacy consent trigger for analytics does not apply, and regulators like CNIL maintain exemptions for limited audience measurement. Conditions apply, member-state interpretations vary, and fingerprinting workarounds void the reasoning: ask the vendor to show, not claim.

Is anonymized analytics data still personal data? Truly anonymous data (no way back to a person) is outside GDPR. Pseudonymized data (an ID without a name) is still personal data. Much of the dispute in practice is which side of that line a vendor's "anonymization" actually falls on.

What is the safest analytics setup under GDPR? EU-owned, EU-hosted, cookieless, no stored identifiers, aggregate reporting, signed DPA, with your reasoning documented. It also happens to be the setup that needs no banner friction and loses no data to consent refusals.