How to Make Your Website Analytics GDPR Compliant

This guide covers what GDPR actually says about analytics, what counts as personal data in this context, how to pick a lawful basis, and a practical checklist you can work through today.

What GDPR Actually Says About Analytics

GDPR is a regulation about personal data. Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person." If your analytics tool processes personal data, GDPR applies. If it does not process personal data, GDPR does not apply.

Article 6 lists the lawful bases for processing personal data. For analytics, the two most relevant are:

• Article 6(1)(a): Consent. The user has given clear, informed, freely given consent to the specific processing activity.
• Article 6(1)(f): Legitimate interests. Processing is necessary for a legitimate interest pursued by the controller, except where overridden by the user's fundamental rights and interests.

The entire consent banner industry exists because many common analytics implementations process personal data under Article 6(1)(a). Whether they have to is a separate question, answered by looking at what data the tool actually collects.

What Counts as Personal Data in an Analytics Context

This is where most compliance discussions go wrong. People assume analytics data is anonymous. It often is not.

IP addresses are personal data. The Court of Justice of the EU confirmed this in the 2016 Breyer case (C-582/14). Even a dynamic IP address can constitute personal data when combined with information held by a third party (your ISP) that could be used to identify the individual. If your analytics tool stores raw IP addresses, those are personal data.

Cookie identifiers are personal data. A UUID stored in a cookie and associated with behavioral data is personal data. It does not need to contain a name or email address. The combination of a persistent identifier and a behavioral record is enough to constitute an identifiable person.

User-Agent strings combined with other signals may be personal data. Browser fingerprinting, whether intentional or incidental, can create a profile that identifies a specific device. Combining User-Agent, screen resolution, installed fonts, timezone, and other browser characteristics creates a fingerprint that is practically unique. If your tool collects and stores this combination, the resulting profile is likely personal data.

Aggregate statistics are not personal data. "327 pageviews on /pricing yesterday" contains no information about any identifiable individual. Truly aggregate data that cannot be traced back to an individual is outside the scope of GDPR.

The practical test: can the data in your analytics system, alone or in combination with other data your vendor or a third party holds, be used to identify a specific individual? If yes, it is personal data.

The Consent Approach

If your analytics tool processes personal data, consent under Article 6(1)(a) is the most common lawful basis. Using it correctly has specific requirements:

Valid consent under GDPR must be:

• Freely given (no pre-ticked boxes, no bundling with terms of service)
• Specific (the user must know what they are consenting to)
• Informed (clear description of what data is collected and how it is used)
• Unambiguous (clear affirmative action, not simply not opting out)

Withdrawing consent must be as easy as giving it. A user who accepted analytics tracking must be able to revoke that consent with the same number of clicks. An "accept all" button on the front page and a buried settings menu six layers deep is not compliant. Multiple national data protection authorities, including Germany's DSK (Datenschutzkonferenz) and France's CNIL, have issued explicit guidance on this.

No analytics before consent. If consent is your lawful basis, your tracking script cannot load before the user has made a choice. Pre-loading the script "just to be ready" while waiting for the consent response is a common mistake and a GDPR violation.

Data protection authorities in France, Austria, Italy, and other EU member states actively investigate and fine companies for consent failures. Austria's DSB issued its ruling on the use of Google Analytics in December 2021 (widely reported in January 2022). CNIL followed days later. These were not theoretical concerns.

The No-Personal-Data Approach

GDPR only applies to processing of personal data. If your analytics tool does not process personal data, GDPR consent requirements do not apply to it.

This is how cookieless analytics tools like Plausible, Fathom, Simple Analytics, and Abner approach the problem. Instead of collecting and storing identifiable data, they:

• Never set cookies
• Hash IP addresses (often with a daily-rotating salt) so the hash cannot be reversed or linked across days
• Do not build persistent visitor profiles
• Store only aggregate metrics and per-event records that contain no personal data

Abner, for example, hashes IP addresses with a daily-rotating salt and never stores the raw IP. The hash is used only within a single calendar day to distinguish unique visitors from repeat pageloads of the same session. After midnight, the salt rotates and the connection between a visitor's hash and their actual IP is permanently severed. There is nothing in the database that constitutes personal data.

When you use a tool like this, you do not need a consent banner for analytics. Not because you are exempted from GDPR, but because GDPR simply does not apply. There is no personal data being processed.

The Legitimate Interests Approach: Why It Usually Does Not Work for Analytics Cookies

Some companies try to claim Article 6(1)(f) legitimate interests as the lawful basis for analytics cookies, bypassing the consent requirement. This is legally risky.

The European Data Protection Board (EDPB) and multiple national DPAs have indicated that analytics cookies cannot generally rely on legitimate interests because they are not strictly necessary for the service the user requested. The user came to read your pricing page. A cookie tracking their behavior across sessions is not necessary to deliver that page.

To rely on legitimate interests, you must conduct a Legitimate Interests Assessment (LIA) that balances your interest against the impact on the data subject. For behavioral tracking cookies, this balance has repeatedly failed to satisfy regulators. If you want to use this basis, get legal advice specific to your situation. Do not treat it as a shortcut.

The French CNIL Google Analytics Ruling: What It Means

In January 2022, France's CNIL issued a formal opinion finding that use of Google Analytics violates GDPR. The specific issue was not consent (though that mattered too). The core problem was data transfer: Google Analytics sends data to Google's servers in the United States, and there is no adequate mechanism to protect that data from access by US intelligence agencies under FISA Section 702.

Austria's DSB had issued its ruling in December 2021 (widely reported in January 2022). Italy, Denmark, and Finland followed with their own findings. The EU-US Data Privacy Framework, adopted in 2023, created a new adequacy decision for US transfers, which Google has joined. This may resolve the transfer issue for some organizations. However, the consent and personal data collection issues remain separate from the transfer question.

The practical takeaway: Google Analytics with a proper consent implementation may now be GDPR-compatible from a transfer perspective under the 2023 framework, but it still requires valid consent for cookie-based tracking. The consent burden has not disappeared.

Data Retention and Minimization

Even with a valid lawful basis, GDPR imposes additional obligations that apply to analytics data.

Data minimization (Article 5(1)(c)): Collect only data that is adequate, relevant, and limited to what is necessary. If your analytics tool is collecting device fingerprint data, advertising IDs, or demographic inferences you never look at, that excess collection creates compliance risk.

Storage limitation (Article 5(1)(e)): Personal data must not be kept longer than necessary. If you have raw server logs containing IP addresses from three years ago, stored because nobody ever thought to delete them, that is a storage limitation violation. Set automatic deletion policies and verify they are enforced.

For analytics specifically: if you can answer your business questions with 13 months of historical data, retaining 5 years of personal data is harder to justify. Configure your tool's data retention settings explicitly.

Data Processing Agreements

If your analytics vendor processes personal data on your behalf, they are a data processor. GDPR Article 28 requires a written Data Processing Agreement (DPA) between you and every data processor. All major analytics vendors provide DPAs. Make sure you have actually executed one rather than assuming it is covered in the terms of service.

If you switch to a tool that processes no personal data at all, the DPA requirement for analytics data disappears, because there is no personal data for the DPA to cover.

GDPR Compliance Decision Tree

GDPR Compliance Checklist for Analytics

Work through this list for your current analytics setup. A "no" answer on any item is a gap that needs addressing.

• Do I know exactly what personal data my analytics tool collects? Read the vendor's data processing documentation, not just the marketing page.
• Do I have a lawful basis for processing that data? Identify which Article 6 basis you are relying on and document it.
• If using cookies: is my consent mechanism compliant? Freely given, specific, informed, unambiguous. Decline as easy as accept. No pre-ticked boxes.
• Does analytics tracking load only after confirmed consent? Not before, not in parallel. After.
• Do I have a signed Data Processing Agreement with my analytics vendor? Not just agreed to terms of service. An actual DPA.
• Is my privacy policy current and accurate? It must describe your analytics data processing specifically: what data, what basis, retention period, vendor name.
• Do I have a data retention policy? Is it automatically enforced? Not a policy document that nobody looks at. An actual automated deletion schedule.
• If data is transferred outside the EU: is there a valid transfer mechanism? Standard Contractual Clauses (SCCs) or adequacy decision. Verify your vendor is covered.
• Can I fulfill a right to erasure request for analytics data? If a user asks you to delete their data, can you actually identify and delete their analytics records?
• Do I have a process for Data Subject Access Requests? A user can request all personal data you hold on them. Analytics data is in scope if it is personal data.
• Is analytics data used for profiling or automated decision-making? If so, additional obligations under Articles 21 and 22 may apply.
• Have I documented my compliance decisions? GDPR requires accountability. Document the basis, the tool, the DPA, the retention policy. If you are audited, this documentation matters.

The Simplest Path to Full Compliance

The lowest-maintenance path to GDPR compliance for analytics is using a tool that does not process personal data. When the tool collects no personal data, most of the checklist above collapses:

• No lawful basis decision required (GDPR does not apply)
• No consent banner required
• No DPA required for analytics data (nothing personal to protect)
• No right to erasure problem (there is no personal data to erase)
• No data retention risk from analytics data
• No transfer mechanism concern

Contrast that with the cookie-based analytics compliance stack:

• Consent Management Platform: $20-100/month
• CMP engineering integration: 5-15 hours initial setup
• Legal review of consent wording
• Ongoing maintenance when regulations change
• Reduced data accuracy from consent dropoff (30-40% on many sites, depending on banner design and geography)

Switching to a cookieless analytics tool eliminates this maintenance burden entirely. The tradeoff is losing persistent cross-visit individual user tracking, which the vast majority of SaaS analytics use cases do not actually require. You keep everything useful: pageviews, unique visitors, sessions, top pages, referrer sources, UTM parameters, custom events, real-time data.

Tools that take this approach include Plausible, Fathom, Simple Analytics, and Abner. None require a cookie consent banner. All produce data that is outside the scope of GDPR because no personal data is processed.

CCPA: A Brief Note

The California Consumer Privacy Act applies to businesses collecting personal information from California residents. The personal information definition in CCPA is broader than GDPR's in some respects but the analytics analysis is similar: if your tool collects data that can be linked to a specific consumer or household, it is covered. Cookieless tools that collect no individually identifiable data generally fall outside CCPA's scope for analytics data. If you are in the cookie-based analytics camp, CCPA requires a "Do Not Sell or Share My Personal Information" mechanism and a compliant privacy policy.

Summary

GDPR compliance for analytics reduces to a single question: does your analytics tool process personal data? If yes, you need a lawful basis, almost certainly consent, with all the implementation burden that entails. If no, GDPR does not apply to your analytics at all.

The compliance checklist above gives you a specific set of items to verify. The simplest way to shorten that list significantly is to switch to a tool that processes no personal data. Every item on the checklist that starts "if your tool processes personal data" simply disappears.