GDPR-Compliant Analytics Without US Data Transfers (2026 Guide)

Last checked: October 27, 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 one of the most used and least explained phrases in analytics marketing. Vendors claim 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.

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 (personal data in many cases, as the CJEU held in Breyer in 2016), 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: writing nothing to the device is not enough, because reading information from the browser is covered too. What can avoid the consent requirement is a narrow exemption for limited audience measurement, which several regulators maintain under conditions; France's CNIL requires anonymous statistics only, no tracking across sites, no combination with other processing and no sharing with third parties, which in practice also rules out campaign and sales linking.

One consequence that vendors rarely spell out, so we will: the exemption covers a mode, not a product. A simple measurement mode, with no device storage, no campaign parameters, no sales linking 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 an easy way for a site to walk 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 means you can skip consent, 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 compliance layer that settings alone do not fix. IP anonymization settings were found insufficient in the 2022 decisions, and the one workaround the CNIL described, a proxy that strips identifiers before anything reaches the vendor, comes with strict conditions. The answers that hold best 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):

Does it set cookies or read device storage? (DevTools → Application → Cookies/Storage)
Does it collect IP addresses, and are they stored or truncated?
Is data processed by a US-owned company? Under which transfer mechanism?
Do you have a signed DPA? A retention period?
If a regulator asked why this measurement runs without consent, do you have a written answer?
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: country, region and city, 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: country, region and city, then discarded). Uniqueness within a day comes from a server-side hash of the date, a secret, the site, the IP and the user agent: the date changes every day, which is what makes following the same person from one day to the next impossible, for us too. The script still reads standard browser information (language, screen size, referrer), so the law on trackers applies: before a visitor's consent, a site can run Simple measurement only, and everything that ties a visit to a sale, a campaign or a person waits for that consent. Customers can opt into a Persistent layer that stores a pseudonymous first-party identifier for 90 days, only after the visitor's consent. We run that layer on datalenk.com ourselves, behind a consent banner, 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 date in the hash changes every day 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, A/B tests) are outside the audience-measurement exemption by construction, which is why they are off unless you turn them on, and why even then they wait for each visitor's consent.

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 position depends on that framework surviving its CJEU appeal ↗; several EU regulators found its transfers unlawful in 2022, when there was no framework in place.

Does cookieless analytics need a cookie banner? Not automatically. Reading information from the browser falls under the same rule as cookies, so a cookieless tool still needs your visitors' consent unless its use stays inside the narrow exemption for limited audience measurement that regulators like the CNIL maintain. 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.