GDPR enforcement is not slowing down. In 2025 alone, EU data protection authorities issued over 2 billion euros in fines, with analytics and tracking violations accounting for a significant share. The message is clear: if you operate in the EU or serve EU users, the way you collect and process analytics data matters — legally, financially, and reputationally.
This guide covers what GDPR requires from analytics tools, why commonly used solutions remain problematic, and how to build an analytics stack that gives you the insights you need without the compliance risk.
What GDPR Requires from Analytics Tools
The General Data Protection Regulation is not a checklist you complete once. It is a framework of principles that apply to every piece of personal data you process. For analytics, five requirements matter most.
Lawful Basis for Processing
You need a legal reason to collect analytics data. The two most relevant bases are consent (Article 6(1)(a)) and legitimate interest (Article 6(1)(f)). Consent must be freely given, specific, informed, and unambiguous — which means pre-checked boxes and cookie walls that block content do not qualify. Legitimate interest requires a balancing test: your interest in analytics must not override the user's right to privacy. Most DPAs have ruled that detailed behavioral analytics (session replay, heatmaps, individual user tracking) require consent, while basic aggregate page view counting may qualify under legitimate interest.
Consent Management
If you rely on consent, you must obtain it before collecting data, not after. Users must be able to withdraw consent as easily as they gave it. You must keep records of when and how consent was obtained. And you must respect the user's choice — no analytics scripts should fire before the user actively opts in. Any analytics tool that starts collecting data on page load and only checks consent status later is non-compliant by default.
Data Minimization
Article 5(1)(c) requires that you collect only the data that is adequate, relevant, and limited to what is necessary. For analytics, this means you should not collect full IP addresses when anonymized IPs serve the same purpose. You should not record form inputs when you only need to know which fields cause abandonment. You should not store session recordings indefinitely when 30 days of data answers all your questions. Every data point you collect is a data point you must protect, justify, and potentially delete.
Right to Erasure
Article 17 gives users the right to have their personal data deleted. If a user contacts you and requests deletion, you must be able to find and remove their data from your analytics system. This is straightforward if your analytics tool supports user-level data access and deletion. It becomes a compliance nightmare if your data is siloed across multiple third-party tools, each with different retention policies and deletion mechanisms.
Data Processing Agreements
When you use a third-party analytics tool, that vendor is a data processor under GDPR. Article 28 requires a written contract (a Data Processing Agreement, or DPA) that specifies what data is processed, how, for how long, and what happens when the relationship ends. The DPA must also address sub-processors — other companies that your analytics vendor shares data with. If your analytics vendor cannot provide a GDPR-compliant DPA, or if their DPA references dozens of sub-processors in jurisdictions without adequate data protection, you have a problem.
Why Google Analytics Remains Problematic
Google Analytics is the most widely used analytics platform in the world. It is also the subject of more GDPR enforcement actions than any other analytics tool. Understanding why helps clarify what compliant analytics actually requires.
The Schrems II Problem
The core issue is data transfers. Google Analytics sends user data to servers in the United States. The Schrems II ruling (2020) invalidated the EU-US Privacy Shield, meaning there is no blanket adequacy decision that makes these transfers automatically lawful. The EU-US Data Privacy Framework, adopted in 2023, provides a mechanism for certified US companies, but its long-term stability remains uncertain. Legal scholars and privacy advocates have already mounted challenges, and the European Data Protection Board has signaled ongoing scrutiny.
For companies that need long-term compliance certainty, relying on a framework that could be invalidated — again — is a strategic risk. Several EU data protection authorities, including those in Austria, France, Italy, and Denmark, have explicitly ruled that using Google Analytics in its standard configuration violates GDPR.
Data Collection Scope
Google Analytics collects more data than most teams realize. Beyond page views and events, it sets cookies that persist across sessions, collects device fingerprinting data, and in its default configuration captures full IP addresses before anonymization occurs on Google's servers. Google's own privacy policy states that data collected through Google Analytics may be used to improve Google's products and services — a purpose that goes well beyond what most site operators communicate in their privacy notices.
DPA Enforcement Trends
The trend across EU member states is clear: data protection authorities are treating analytics data transfers to the US as high-priority enforcement targets. The fines are not hypothetical. The Austrian DSB, the French CNIL, the Italian Garante, and the Danish Datatilsynet have all issued binding decisions against specific companies for their use of Google Analytics. These decisions establish precedents that apply to all companies in those jurisdictions, not just the ones that were investigated.
3 Approaches to GDPR-Compliant Analytics
There is no single correct approach to GDPR-compliant analytics. The right choice depends on what data you need, how much engineering effort you can invest, and how conservative your risk tolerance is.
1. Cookie-Free Analytics
The simplest path to compliance is to avoid personal data collection entirely. Cookie-free analytics tools count page views, referrers, and basic session metrics using techniques that do not create persistent identifiers. No cookies, no IP address storage, no cross-session tracking. Because no personal data is processed, GDPR's consent requirements do not apply. The trade-off is that you lose the ability to track individual user journeys, measure returning visitors, or build cohort analyses. For content sites, blogs, and marketing pages, cookie-free analytics provide sufficient insight. For product teams that need behavioral data, session replay, or form analytics, they fall short.
2. Consent-Based Analytics
Consent-based analytics collect behavioral data — including session replay, heatmaps, and individual user journeys — but only after obtaining explicit user consent. This approach is fully GDPR-compliant when implemented correctly. The key is that your analytics tool must support true consent gating: no data collection of any kind before the user actively opts in.
The trade-off is sample size. Consent rates for analytics typically range from 30% to 60%, depending on your audience and how you present the consent dialog. You get rich behavioral data, but only from users who consent. For most product teams, a 40% sample of detailed behavioral data is more valuable than 100% coverage of basic page views.
Consent-based analytics work best when paired with two consent modes: opt-in for markets where consent is required (EU, UK), and opt-out for markets where implied consent is acceptable (parts of the US, non-regulated contexts). This gives you maximum data coverage within the legal requirements of each market.
3. Self-Hosted Analytics
Self-hosting eliminates the data transfer problem entirely. When your analytics data never leaves your own infrastructure, there is no third-party processor, no cross-border data transfer, and no sub-processor chain to audit. You control the data, the retention periods, the deletion processes, and the security measures. This is the most conservative approach from a compliance perspective.
Self-hosting does require engineering capacity to deploy and maintain the infrastructure. However, modern containerized analytics platforms have reduced this burden significantly. A Docker deployment with PostgreSQL, Redis, and an application server can be running in under 10 minutes and maintained with minimal ongoing effort.
10 Questions to Ask Your Analytics Vendor
Before committing to an analytics platform, run through this checklist. The answers will tell you whether the tool can support your compliance requirements or whether you are inheriting risk.
- Where is user data stored? Look for EU-only data residency or, better, self-hosting options. US-based storage introduces transfer risk.
- Does the tool support true consent gating? Data collection must stop completely when consent is not given — not just cookie setting, but all data transmission.
- What personal data is collected by default? Full IP addresses, device fingerprints, persistent identifiers — each one adds compliance burden.
- Can users be identified across sessions? Cross-session tracking typically requires consent. Know whether it is on by default and whether it can be disabled.
- Is there a GDPR-compliant DPA available? Read it. Check the sub-processor list. Verify that data use is limited to providing the service, not improving the vendor's other products.
- How does the tool handle right-to-erasure requests? You need the ability to find and delete a specific user's data on request. If this requires a support ticket and a 30-day wait, that is a problem.
- What is the data retention policy? Shorter is better for compliance. Look for configurable retention periods that you control.
- Does the vendor use the collected data for their own purposes? If yes, you need to disclose this in your privacy notice, and it may undermine your lawful basis.
- Can PII be automatically detected and masked? Session replay and form analytics can capture sensitive data. Automatic PII detection is a safety net, not a nice-to-have.
- Is self-hosting an option? Even if you use cloud hosting today, having the option to self-host gives you a migration path if regulations change or if your compliance requirements evolve.
How Traceflair Handles GDPR
Traceflair was designed from day one for teams that need behavioral analytics without compliance risk. Privacy is not a feature we added — it is an architectural constraint that shaped every design decision. Here is how it works in practice.
Three Consent Modes
Traceflair supports three distinct consent modes, configured with a single data attribute:
opt-in— No data is collected until the user explicitly grants consent. This is the strictest mode and the right choice for EU audiences subject to GDPR and ePrivacy requirements.opt-out— Data collection begins on page load, and users can opt out at any time. Suitable for markets where implied consent is legally acceptable.implied— Analytics are always active. Appropriate for first-party analytics on your own infrastructure where no personal data is collected beyond what is strictly necessary.
The consent mode is not a cosmetic setting. In opt-in mode, the SDK does not initialize any plugins, does not set any cookies, and does not send any network requests until consent is granted. Zero data leaves the browser. Read more about our privacy architecture in Session Replay Done Right.
Automatic PII Detection
Session replay and form analytics capture what users type and interact with. Without safeguards, this means recording email addresses, phone numbers, passwords, and credit card numbers. Traceflair includes automatic PII detection that identifies and masks sensitive data before it leaves the browser. Input fields with types like password, email, and tel are masked by default. Pattern-based detection catches credit card numbers, social security numbers, and other structured PII in text content.
The data-traceflair-ignore Attribute
For granular control, add data-traceflair-ignore to any HTML element. The entire subtree — including all child elements — is excluded from session recording, click tracking, and heatmap data collection. Use it on account settings sections, payment forms, medical information fields, or any part of your application that handles sensitive data:
<div data-traceflair-ignore>
<!-- This entire section is invisible to Traceflair -->
<form id="payment-form">
<input type="text" name="card-number" />
<input type="text" name="cvv" />
</form>
</div>Self-Hosting for Full Data Sovereignty
When you self-host Traceflair, your analytics data stays on your servers. There is no third-party data processor. No cross-border data transfer. No sub-processor chain. Your DPA requirements are simplified because you are both the controller and the processor. A single docker compose up deploys the complete platform: event ingestion, storage, session replay, heatmaps, form analytics, and the dashboard.
IP Anonymization
Traceflair anonymizes IP addresses before storing them. The last octet of IPv4 addresses and the last 80 bits of IPv6 addresses are zeroed out. This makes IP addresses non-personal data under GDPR while still allowing approximate geographic segmentation. Anonymization happens at the ingestion layer, before data touches the database, so raw IP addresses are never stored.
GDPR compliance is not optional, and it should not be difficult. The right analytics tool handles the hard parts — consent gating, PII detection, data minimization, IP anonymization — so your team can focus on understanding users rather than worrying about compliance. Visit our privacy page for the full details of how Traceflair protects user data, or explore the complete feature set to see what you get.
Start your free trial and get GDPR-compliant analytics running in under 5 minutes. No credit card required.