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.

One consequence that vendors rarely spell out, so we will: the exemption covers a mode, not a product. A cookieless default mode, with no device storage and no cross-site tracking, is designed to fall inside it. The deeper features that the same tool may offer, a persistent visitor identifier, cross-device identity, session replay, do not, and they have to be treated as ordinary processing with the consent and disclosure that implies. Turning one of them on quietly, because the vendor's homepage said "no cookies", is the single most common way a site walks out of the exemption without noticing. And note who pays for that: enforcement in this area lands on whoever operates the site. In the 2022 transfer rulings it was the websites that received the orders, not the tool maker, and cookie sanctions work the same way. When your analytics setup is wrong, it is your name on the decision, not your vendor's.

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 not arrive at one setting. You would arrive at layers, with the shallowest one as the default:

• The default layer does the least it can. Nothing written to or read from the device (no ePrivacy trigger), no raw IP stored (an IP is used in memory to derive a coarse location, then discarded), no cross-site tracking, no identifier that survives the day. It answers the questions most teams actually have: where traffic comes from, what converts, which channel produced revenue.
• The deeper layers are opt-in, one by one, and consented. Returning visitors need a persistent identifier. Cross-device lifetime value needs an identity. Behavioural debugging needs replay. Each of these is a real capability and each one is a real processing decision: it should take a deliberate action to enable, it should be disclosed to visitors, and it should carry consent where your jurisdiction requires it.
• Around both: EU-owned infrastructure (no transfer question), first-party collection (resilient and transparent), and data export you can run yourself (no lock-in when a court moves).

That layered brief is what Datalenk was built against, France-based and EU-hosted. 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. Several good EU tools follow the same brief ↗. Check the architecture.

Show, not claim: how our default layer actually works

This article told you to make vendors show rather than claim, so here is ours, in enough detail to check it.

How Datalenk actually works, so you can hold us to it. Datalenk is cookieless by default: the standard snippet writes nothing to the visitor's device, no cookie and no localStorage, and no raw IP is ever stored (it is used in memory to derive a coarse location, then discarded). Uniqueness within a day comes from a server-side hash of the site, the IP and the user agent, salted with a secret that rotates every 24 hours, which is what makes following the same person from one day to the next impossible, for us too. Customers can explicitly opt into a Persistent layer that stores a pseudonymous first-party identifier for 90 days, which brings the consent question back: our dashboard makes them tick a box that says so before it turns on. We run that layer on datalenk.com ourselves, and we disclose it in our own privacy policy.

Two things follow from that, and we would rather say them than have you find them in DevTools. First, the daily salted hash is a fingerprinting-adjacent technique in the literal sense: it derives a value from the IP and the user agent. What keeps it inside the "audience measurement" reasoning rather than outside it is that the salt rotates every 24 hours and the hash is never joined across sites, so it cannot follow a person over time or across the web. Ask any cookieless vendor to explain exactly that mechanism, including us; the answer is where a good tool separates from a badge. Second, our deeper layers (persistent identifier, identity, replay) are outside the audience-measurement exemption by construction, which is why they are off unless you turn them on and confirm you understand what changes for your visitors.

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. Check the wording too: "cookieless" and "cookieless by default" are different products. If the tool offers a persistent-identifier mode, enabling it puts you back in banner territory, whatever the homepage says.

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 and EU-hosted, cookieless by default, no raw IPs stored, no identifier that survives the day, any deeper layer left off unless you have deliberately turned it on and disclosed it, and your reasoning written down. It also happens to be the setup that carries no banner friction on the measurement layer and loses no data to consent refusals.