Do you need a cookie banner for analytics?

The short answer is: it depends on what your analytics tool actually does. A banner is not required simply because you run analytics — it is required when specific technical operations trigger a consent obligation. Understanding the difference can save you meaningful engineering and operational overhead.

ePrivacy and GDPR: two separate laws, one common confusion

Most discussions about cookie banners conflate two distinct legal instruments. Understanding the difference matters for accurately assessing your obligations.

The ePrivacy Directive (Article 5(3)) requires informed consent before storing or reading information on a user's terminal device — this covers cookies, local storage, pixels, and any browser-side identifier. It does not cover purely server-side processing that never touches the device. This is the primary legal basis for cookie consent banners in the EU.

GDPR applies to the processing of personal data, which includes pseudonymous identifiers like session hashes. GDPR requires a lawful basis for processing (Article 6) — which can be legitimate interest or contract, not only consent, depending on what you do with the data. GDPR does not mandate consent for all analytics processing.

The practical implication: an analytics tool that places no cookie and reads no stored identifier avoids the classic Article 5(3) trigger. One important nuance: the EDPB's Guidelines 2/2023 on the technical scope of Article 5(3) read "storing and accessing information" broadly — under that reading, even instructing the browser to transmit device information can fall within scope. This is precisely why the national audience-measurement exemptions described below, and your own DPA's published position, matter: whether a specific cookieless configuration requires consent is jurisdiction-dependent, not settled EU-wide. And if the tool processes personal data (including IP-derived identifiers), GDPR still applies and requires a lawful basis — typically documented in your privacy policy.

What triggers the consent requirement

The consent banner obligation for analytics is not categorical — it depends on the technical operations your tool performs.

Triggers consent under Article 5(3) of the ePrivacy Directive:

• Setting a first-party analytics cookie (e.g. _ga, _ga_*, custom persistent identifiers)
• Reading or writing to localStorage or sessionStorage for tracking purposes
• Browser fingerprinting: combining attributes such as screen resolution, font list, Canvas rendering, WebGL output, and user agent to create a persistent cross-session identifier
• Setting any persistent identifier on the visitor's browser, regardless of how it is labelled

Does not, by itself, trigger the classic Article 5(3) consent requirement (see the EDPB nuance below):

• Server-side processing of the HTTP request (IP address, user agent, referer header) that never writes to the browser
• A daily-rotating cryptographic hash computed server-side that is never sent back to the browser as a cookie or stored value
• Aggregating page view counts in a server-side database with no browser-side identifier

The critical question is not "is this analytics?" but "does my analytics tool store anything on the visitor's browser, or read a stored identifier back from it?"

What EU authorities say about analytics exemptions

Several EU data protection authorities have published guidance on audience measurement tools that may qualify for a consent exemption. These positions vary by member state and are subject to change — always verify against the current published guidance from your own authority.

CNIL (France): the French data protection authority has published a framework (CNIL guidance on analytics cookies, cnil.fr) recognising that certain analytics tools may be exempt from the consent requirement under specific conditions. These conditions include: the purpose is strictly limited to measuring the audience for the publisher; the data is not cross-referenced with other processing; the tool is not used to track individuals across sites or over time; and an opt-out mechanism is provided. The CNIL has also indicated that the analytics provider must be contractually prohibited from reusing the data for its own purposes.

AEPD (Spain): the Spanish data protection authority has published guidance (AEPD guide on cookies, aepd.es) covering the conditions under which analytics cookies may be considered exempt from prior consent. The analysis turns on whether the tracking is cross-site, whether individuals can be re-identified, and whether the data leaves the publisher's control.

German DPAs: German supervisory authorities have historically taken a stricter position, generally not recognising an analytics exemption equivalent to the CNIL's approach. If your primary audience is German, consult the relevant Landesbeauftragter für Datenschutz guidance directly.

Key pattern across published guidance: exemptions, where they exist, are narrow. They typically require: no cross-site tracking, no individual re-identification, short-lived or aggregate identifiers, first-party data only, no onward data sharing, and an accessible opt-out. Tools that meet all of these conditions for strictly limited audience measurement may qualify — but the qualification is fact-specific and the authority in your jurisdiction has the final word.

Checklist: evaluating your current analytics tool

Use these questions to assess whether your analytics tool triggers the ePrivacy consent requirement:

Browser-side operations

• Does your analytics tool set any cookie? Check the browser developer tools Network tab (look for Set-Cookie headers from your analytics domain) and Application tab (Cookies).
• Does your analytics tool write to localStorage, sessionStorage, or IndexedDB? Check the Application tab in browser developer tools.
• Does your analytics tool use Canvas, WebGL, AudioContext, font enumeration, or other fingerprinting vectors? Check the tool's documentation and the network requests it makes.

Cross-site and data sharing

• Does your analytics tool track visitors across multiple domains or websites? Review the privacy policy and data processing documentation of your provider.
• Does your analytics provider use your analytics data for its own purposes (advertising, benchmarking, model training)? Review the DPA and terms of service.
• Is data transferred outside the EU? If the analytics provider is US-based or uses US infrastructure, EU-US data transfer rules apply (European Court of Justice Schrems II ruling, CJEU 2020).

Opt-out and transparency

• Can visitors opt out of analytics tracking? If you are claiming an exemption in a jurisdiction that requires it, an accessible opt-out mechanism is typically mandatory.
• Is your analytics data collection described accurately in your privacy policy?

If you answer "yes" to any of the browser-side operation questions, your analytics tool likely triggers Article 5(3) of the ePrivacy Directive and requires prior consent for EU visitors in most jurisdictions.

What cookieless analytics changes — and what it does not

A cookieless analytics tool that operates server-side, uses no persistent browser identifiers, and performs no fingerprinting is designed to avoid the ePrivacy Article 5(3) consent trigger for the analytics layer specifically — subject to the jurisdictional nuance discussed above (EDPB Guidelines 2/2023 and your DPA's exemption conditions).

Atriqo is a privacy-first, cookieless web analytics tool, hosted in the EU (Germany), built as a GDPR-native-by-design alternative to Google Analytics.

Atriqo's session identification works as follows: when a page loads, the server receives the HTTP request. It computes a cryptographic hash of the visitor's IP address, user agent, and a daily-rotating salt. The raw IP is discarded immediately. The hash changes every 24 hours, making cross-day individual tracking impossible by design. No cookie is set. No identifier is written to the browser. No cross-site tracking occurs — each site's data is siloed.

What this changes:

• The classic Article 5(3) consent trigger for the analytics layer is avoided by design: no identifier is written to the visitor's browser and no stored tracking identifier is read back from it. (For transparency: the tracker script does read standard page context — current URL, referrer, screen width, language — and checks the visitor's opt-out flag and the Do Not Track setting before sending anything. What it never does is store an identifier or read one back.) Whether this means no consent is required, or that your configuration fits a national audience-measurement exemption, depends on your jurisdiction and your DPA's guidance — this is Atriqo's position, not a guarantee (see "Facts vs interpretation" below).
• No EU-US transfer question for the analytics data, because the analytics infrastructure is hosted in the EU (analytics infrastructure in Germany — Hetzner, Falkenstein).
• No need for Google Analytics consent mode configuration or CMP integration for the analytics tool itself.

What this does not change:

• If you run a Meta pixel, Google Ads tag, YouTube embeds, or any other third-party script that places cookies or accesses browser storage, those scripts each carry their own consent obligations independently of your analytics tool.
• The legal analysis under GDPR still applies to the pseudonymous session identifiers Atriqo processes server-side. GDPR does not require consent for all analytics, but it does require a lawful basis and appropriate disclosures in your privacy policy.
• Atriqo does not make your site GDPR-compliant. It reduces the analytics-specific friction. The compliance picture for your site depends on your full vendor stack.

For Atriqo's technical methodology, see our privacy documentation.

Getting started with Atriqo

The free tier — 10,000 billable events per month (a billable event is any tracked event: pageview, outbound click, file download, 404, or custom event), no credit card required, no expiry — is available at launch.

If you want early access, join the waitlist.

This article is for informational purposes only and does not constitute legal advice. For specific guidance on your site's compliance obligations, consult a qualified legal professional familiar with EU data protection law and the published positions of the data protection authorities in your jurisdiction.