GDPR compliant analytics: what you need to know
TL;DR:
- Adding a cookie banner does not ensure GDPR compliance for analytics, which requires comprehensive data management. Privacy-first tools collect no personal data and can operate legally without consent, offering higher data completeness and lower compliance risks. Continuous reviews, proper documentation, and technical measures are essential for maintaining lawful and effective GDPR-compliant analytics processes.
Most businesses assume that adding a cookie banner makes their analytics GDPR compliant. It does not. Understanding what is GDPR compliant analytics means recognising that compliance touches every layer of your data setup, from how you collect IP addresses and device data, to where your analytics vendor stores that information. Get it wrong and you face more than regulatory risk. You face a dataset built on incomplete, unreliable information. This guide cuts through the confusion and gives you a practical framework for collecting meaningful data while staying firmly within the rules.
Table of Contents
- Key takeaways
- What GDPR analytics requirements actually cover
- Consent-based vs privacy-first analytics
- Technical measures for GDPR data privacy analytics
- Choosing the right analytics tool
- Best practices for ongoing GDPR analytics compliance
- My take on GDPR analytics compliance
- How Qrlytics approaches privacy-first analytics
- FAQ
Key takeaways
| Point | Details |
|---|---|
| GDPR covers more than cookies | IP addresses and device fingerprints count as personal data, not just cookie identifiers. |
| Consent refusals distort data | Between 30 and 70% of users decline consent, making consent-based analytics unreliable. |
| Privacy-first tools change the model | Some analytics tools collect no personal data at all, allowing a legitimate interest legal basis. |
| DPAs are non-negotiable | Written Data Processing Agreements with your analytics vendor are legally required under GDPR. |
| Compliance is continuous | Regular audits, DPIAs, and records reviews are necessary, not optional. |
What GDPR analytics requirements actually cover
Many organisations treat GDPR as a checkbox exercise. The regulation runs much deeper than that, particularly when it comes to analytics.
Under GDPR, personal data is any information that can identify a natural person, directly or indirectly. That definition is broader than most marketers expect. Dynamic IP addresses are personal data under GDPR when identification via an ISP is feasible, as established by the CJEU in the Breyer case. Device fingerprints, session identifiers, and user IDs all carry the same classification.
The legal bases most relevant to compliance in data analytics are:
- Consent (Article 6(1)(a)): freely given, specific, informed, and unambiguous agreement from the user
- Legitimate interest (Article 6(1)(f)): where your processing need is balanced against the user’s rights, documented through a Legitimate Interest Assessment
- Legal obligation (Article 6(1)©): rarely applicable to standard web analytics
Beyond legal basis, two principles shape every analytics decision. Data minimisation means collecting only what you genuinely need. Purpose limitation means not repurposing data collected for one reason to serve another. If you collect session data to improve page performance, you cannot quietly redirect that data to build advertising profiles.
Data subject rights also apply directly to analytics. Users can request access to the data held on them, request deletion, and object to processing. If your analytics setup cannot action a deletion request, it is not compliant. Your privacy policy must clearly explain what analytics data you collect, why, and how long you keep it.
Consent-based vs privacy-first analytics
This is where the practical difference between approaches becomes stark. Most organisations default to consent-based analytics because it is familiar. But the data picture it produces is far from complete.
With consent-based tools such as Google Analytics 4, a cookie banner fires before any tracking begins. If the user declines, no data is collected for that session. The problem is that 30 to 70% of users decline consent in standard consent-based models, meaning your analytics may be missing more than half of your actual audience. Decisions made on that data are decisions made with a significant blind spot.
Privacy-first analytics tools take a fundamentally different approach. Tools that operate without cookies, IP storage, or fingerprinting can operate under a legitimate interest legal basis rather than requiring explicit consent. Platforms such as Plausible, Fathom, Matomo (with the right configuration), and Umami are built on this model. They aggregate data at a statistical level and never tie behaviour to an identifiable individual.
Pro Tip: If you choose the legitimate interest route, you still need a Legitimate Interest Assessment. LIAs are required documentation even when your tool makes no personal data contact at all. Prepare it before you go live, not after an audit.
Here is how the two models compare:
| Approach | Data completeness | Consent needed | Legal basis | Compliance risk |
|---|---|---|---|---|
| Consent-based (e.g. GA4) | Low to medium (30–70% loss) | Yes | Consent | Higher, especially for US transfers |
| Privacy-first (e.g. Plausible, Fathom) | High (tracks all visitors) | No | Legitimate interest | Lower, with LIA in place |
| Self-hosted privacy-first (e.g. Matomo) | High | No | Legitimate interest | Lowest with EU hosting |
The data completeness advantage of privacy-first tools is not a minor detail. When you are trying to understand which marketing channels perform, which content converts, or where users drop off, a 50% data gap makes those questions unanswerable with confidence. Privacy-first analytics are recommended by experts precisely to avoid consent fatigue and improve the coverage of your dataset.
Technical measures for GDPR data privacy analytics
Getting the legal basis right is only part of the picture. The technical and operational measures you put in place determine whether that legal basis actually holds up.
-
Understand IP anonymisation limits. Truncating the last octet of an IP address is pseudonymisation, not true anonymisation. Truncated IPs are still treated as personal data by most Data Protection Authorities when combined with browser fingerprints or other identifiers. True anonymisation requires data to be unlinkable to an individual by any means whatsoever. Most standard analytics configurations do not meet that bar.
-
Manage data transfers carefully. If your analytics vendor stores data outside the EU, you need a lawful transfer mechanism in place, such as Standard Contractual Clauses. Google Analytics has been found non-compliant by multiple EU Data Protection Authorities because full IP addresses are transferred to US servers before anonymisation occurs. This is not a configuration problem you can fix with a setting. It is structural.
-
Set data retention limits. Define how long you keep analytics data and automate deletion at that point. Most DPAs expect retention periods to be proportionate to the purpose. Holding two years of granular session data when a 90-day aggregate would serve the same purpose is hard to justify.
-
Sign Data Processing Agreements with every vendor. DPAs are mandatory with analytics vendors even when the vendor claims GDPR readiness. The agreement must set out responsibilities, security standards, and sub-processor arrangements in writing.
-
Configure your Consent Management Platform properly. Analytics cookies are not strictly necessary under GDPR, which means pre-ticked boxes, implied consent, and “continuing to use this site means you agree” approaches are all unlawful. Consent must be withdrawable as easily as it is given.
-
Maintain Records of Processing Activities (RoPA) and conduct Data Protection Impact Assessments (DPIAs) for high-risk processing. These are not one-off tasks. GDPR compliance is a continuous process that requires regular reviews as your tools, vendors, and data flows change.
Pro Tip: Self-hosting your analytics on EU servers removes the data transfer problem entirely. Self-hosting eliminates transfer risks and gives you direct control over retention and deletion. For organisations with the technical resource, it is one of the most straightforward paths to a defensible compliance position.
Choosing the right analytics tool
Tool selection is where GDPR data privacy analytics decisions become concrete. The table below summarises the key compliance and operational characteristics of widely used platforms.
| Tool | Cookies used | IP handling | Default hosting | Consent required | Key risk |
|---|---|---|---|---|---|
| Google Analytics 4 | Yes | Transferred to US before anonymisation | US (Google servers) | Yes | US data transfer, EU enforcement |
| Matomo (cloud) | Optional | Anonymised or not stored | EU available | Optional (privacy mode) | Depends on configuration |
| Matomo (self-hosted) | Optional | Fully controllable | Your EU server | Optional | Misconfiguration |
| Plausible | No | Not stored | EU (Hetzner, Germany) | No | Minimal |
| Fathom | No | Not stored | EU/US with SCCs | No | Low with SCC review |
| Umami | No | Not stored | Self-hosted | No | Depends on hosting |
The Google Analytics compliance challenges are well documented. If you continue using GA4, you need Consent Mode v2 properly configured, a valid DPA with Google, and a consent mechanism that genuinely meets GDPR standards. That is a significant operational overhead. For many small to medium businesses, privacy-first alternatives deliver equivalent marketing insight with far less compliance exposure and the added benefit of complete data.
Best practices for ongoing GDPR analytics compliance
Getting compliant is one thing. Staying compliant as your organisation grows and regulations evolve is a different challenge. These practices help you maintain a defensible position over time.
- Document everything. Your LIAs, DPAs, consent configuration, and retention schedules should all be written down and version controlled. Documentation is your evidence in any regulatory enquiry.
- Review your analytics setup at least annually. Vendors update their products, sub-processors change, and regulatory guidance develops. What was compliant last year may not be compliant today.
- Align marketing and compliance teams early. The best practices for GDPR analytics only work when the people running campaigns and the people managing compliance are talking to each other. Marketing teams often introduce new tracking tags without realising the compliance implications.
- Be transparent with your customers. Your privacy policy should clearly explain your analytics tools, the legal basis for processing, and how users can exercise their rights. Transparency is not just a legal requirement. It builds trust with the audience you are trying to reach.
- Monitor regulatory decisions. EU and UK Data Protection Authorities regularly publish enforcement decisions and updated guidance. Subscribing to ICO and EDPB updates costs nothing and keeps you ahead of changes before they become problems. Analytics data that drives 57% better ROI is only valuable if the collection method holds up to scrutiny.
My take on GDPR analytics compliance
I have worked with enough organisations to know that most GDPR analytics problems are not legal problems. They are operational ones. Someone set up GA4 three years ago, signed a DPA once, and nobody has reviewed the configuration since. The tools have changed, the regulation has been enforced, and the gap between what the privacy policy says and what is actually happening is significant.
What I have observed is that the consent-based data loss problem does not get taken seriously enough until someone looks at the numbers. When you realise your analytics data represents, at best, half of your actual visitors, the case for a privacy-first tool becomes obvious. You get more data, simpler compliance, and far less operational overhead.
The documentation side is where I see organisations consistently underinvest. A Legitimate Interest Assessment is not a bureaucratic formality. It is the record that demonstrates you thought carefully about the balance between your business need and your users’ privacy rights. Documented LIAs demonstrate lawful processing in a way that no amount of verbal assurance ever will.
My honest recommendation is to evaluate privacy-first analytics tools before you are forced to. The organisations that will struggle are those that keep retrofitting compliance onto architectures that were never designed for it. Starting with a tool that collects no personal data by design removes an entire category of risk. For QR code campaigns, event marketing, and physical-to-digital tracking, that approach is entirely practical and commercially sound.
— The Qrlytics Team
How Qrlytics approaches privacy-first analytics
If you run QR code campaigns as part of your marketing, compliance in data analytics applies to your scan tracking just as much as your website. Qrlytics is built with GDPR-focused data handling at its core, offering privacy-conscious scan analytics without compromising data coverage or campaign insight.
With Qrlytics, you get real-time scan data, geographic tracking, and campaign performance metrics through an infrastructure designed to respect user privacy. Dynamic QR codes let you update redirect URLs without reprinting materials, and every scan event is logged in a way that supports your compliance obligations rather than creating new ones. Whether you are running a small campaign or managing QR codes across a national print run, Qrlytics gives you the tracking depth you need without the compliance exposure you do not. Explore the free QR code generator and see how compliant campaign tracking works in practice, or visit Qrlytics to review the full feature set.
FAQ
What is GDPR compliant analytics?
GDPR compliant analytics refers to the collection, processing, and storage of website or campaign data in a way that meets all requirements of the General Data Protection Regulation, including lawful legal basis, data minimisation, transparency, and user rights. It covers both the tools you use and the processes you operate.
Do I need a cookie banner for GDPR analytics?
Not always. If you use a privacy-first analytics tool that collects no personal data and sets no cookies, you may be able to rely on legitimate interest rather than consent, removing the need for a cookie consent banner. You will still need a Legitimate Interest Assessment.
Why is Google Analytics a GDPR compliance risk?
Google Analytics transfers full IP addresses to US servers before anonymisation, which multiple EU Data Protection Authorities have found to be a GDPR violation. To use it compliantly, you need Consent Mode v2 configured correctly, a valid DPA with Google, and a lawful transfer mechanism for US data transfers.
How much data do I lose with consent-based analytics?
Research shows that between 30 and 70% of users decline consent in standard cookie consent setups, meaning your analytics data may represent fewer than half of your actual visitors. Privacy-first tools avoid this loss by not requiring consent at all.
How often should I review my GDPR analytics compliance?
At minimum, review your analytics setup annually and whenever a vendor updates their platform or sub-processors change. GDPR compliance is an ongoing obligation, not a one-time configuration. Regular audits, updated Records of Processing Activities, and refreshed DPIAs are all part of maintaining a lawful setup.