How Cookie-Free Analytics Works — and Why You Don't Need a Consent Banner
A technical explanation of what “cookie-free” actually means for us, what really happens in the browser and on the server, and why aggregate first-party audience measurement doesn't fall under the ePrivacy consent requirement.
Almost every site today ships a cookie banner “just to be safe” — including for an analytics tool that does nothing more than count visits. It's a precaution born from a misunderstanding, and one that has a real cost: every click on “Decline” in a consent banner is traffic you no longer see in your dashboard. This article explains exactly what we do technically, why we classify this as audience measurement exempt from consent, and precisely where that exemption ends.
What “cookie-free” actually means, technically
The tracking script (tracker.js, under 1KB) doesn't set any cookies. To group activity by the same visitor, it stores a single random identifier (a UUID generated with crypto.randomUUID()) in localStorage, under the key _ana_vid. This is an important distinction, not just a semantic one: localStorage is isolated per origin — your domain can't read the ID stored by another site, and no other site can read yours. There's no cross-site sharing mechanism at all (it's not a third-party cookie, and it's not a pixel loaded from a central domain that could correlate visits across different sites, the way ad networks do).
On the server, that ID is hashed and stored as visitorHash on the Visitor row — never as a raw string, and never linked to a name, email, or other account identifier (unless the visitor is already logged into your account, in which case you have a separate lawful basis for account data anyway). The visitor's raw IP address never reaches the database: it's used exactly once, in memory, to resolve country/region/city through a geolocation lookup, then discarded. What actually gets stored is only country/region/city — enough for an aggregate report like “X visitors from Romania,” not enough to identify a person.
How a session forms, without a session cookie
Many “cookie-free” tools still set a technical cookie for the duration of the session, just to link pageviews together. We don't do that either. On every pageview, the server looks up the same visitorHash's most recent session on that site: if the last activity was less than 30 minutes ago, the new event is attached to the existing session; otherwise a new session is created. That's the same 30-minute inactivity window Google Analytics uses — an industry-standard compromise, not something stored on your device, but calculated from the timestamps of events already received.
The practical result: if someone visits your site today and comes back in three days, their localStorage still holds the same visitorHash (so you correctly see “returning visitor” instead of “new visitor”), but the sessions are distinct — exactly as if you had a session cookie, except you don't.
Why you don't need a consent banner
The ePrivacy Directive (transposed into each member state's law as the “cookie law”) requires consent to store or access information on a user's terminal equipment — cookies, localStorage, fingerprinting, any equivalent technique — except in two cases: (1) it's strictly necessary for a service the user explicitly requested (e.g., a shopping cart, authentication), or (2) specific exemptions that national data protection authorities have clarified over time for “low privacy risk” cases.
First-party audience measurement is the canonical exemption case discussed by data protection authorities in several member states, most explicitly by France's CNIL: an analytics tool can be exempt from consent if it meets several conditions simultaneously.
- The data is used exclusively by the site operator, solely for audience statistics — not for advertising, profiling, or resale to third parties.
- There's no cross-site tracking: the identifier can't be read or correlated by another domain.
- The data is aggregated / pseudonymized as soon as possible, not used to reconstruct a specific person's path.
- The retention period is limited, not indefinite.
- The visitor has a real way to opt out of tracking, and that opt-out is respected.
No cookies, no cross-site tracking, no advertising profiling, with limited retention — the tool is built exactly for the conditions above, which means it doesn't trigger the ePrivacy banner requirement for plain traffic measurement.
ePrivacy isn't the whole of GDPR
The exemption above is about STORAGE consent on the device (ePrivacy), not about GDPR as a whole. Even without cookies, you're still processing personal data (a pseudonymous identifier, an approximate location), and you still need a lawful basis for that — typically legitimate interest, not consent. We break down exactly what that involves in our GDPR compliance guide.
Where the exemption stops
The exemption isn't a universal pass for any script you put on your site. It breaks the moment you combine traffic data with:
- Advertising pixels (Meta Pixel, Google Ads remarketing) — these build cross-site profiles for targeting, exactly what the exemption explicitly excludes.
- Aggressive fingerprinting (canvas fingerprinting, combinations of device signals unique enough to re-identify a person without localStorage).
- Sharing raw data with a third party that uses it for a purpose other than your own audience statistics.
- Indefinite or unlimited retention of data at the individual visitor level.
If at some point you add a retargeting pixel to your site alongside this tool, that pixel needs its own separate consent banner — not because we've changed anything, but because that pixel doesn't qualify for the same exemption.
Note: this is an informational summary, not legal advice. The exact interpretation of ePrivacy varies slightly from one member state to another, and your country's data protection authority is the final word for your specific case.