Analytics Without Consent Banners: What GDPR Allows (2026)

The consent misconception: GDPR vs. the ePrivacy Directive

Most WordPress site owners believe they need a cookie consent banner because “GDPR requires it for analytics.” That framing is an oversimplification — and it has driven a proliferation of consent popups across the web, many of them broader than the law demands. Running GDPR analytics without a consent banner can be a defensible, mainstream position for a correctly architected setup — but whether it is defensible for your setup depends on two distinct instruments of European privacy law that operate in parallel and govern entirely different things.

• GDPR (General Data Protection Regulation, EU 2016/679) governs the processing of personal data across the EU and EEA. It establishes six legal bases for processing: consent, legitimate interest, contractual necessity, legal obligation, vital interests, and public task. Consent is one option, not the only one.
• ePrivacy Directive (Directive 2002/58/EC, as amended) specifically governs electronic communications privacy, including what happens on users’ devices. Article 5(3) — the so-called “Cookie Law” — is the provision that requires prior informed consent before storing or accessing information on a user’s terminal equipment.

The consent requirement that drives most analytics banners flows primarily from the ePrivacy Directive and its national implementations, not from GDPR directly. Critically, the ePrivacy layer targets a specific act: storing or accessing data on the visitor’s device. It is not a blanket requirement on every form of analytics data collection. But the inverse is equally important and often glossed over by analytics vendors: if your tool does write to the device — even just a pseudonymous ID in localStorage — the device-storage consent rules are engaged in jurisdictions that enforce them strictly. “No cookies” does not automatically mean “no consent trigger.”

What Article 5(3) actually covers — and what it does not

Article 5(3) of the ePrivacy Directive requires prior informed consent before “the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user.” In practice, this provision covers:

• HTTP cookies — both setting and reading them
• localStorage and sessionStorage used for visitor identification or persistent measurement — the wording is technology-neutral, so “cookieless” tools that store an identifier in localStorage are still inside its scope
• Browser fingerprinting techniques that reconstruct identifiers from browser attributes
• IndexedDB and equivalent persistent browser-side storage mechanisms
• Any JavaScript-based technique that reads previously stored information to re-identify a visitor across sessions

Article 5(3) does not cover:

• Server-side processing of HTTP request metadata — IP address, User-Agent, referrer, timestamp — transmitted to your server as part of how the HTTP protocol works
• Analytics derived purely from server-received data without reading or writing anything to browser storage
• Aggregate statistical analysis of access patterns that does not involve individual identification

When a user loads a page, their browser transmits certain information to your server as part of the TCP/IP and HTTP handshake — before any JavaScript runs, before anything is written to the device. Processing that server-received data is fundamentally different from writing an identifier into the browser’s storage. That distinction defines the boundary between consent-required and consent-optional measurement — and it is precisely the boundary that makes analytics without a consent banner achievable, provided your tool genuinely stays on the server-side of the line for the visitors whose jurisdictions demand it.

The legitimate interest legal basis — EDPB Opinion 05/2019 and the three-step test

Even where GDPR’s personal data rules are engaged, consent is not the only lawful basis available. Article 6(1)(f) of GDPR permits processing based on legitimate interest when three cumulative conditions are satisfied. The European Data Protection Board addressed the relationship between the two frameworks in EDPB Opinion 05/2019 on the interplay between the ePrivacy Directive and the GDPR. Where ePrivacy consent is required for a device-storage layer, a separate GDPR legal basis is still needed for the subsequent personal data processing — and where the ePrivacy layer does not apply at all (because no device storage is accessed), the GDPR legitimate interest analysis stands on its own.

The three-step legitimate interest test requires:

• Purpose test: You have a genuine, articulated legitimate interest — for example, understanding how your website is used in order to improve its content and performance. The interest must be specific and real, not boilerplate.
• Necessity test: The processing is necessary to achieve that interest, and you cannot reasonably achieve the same outcome through less privacy-invasive means. Server-side measurement with hashed, truncated IP addresses satisfies this far more cleanly than any client-side profiling alternative.
• Balancing test: Your interest is not overridden by the data subject’s rights and reasonable expectations, taking into account the nature of the data, the likely impact on individuals, and the safeguards applied.

For privacy-preserving first-party analytics, this framework is genuinely workable. Understanding visitor behavior is a recognized business interest; pseudonymized, first-party-only measurement with no cross-site tracking and no third-party data sharing keeps the privacy impact demonstrably low, so the balancing test tilts in the operator’s favor.

Legitimate interest is not a free pass, however. You must conduct and document a Legitimate Interest Assessment (LIA) — a written record showing you worked through all three steps: the specific purpose pursued, the technical safeguards applied, and your reasoned conclusion on the balancing test. File it alongside your Records of Processing Activities (ROPA) and review it annually.

Jurisdiction by jurisdiction: where the answer actually diverges

Germany — TDDDG Section 25, the strictest reading

Germany implements the ePrivacy rules through the TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, renamed from the TTDSG in May 2024). Section 25 requires consent for storing information on, or accessing information already stored on, the user’s device — and German regulators read this to include localStorage used for analytics identifiers. The only exemption is for storage that is strictly necessary to deliver a service the user explicitly requested, and audience measurement generally does not qualify. The practical consequence: in Germany, an analytics tool that writes any identifier to the browser needs consent for that act, however privacy-friendly the rest of its architecture is. A tool that collects nothing from device storage for German and EU visitors avoids the Section 25 trigger entirely — which is exactly why storage-less operation matters (more on that below).

France, Spain, Belgium — the audience-measurement exemption

France’s CNIL has published an analytics exemption permitting limited audience measurement without consent when the data is used solely by the first party, is not combined with other datasets, serves only statistical measurement of the site’s own audience, and is not transmitted to third parties. The Spanish AEPD and Belgian APD have taken broadly compatible positions. The pattern across the EU in 2026: the closer your analytics is to pure first-party, non-identifying, server-side measurement, the more defensible a no-consent posture becomes — but the exact line is drawn nationally, not once for the whole EU.

United Kingdom — PECR

Post-Brexit, the UK operates under the Privacy and Electronic Communications Regulations 2003 (PECR) alongside UK GDPR. PECR Regulation 6 mirrors Article 5(3) in requiring consent for storing or accessing information on terminal equipment. The ICO has signaled that low-privacy-impact, first-party analytics sits at the bottom of its enforcement priorities, and has consulted on relaxing the rules for it — but as of 2026, the formal consent requirement for device storage remains. A pure server-side approach that never writes to or reads from the browser stays outside PECR’s device-storage trigger, with UK GDPR legitimate interest covering the residual server-side processing.

Japan — APPI

Japan’s Act on the Protection of Personal Information (APPI), substantially amended in 2022, has no equivalent of Article 5(3): there is no Japanese “cookie law” requiring consent for client-side storage per se. For Japan-facing WordPress sites, first-party analytics using hashed identifiers and no cross-linking with personal databases presents minimal APPI risk, provided appropriate privacy policy disclosure is made. This is why the compliance calculus for a Japanese-audience site differs so sharply from a German-audience one — and why a single global “yes/no banner” answer is impossible.

What enforcement has actually targeted

Reviewing enforcement actions from the major European data protection authorities since 2018 reveals a consistent pattern. Cases resulting in fines and formal notices have targeted:

• Google Analytics transferring EU visitor data to US servers under transfer mechanisms deemed insufficient after Schrems II
• Advertising tags — Meta Pixel, Google Ads conversion tags, LinkedIn Insight Tag — deployed without valid prior consent
• Consent banners that made rejection harder than acceptance, or that ignored “reject all” selections entirely
• Cross-site behavioral tracking and advertising profiling without a valid lawful basis
• Data brokers processing personal data at scale without meeting any Article 6 condition

We are not aware of published enforcement actions against first-party, server-contained analytics that processes only pseudonymized identifiers and shares nothing with third parties. That reflects regulatory purpose — protecting users from hidden third-party data collection — rather than a formal safe harbor, so it is a reason for measured confidence, not complacency. The risk profile of replacing Google Analytics with a first-party tool is categorically different from the risk profile of running GA4 without consent.

How FPAI maps onto this analysis — honestly

FPAI (First-Party AI Analytics) is a free WordPress plugin designed around GDPR principles: no cookies, no third-party endpoints, all data stored in your own WordPress database, and a built-in AI assistant — with nine supported providers — that answers questions about your traffic right inside wp-admin, a feature no other analytics plugin currently offers. But because this is a legal article, precision matters, so here is exactly how it behaves:

• Default mode: FPAI stores a pseudonymous identifier in the browser’s localStorage to recognize returning visitors. It sets no cookies and contacts no third party — but localStorage is still device storage, so in strict jurisdictions such as Germany (TDDDG Section 25), this mode engages the consent requirement.
• Storage-less Mode (v1.1.0, August 2026): EU visitors are detected automatically and measured with zero device storage — no cookies, no localStorage, nothing written to or read from the browser. For those visitors, the Article 5(3) / Section 25 trigger is never pulled, and the remaining server-side processing rests on documented legitimate interest. See the release notes. Among privacy-focused analytics tools, an automatic storage-less mode remains a genuine differentiator.

Whether you can drop the banner therefore follows the same two-variable logic as everything above: a Japan-facing or US-facing site running FPAI has a very different answer from a Germany-facing site running it in default mode — and Storage-less Mode exists precisely to close that gap for EU audiences.

A practical checklist before you remove the banner

• Map your audience. If a meaningful share of visitors comes from Germany or other strict-implementation member states, assume device-storage consent rules apply to anything written to the browser.
• Audit your actual stack. The analytics plugin is rarely the only script. One leftover Meta Pixel or Google remarketing tag re-triggers the consent requirement for the whole site.
• Verify the storage behavior yourself. Open DevTools → Application → Cookies and Local Storage and confirm what your analytics writes for an EU visitor profile.
• Write the LIA. Document purpose, necessity, and balancing for the server-side processing, and keep it with your ROPA.
• Disclose in your privacy policy. No-banner does not mean no-transparency: describe what is measured, the lawful basis, and retention.
• Re-check annually. The ePrivacy Regulation remains stalled, national guidance shifts, and tool behavior changes between versions.

Get these right, and for most non-German-centric audiences a correctly configured first-party setup supports a banner-free experience; for EU-strict audiences, a storage-less configuration does the same work without asking your visitors to click through anything.

FPAI — First-Party AI Analytics is free, lives entirely inside WordPress, keeps every byte of data on your own server, and lets you ask your analytics questions in plain language from the dashboard. Download it from the WordPress.org plugin directory and see what banner-conscious, first-party measurement looks like in practice.