Web analytics sits in an uncomfortable position for GDPR compliance: it is nearly universal, often treated as a default, and increasingly scrutinised by European data protection authorities. Understanding what GDPR actually requires for analytics — not what vendors claim — lets you make defensible decisions about your stack.
This guide covers the legal requirements, what to ask your analytics provider, and how tool architecture affects your obligations. It does not constitute legal advice.
Quick answer
GDPR applies to web analytics because analytics tools typically process personal data — IP-derived session identifiers, geolocation inferences, and device attributes are all personal data under EU law. The core requirements are: a valid lawful basis for processing, a data processing agreement with your analytics provider, data minimisation (collect only what you need), restrictions on transfers outside the EU, and the ability to respond to data subject rights requests. EU-hosted analytics with no persistent identifiers, no cross-site tracking, and no IP storage reduces the surface area of these obligations — but does not eliminate them entirely. Atriqo does not make your site GDPR-compliant; it reduces analytics-specific friction. Consult a qualified legal professional for your specific situation.
Key takeaways
- GDPR applies to analytics because IP addresses, browser fingerprints, and session identifiers are personal data under Article 4(1) GDPR, even when not directly tied to a name.
- You need a lawful basis for analytics processing. For most EU commercial sites, this is either consent (Article 6(1)(a)) or legitimate interest (Article 6(1)(f)) — the correct choice depends on your tool's architecture and the guidance of your data protection authority.
- You must have a Data Processing Agreement (DPA) with your analytics provider, because the provider processes personal data on your behalf (Article 28 GDPR).
- Data transfers to analytics providers outside the EU require appropriate safeguards (Chapter V GDPR). Multiple European DPAs found specific uses of Google Analytics unlawful on this basis in 2022–2023.
- Data minimisation (Article 5(1)(c)): collect only what is necessary. Tools that discard raw IPs, use short-lived identifiers, and avoid persistent browser storage reduce the personal data footprint.
- Data subject rights apply to analytics data when individuals can be identified or re-identified. The ability to delete or export a specific visitor's data depends on your tool's architecture.
Definitions
Personal data (GDPR Art. 4(1)): any information relating to an identified or identifiable natural person. IP addresses are personal data (WP29 Opinion 4/2007; confirmed by CJEU in Breyer case C-582/14 (2016)). Pseudonymous identifiers (hashes derived from IP + user agent) are also personal data because re-identification, even if difficult, is not impossible.
Data Processing Agreement (DPA): a contractual document required by Article 28 GDPR when a controller (your organisation) engages a processor (your analytics provider) to process personal data on its behalf. It must specify subject matter, duration, nature and purpose of processing, type of data, and obligations and rights of the controller.
Data minimisation: the principle (Article 5(1)(c)) that personal data must be adequate, relevant, and limited to what is necessary in relation to the purposes for which it is processed. In analytics terms: do not collect raw IPs if a hash suffices; do not retain granular event logs for two years if 90-day aggregate retention meets your needs.
Standard Contractual Clauses (SCCs): the primary mechanism for lawful EU-to-third-country data transfers post-Schrems II (European Commission SCCs, adopted 2021). SCCs alone are not sufficient if the transfer destination has laws that override them in practice — a Transfer Impact Assessment (TIA) is required.
GDPR-native by design: a product positioning claim (not a compliance certification) meaning the tool was designed from the ground up around EU data protection principles, rather than retrofitting consent mitigations onto a tracking-first architecture.
Requirement 1: Lawful basis for analytics processing
GDPR Article 6 requires a lawful basis for every processing activity. For web analytics, the two relevant options are:
Consent (Article 6(1)(a)): the visitor explicitly agrees, prior to data collection, to analytics processing. Required when your analytics tool uses cookies, persistent identifiers, or fingerprinting — because those operations also trigger Article 5(3) of the ePrivacy Directive, which mandates consent independently of GDPR.
Legitimate interest (Article 6(1)(f)): you have a legitimate interest in understanding how visitors use your site, and that interest is not overridden by the visitor's rights. This basis is available where the analytics processing is proportionate and the visitor would reasonably expect it. It requires a documented Legitimate Interest Assessment (LIA). Note: the Article 29 Working Party (now EDPB) has expressed caution about relying on legitimate interest for behavioural tracking; the strength of the basis depends heavily on how the tool operates.
What to ask your provider: What lawful basis does your DPA template assume? Does your tool architecture support legitimate interest (i.e. is it cookieless, no persistent identifiers, no cross-site tracking), or does it require consent?
Requirement 2: Data Processing Agreement
Article 28 GDPR requires a written DPA with any analytics provider that processes personal data on your behalf as a processor. The DPA must include:
- Subject matter, duration, nature, and purpose of processing
- Type of personal data and categories of data subjects
- Obligations and rights of the controller (you)
- Subprocessor authorisation and notification requirements
- Security measures and breach notification obligations
- Assistance with data subject rights requests
- Return or deletion of data at contract end
What to ask your provider: Do you offer a DPA? Is it available without a paid plan or enterprise tier? Does it cover all your subprocessors (infrastructure, email, error tracking, etc.)?
For reference, Atriqo's subprocessor chain includes: Hetzner (analytics infrastructure, Germany), Stripe (billing), Brevo (transactional email, EU-hosted), Sentry (error tracking, EU DSN), Cloudflare (DNS only, no proxy), and MaxMind GeoLite2 (IP-to-country lookup; IP is never stored or transmitted to MaxMind — the lookup is local).
Requirement 3: Data minimisation in practice
Article 5(1)(c) GDPR requires that personal data be "adequate, relevant and limited to what is necessary". For analytics, this principle applies at three layers:
Collection: does the tool need raw IP addresses? If session identification can be achieved with a cryptographic hash that discards the IP immediately (as Atriqo does: HMAC(secret, IP + user_agent + daily_salt), IP discarded after hashing), storing the raw IP is not necessary.
Retention: how long do you keep event-level data? Retaining detailed page-level event logs for two years typically cannot be justified for basic audience measurement. Aggregate counts at weekly or monthly granularity are sufficient for trend analysis and carry less GDPR risk.
Granularity: do you need individual session-level data, or are aggregate counts sufficient for your use case? Tools that store per-visit event streams create a richer personal data set than tools that count page views at the aggregate level.
What to ask your provider: What raw data fields are stored at event time? Is the IP address stored? Are user agent strings stored verbatim? What is the default and configurable retention period? Can you delete data for a specific visitor or time window?
Requirement 4: Transfers outside the EU
Chapter V of GDPR restricts transfers of personal data to countries outside the EU/EEA unless appropriate safeguards are in place. For analytics, this is the mechanism behind the 2022–2023 European DPA decisions about Google Analytics.
The decisions: data protection authorities in Austria (DSB Decision D-B 2021.0573, January 2022), France (CNIL formal notice, January 2022), Italy (Garante Order, June 2022), and others found that specific uses of Google Analytics resulted in personal data (IP addresses, unique identifiers) being transferred to Google's US servers, and that the SCCs in place were insufficient given US surveillance law. These are findings about specific configurations — not a categorical ban — but they illustrate the compliance exposure of using analytics infrastructure outside the EU.
How EU hosting reduces this exposure: when analytics infrastructure is hosted entirely within the EU, the Chapter V transfer question does not arise for the analytics data. Data collected in the EU stays in the EU. This does not eliminate all GDPR obligations — you still need a lawful basis, a DPA, and data minimisation practices — but it removes one of the most actively enforced compliance vectors.
What to ask your provider: Where exactly is analytics data stored? Is the answer in a specific country and specific data centre, or vague ("EU regions")? Is the parent company subject to non-EU government data access laws (e.g. the US CLOUD Act)? What SCCs or transfer mechanisms apply if any subprocessor is outside the EU?
Requirement 5: Data subject rights
GDPR Articles 15–22 grant individuals rights over their personal data, including the right of access (Article 15), erasure (Article 17), and objection (Article 21). For analytics, these rights apply when the data allows identification or re-identification of the individual.
When erasure is difficult: tools that store event-level data with persistent user identifiers (cookies, fingerprints) can be asked to delete all records associated with a specific user. Complying requires the tool to support deletion by user ID or cookie value.
When erasure is less operationally complex: tools that use daily-rotating hashes without persistent identifiers cannot link records to a specific individual across days. An erasure request for "visitor X" cannot be fulfilled with precision because the identifier changes daily and is not reversible to an IP. This reduces operational complexity — but it also means the tool cannot fulfil a Subject Access Request with individual-level granularity, which may itself require a disclosure in your privacy policy.
What to ask your provider: Does your tool retain any data that could be linked to a specific individual over time? What is the procedure for responding to a Subject Access Request? Can data be deleted by visitor or by date range?
Requirement 6: Records of processing activities
Article 30 GDPR requires controllers to maintain written records of processing activities. For an analytics tool, this record should include:
- Name and contact of the controller and DPO (if applicable)
- Purpose of processing (audience measurement, performance analysis, etc.)
- Categories of data subjects (website visitors)
- Categories of personal data (session identifiers, device attributes, geographic region, page URLs visited)
- Recipients (your analytics provider and their subprocessors)
- Third-country transfers (if any) and safeguards
- Retention periods
- Security measures (at a high level)
What to ask your provider: Do you provide documentation suitable for a Record of Processing Activities? Does your DPA template or privacy policy documentation map to the Article 30 requirements?
Summary table: GDPR requirements for web analytics
| Requirement | Key question for your provider | Reduced by privacy-first architecture? |
|---|---|---|
| Lawful basis (Art. 6) | Does your tool require consent, or can legitimate interest apply? | Yes — no cookies / no persistent IDs supports legitimate interest |
| Data Processing Agreement (Art. 28) | Is a DPA available? Does it cover all subprocessors? | No — DPA required regardless |
| Data minimisation (Art. 5(1)(c)) | Is raw IP stored? What is the retention period? | Yes — IP discard + short-lived hashes reduce data footprint |
| EU transfers (Ch. V) | Where is data stored? Is the parent company subject to non-EU law? | Yes — EU-hosted analytics removes the transfer question for analytics data |
| Data subject rights (Arts. 15–22) | Can you delete data for a specific visitor? Can you fulfil a SAR? | Partially — daily-rotating hashes limit individual re-identification |
| Records of processing (Art. 30) | Can you provide documentation for an Article 30 record? | No — documentation required regardless |
What a privacy-first analytics tool changes in this picture
Atriqo is a privacy-first, cookieless web analytics tool, hosted in the EU (Germany), built as a GDPR-native-by-design alternative to Google Analytics.
Using a tool with the following properties reduces — but does not eliminate — the GDPR surface area for analytics:
- No cookies, no persistent browser identifiers: designed to avoid the classic ePrivacy Article 5(3) consent trigger (jurisdiction-dependent — see our cookie banner guide for the EDPB Guidelines 2/2023 nuance) and supports a legitimate interest basis under GDPR.
- IP discarded after privacy hash: reduces the personal data set stored at event time. The hash is pseudonymous; the raw IP is never written to disk.
- No cross-site tracking: each site's data is siloed. No visitor data is combined or reported across different websites.
- No fingerprinting: no browser attribute combination to create a persistent cross-session identifier.
- Hosted in the EU (analytics infrastructure in Germany — Hetzner, Falkenstein): removes the Chapter V transfer question for analytics data.
What a privacy-first architecture does not change:
- A DPA is still required. Atriqo processes personal data (pseudonymous session identifiers) on your behalf. Article 28 applies.
- GDPR still requires a lawful basis. Cookieless architecture supports a legitimate interest basis — it does not make a lawful basis unnecessary.
- Your privacy policy must describe the analytics processing. Visitors have a right to know what data is collected and for what purpose, regardless of the architecture.
- Data subject rights obligations remain. The architecture limits what can be retrieved or deleted with individual precision — that limitation itself must be disclosed accurately.
- Other vendors on your site carry independent obligations. Analytics is one processing activity among many. Ad pixels, social embeds, CRM integrations, and support chat tools each carry their own GDPR requirements.
For Atriqo's technical methodology, see our privacy documentation.
Facts vs interpretation
Documented facts: GDPR Article 4(1) defines personal data broadly. The CJEU confirmed IP addresses are personal data in Breyer (C-582/14, 2016). Austrian, French, and Italian DPAs issued decisions finding specific uses of Google Analytics created unlawful EU-US transfers in 2022–2023 (sources cited above). Article 28 GDPR requires a DPA with processors. Chapter V restricts data transfers outside the EU/EEA. Standard Contractual Clauses adopted June 2021 are the current primary transfer mechanism.
Our interpretation: that a cookieless, EU-hosted analytics tool with IP discard and no persistent identifiers reduces GDPR compliance friction for the analytics layer is Atriqo's commercial position. Whether that reduction is sufficient for your compliance programme, and whether legitimate interest applies in your specific context, are legal questions that depend on your jurisdiction, your full data processing activities, and the guidance of a qualified legal professional. This article is not legal advice.
Getting started with Atriqo
The free tier — 10,000 billable events per month (a billable event is any tracked event: pageview, outbound click, file download, 404, or custom event), no credit card required, no expiry — is available at launch.
If you want early access, join the waitlist.
This article is for informational purposes only and does not constitute legal advice. GDPR compliance depends on your full data processing activities, your jurisdiction, and the published guidance of the data protection authorities applicable to your organisation. Consult a qualified legal professional for advice specific to your situation.