How it works
Cookieless analytics, and how counting actually works
A word that has been stretched until it means very little. Here is what it should mean, how a visitor is counted without an identifier, and the three things it genuinely costs you.
The word
Four things "cookieless" is taken to mean, and one it should
Three of the four techniques below set no cookie and identify people anyway. The absence of a cookie is a statement about one storage mechanism, not about privacy.
-
Cookieless is not consent-free
Article 5(3) of the ePrivacy Directive is triggered by storing information on, or reading information from, the visitor’s device. A cookie is one way to do that.
localStorage, IndexedDB, a cache-timing probe and a device fingerprint are others, and every one of them needs consent on the same footing. The absence of a cookie tells you almost nothing on its own. -
Cookieless is not anonymous
A tool can set no cookie and still hold a durable, server-side identifier derived from the request — one that follows a person across days, and sometimes across sites. That is pseudonymous data, fully in scope under the GDPR, and it is a stronger form of tracking than the cookie it replaced, not a weaker one.
-
Fingerprinting is the opposite of the point
Assembling fonts, canvas output, screen geometry and hardware details into a stable identity is cookieless by construction and is the most invasive technique in common use, because the visitor cannot see it, cannot clear it and cannot refuse it. Regulators treat it as equivalent to a cookie; browsers are actively working to break it.
-
What it should mean
Nothing is written to the device, nothing durable is retained on the server, and the system is incapable of joining one person’s visits across days or across sites — not merely configured not to. That is a testable claim, and the rest of this page is how it is met here.
The mechanism
How a visitor is counted without being identified
The IP address is read once, in memory, and is gone before the reply is sent. What survives the request is a token that expires with the day.
01 Seen in memory, for one request
- IP address
203.0.113.42local variable, one request - User agent
Mozilla/5.0 (Macintosh…never stored raw
02 One-way function
03 All we keep
9f3a71c4e0b58d2a6c81d4f7 An opaque token, scoped to one site for one day. Nothing links it to a person, to a device, to the same visitor tomorrow, or to the same person on another site running this product.
04 Discarded before the response
203.0.113.42never writtenMozilla/5.0 (Macintosh…parsed, then dropped
No IP address reaches a log, a database, an analytics pipeline or an object store. It exists as one local variable and goes out of scope with the request.
Every day, yesterday becomes unrecoverable
Tokens rotate daily, and the previous day's cannot be recomputed — not by us, not by anyone who obtained the database, not under a court order. So yesterday's visitors cannot be joined to today's. Cross-day tracking here is not switched off by policy; it is arithmetically impossible, which is the only kind of promise worth making.
Three properties make the guarantee, and each is checkable from outside: the token is one-way, so it cannot become an IP address again; it is scoped to one site, so the same browser elsewhere on this network is a different token; and it rotates daily and cannot be recomputed for a past day, so there is no key that would join last month together. You can verify the first half from your own browser — no cookie is set, nothing identifying is written to storage, and the entire request is readable in a network tab.
The trade
Three things you give up
Two of these are arithmetic rather than engineering: they follow from refusing a durable identifier and cannot be fixed without becoming the thing this product exists not to be. We would rather you read them now than find them in month two.
- 01
Unique visitors across a date range
A visitor is unique within a day, because the token that recognises them expires with the day. Ask for uniques over a month and the honest answer is a sum of daily figures, which overcounts anyone who came back. We label it as a sum rather than quietly presenting it as a de-duplicated total, and every tool that gives you a clean 30-day unique count is holding an identifier that lasts 30 days.
- 02
The individual journey
There is no "this person visited on Tuesday, read three pages, came back on Friday and converted". Paths are aggregated across visitors, so you can see that a route is common; you cannot replay one person walking it. If per-user timelines are what your team works from, this is the wrong category of tool, not the wrong vendor in it.
- 03
Long-window attribution
A 30-day or 90-day lookback that connects today’s purchase to an ad clicked six weeks ago needs an identity that survived six weeks. Ours does not exist for longer than a day. Source and campaign are captured at the visit that produced the conversion, which answers most questions honestly and does not answer that one at all.
Everything else survives intact: pageviews, visits, sources, campaigns, countries, devices, entry and exit pages, goals, revenue, realtime, and click and scroll maps. If you want the fuller account of what is collected field by field, it is in the compliance documentation. And if you are weighing this against what you have now, eight questions for judging any alternative is the shortest route to a decision.
How do you count returning visitors without a cookie?
With a token derived from the request and a salt that rotates daily, scoped to one site. It is one-way, so it cannot be turned back into an IP address; yesterday’s cannot be recomputed, so yesterday’s visitors cannot be joined to today’s; and the same person on another site running this product produces a different token. Within a day it recognises a returning browser accurately. Beyond a day it is gone, by construction rather than by policy.
Is cookieless analytics accurate?
More accurate than the cookie-based tool it replaces, on most sites, for a reason that has nothing to do with the technique: every mainstream blocklist carries the major analytics domains, and blocked requests are simply missing from those reports. Our script is 1270 bytes and far less widely blocked, so sites running both usually see more traffic reported here. Where it is genuinely less precise is multi-day unique counts — see the trade-offs above, which are on this page rather than in a footnote.
Do I need a cookie banner for cookieless analytics?
Not for a tool that writes nothing to the device and reads nothing from it, because the rule that produces the banner is triggered by that access rather than by the sensitivity of what is collected. You may still need one for everything else on the page — an ad pixel, an embedded video, a chat widget, a tag manager. Removing one script does not remove a banner four other scripts are holding up. The full reasoning is in what makes web analytics GDPR-compliant.
Can cookieless analytics track conversions and goals?
Yes. A conversion is an event that happens during a visit, and the visit is what carries the source and campaign — no durable identity is needed to attribute a purchase to the session that produced it. What it cannot do is attribute it to a click from six weeks ago. Custom events and goals are documented in custom events and goals, and revenue in revenue tracking.
Does it work with a single-page application?
Yes. History-based routing is picked up automatically and hash routing is one attribute. There is no identity to maintain between views, which makes SPA support simpler here than in tools that have to keep a session alive. The details are in the install reference.
How long is the data kept?
15 months on every plan, on every plan, with nothing to configure. Retention is about the aggregated statistics, not about visitors — there is no visitor record to retain, which is why there is nothing here to erase on request.
In this series
Measuring without cookies
How counting works when nothing is stored on the visitor’s device, and what the law asks of you either way.
- What makes web analytics GDPR-compliantTwo laws, in the order a regulator asks them. Sources named throughout.
- Do you actually need a cookie banner?A flowchart, and an audit of every script on an ordinary page.
- Privacy and compliance referenceWhat is collected field by field, and how erasure requests are handled.
- Removing your cookie bannerWhat is actually keeping it there, and the order that gets it done.
- Why returning visitors look newThe key is destroyed every midnight, so nobody links across days.
- Our own privacy policyWritten to the standard we are asking you to hold us to.
Ready
Check it from your own network tab.
Paste one 1270-byte script tag and watch what it sends. No cookie is set, nothing is written to storage, and the whole request is readable.