GDPR Compliance for Analytics in 2026: What You're Actually Required to Do
Most cookie consent banners exist because an analytics vendor told website owners they were legally required. The actual requirement is narrower: you need consent only when you process personal data. Whether your analytics tool processes personal data determines almost everything else.
This guide covers what GDPR actually says about analytics, what counts as personal data in this context, a practical 12-point compliance checklist, CCPA basics for US-facing businesses, and the ePrivacy Directive — the "cookie law" that is frequently conflated with GDPR but is a separate instrument with its own requirements.
The Core GDPR Rule for 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. Whether yours does depends on what the tool actually collects and stores.
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 that could 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 even without a name or email address. The combination of a persistent identifier and a behavioral record is enough to constitute an identifiable person.
Browser fingerprints may be personal data. Combining User-Agent, screen resolution, timezone, installed fonts, 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 12-Point GDPR Analytics Compliance Checklist
Work through this list for your current analytics setup. A gap on any item needs addressing before you can consider your analytics implementation compliant.
- 1 Identify whether your analytics tool stores cookies or builds persistent visitor profiles through fingerprinting.
- 2 Confirm whether IP addresses are stored raw, or hashed and anonymized in a way that prevents reversal.
- 3 Document your lawful basis for analytics processing — either consent (Article 6(1)(a)) or legitimate interests (Article 6(1)(f)).
- 4 If using consent: implement a compliant consent management platform. Confirm the banner is freely given, specific, informed, and unambiguous — no pre-ticked boxes, decline as easy as accept.
- 5 If using legitimate interests: complete a Legitimate Interests Assessment (LIA) and document it. Regulators have repeatedly rejected LIA arguments for analytics cookies — get legal advice before relying on this basis.
- 6 Configure data retention periods explicitly. Verify automatic deletion is enforced — a policy document nobody enforces is not GDPR-compliant data minimization.
- 7 Update your privacy policy to accurately describe your analytics processing: what data, which lawful basis, retention period, vendor name, and how users can exercise their rights.
- 8 Confirm data transfer compliance. If your analytics vendor is based in the US, verify they are covered by the EU-US Data Privacy Framework (adopted 2023) or have Standard Contractual Clauses (SCCs) in place.
- 9 Test that analytics tracking stops completely when consent is withdrawn. The tracking script must not fire, not merely be suppressed at the display layer.
- 10 Verify a Data Processing Agreement (DPA) with your analytics vendor is signed and current. DPAs are required by Article 28 — agreed-to terms of service is not a substitute.
- 11 Train team members who can access analytics data on GDPR basics: what constitutes a data subject request, how to handle one, and who to escalate to.
- 12 Schedule an annual review of your analytics setup and compliance documentation. Regulations, vendor practices, and enforcement priorities change — your assessment from 2022 may not reflect today's requirements.
CCPA and Analytics: What California Requires
The California Consumer Privacy Act (CCPA), amended by the California Privacy Rights Act (CPRA), is the most significant US privacy law affecting analytics. It applies to for-profit businesses that meet at least one of these thresholds:
- Annual gross revenue exceeding $25 million
- Annual buying, selling, or receiving personal information of 100,000 or more California residents or households
- Deriving 50% or more of annual revenue from selling or sharing California residents' personal information
Most small businesses and early-stage startups fall below these thresholds. If you do meet them, the analytics-specific implications are as follows.
Does your analytics tool "sell" or "share" data? CCPA's definition of "sale" and "share" (for cross-context behavioral advertising) is broad. Many analytics tools do not sell data, but check your vendor's data use terms carefully. If your analytics vendor uses data collected from your site to train models, improve its own products, or serve advertising on other sites, that may constitute "sharing" under CCPA.
If personal information is sold or shared: CCPA requires a "Do Not Sell or Share My Personal Information" link prominently displayed on your website. You must also update your privacy policy with the categories of personal information collected, the purposes, and the rights available to California residents (access, deletion, correction, opt-out of sale/sharing).
The cookieless analytics shortcut applies here too. If your analytics tool collects no personal information — no IP addresses, no cookies, no device fingerprints linked to individuals — there is no personal information to sell, share, or protect under CCPA. The regulation's analytics obligations effectively disappear.
The Cookie Law: ePrivacy Directive Basics
The ePrivacy Directive (2002/58/EC, amended by 2009/136/EC) is the legal instrument commonly called "the cookie law." It is separate from GDPR but frequently confused with it. Here is what actually matters for analytics.
What the ePrivacy Directive requires: Article 5(3) of the Directive requires "prior informed consent" before storing information on — or retrieving information from — a user's terminal equipment. In plain English: before setting a cookie, you need consent.
Analytics cookies are non-essential. The Directive includes a limited exception for cookies that are "strictly necessary" to provide a service explicitly requested by the user. Login session cookies are strictly necessary. Analytics cookies are not — the user requested your content, not behavioral tracking. All major EU data protection authorities have confirmed this interpretation.
Where GDPR and ePrivacy intersect: When you use a cookie-based analytics tool, you have two distinct obligations. The ePrivacy Directive requires consent to set the cookie. GDPR requires a lawful basis to process the personal data contained in that cookie. Both apply simultaneously. This is why cookie-based analytics compliance requires both a legal basis under GDPR and a technically compliant consent mechanism under ePrivacy.
The ePrivacy Directive does not apply to cookieless analytics. If your analytics tool sets no cookies and reads no information from the user's device, Article 5(3) of the Directive is not triggered at all. There is no cookie consent requirement because there are no cookies. The consent obligation exists only when something is stored on or read from the user's device.
The Cookieless Analytics Exception
A tool that sets no cookies and processes no personal data occupies a fundamentally different compliance category from cookie-based analytics. The distinction is not a technicality — it collapses most of the compliance burden entirely.
- ✗ Consent banner required (ePrivacy)
- ✗ Lawful basis required (GDPR)
- ✗ DPA with vendor required
- ✗ Data transfer mechanism required
- ✗ Right to erasure must be operable
- ✗ 30–40% data loss from consent dropoff
- ✗ CCPA opt-out if vendor shares data
- ✓ No consent banner needed
- ✓ GDPR does not apply (no personal data)
- ✓ No DPA needed for analytics data
- ✓ No transfer mechanism needed
- ✓ No erasure problem (nothing personal stored)
- ✓ 100% data — all visits counted
- ✓ No CCPA obligations for analytics data
The tradeoff is losing persistent cross-visit individual user tracking — which the vast majority of SaaS and content site analytics use cases do not require. You keep everything that matters: pageviews, unique visitors, sessions, top pages, referrer sources, UTM parameters, custom events, and real-time data.
Tools that operate this way include Plausible, Fathom, Simple Analytics, and Abner. All produce data that is outside the scope of GDPR because no personal data is processed, and outside the scope of the ePrivacy Directive because no cookies are set.
The Consent Approach: Getting It Right
If you are using a cookie-based analytics tool and have decided consent is your lawful basis, the implementation requirements are specific and frequently violated in practice.
Valid consent under GDPR must be:
- Freely given — no pre-ticked boxes, no bundling with terms of service acceptance
- Specific — the user must know what they are consenting to, including the vendor's name
- Informed — a clear description of what data is collected and how it is used
- Unambiguous — clear affirmative action, not simply failing to opt out
Withdrawing consent must be as easy as giving it. An "Accept all" button on the front page and a buried settings panel six layers deep is not compliant. Germany's DSK and France's CNIL have both issued explicit guidance on this requirement.
No analytics before consent is confirmed. If consent is your lawful basis, your tracking script cannot load before the user has made an active choice. Pre-loading the script while waiting for the consent response is a GDPR violation.
In January 2022, France's CNIL and Austria's DSB both issued formal opinions that the use of Google Analytics violated GDPR — the core issue being US data transfers under FISA Section 702. Italy, Denmark, and Finland followed. The EU-US Data Privacy Framework (2023) created a new adequacy decision for US transfers, which Google has joined, potentially resolving the transfer issue. But the consent requirements described above are unaffected by the transfer framework. The consent burden has not disappeared.
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 and rarely survives regulatory scrutiny.
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 around consent requirements.
Data Retention and Minimization
Even with a valid lawful basis, GDPR's data minimization and storage limitation principles impose additional obligations on 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 with no business benefit.
Storage limitation (Article 5(1)(e)): Personal data must not be kept longer than necessary. Raw server logs containing IP addresses from three years ago — stored because nobody ever thought to delete them — are a storage limitation violation. Set automatic deletion policies and verify they are actually enforced in the vendor's systems, not just documented in your own internal policies.
If your analytics vendor processes personal data on your behalf, GDPR Article 28 also requires a written Data Processing Agreement (DPA). 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 disappears entirely.
GDPR Compliance Decision Tree
How Abner Is GDPR-Compliant by Design
Abner is GDPR-compliant by design
Abner uses cookieless, fingerprint-free analytics. IP addresses are hashed with a daily-rotating salt and never stored in raw form — 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 link between a visitor's hash and their actual IP is permanently severed. No personal data is collected or stored. GDPR consent requirements do not apply, the ePrivacy Directive cookie rules do not apply, and no consent banner is needed.
Start free trial →Summary
GDPR compliance for analytics in 2026 reduces to one question: does your analytics tool process personal data? If yes, you need a lawful basis under GDPR (almost always consent), a compliant consent mechanism under the ePrivacy Directive, a DPA with your vendor, a data transfer mechanism if the vendor is US-based, and all the ongoing maintenance those obligations entail. If no, none of those requirements apply.
CCPA adds a parallel set of obligations for US businesses above certain size thresholds — focused on the right to opt out of sale or sharing of personal information. For analytics specifically, a tool that collects no personal information sidesteps both frameworks at once.
The 12-point checklist above gives you concrete items to verify for your current setup. If you are on cookie-based analytics and every item on that list represents ongoing compliance work, the simplest remediation is switching to a tool that does not process personal data. At that point, most of the list simply does not apply to your analytics implementation.