What cookieless actually means
Cookieless analytics is analytics that measures your traffic without storing a persistent identifier on the
visitor’s device — no cookie, no localStorage entry, nothing that survives the page. The term is
slightly misleading: the cookie was never the point. What matters legally and ethically is whether something on the
device can be read back later to recognise the same person, and a localStorage key does that just as
well as a cookie does.
That distinction is why the ePrivacy Directive — the rule that actually produces consent banners — is written about storing or accessing information on a user’s device, not about cookies specifically. Remove the storage and you remove that trigger. You do not remove GDPR, which governs what you then do with the data. The two are separate questions and conflating them is the most common mistake in this area; the GDPR compliance guide works through both.
The three ways to measure without cookies
Every cookieless tool takes one of three approaches, and they are not equivalent. Vendors tend to use the same word for all three.
1. No identifier at all
The simplest option: record the event, attach no identity, and report only aggregate counts. You get pageviews, top pages, referrers and totals. You cannot get unique visitors, sessions, funnels or retention, because every one of those requires knowing that two events came from the same person. This is honest and cheap, and it is why the most privacy-aggressive tools report so few metrics.
2. A rotating, derived identifier
The middle path, and the one most privacy-focused analytics tools actually use. The server derives an identifier from data the HTTP request already carries — typically the IP address and User-Agent — by running it through a keyed hash with a secret that rotates on a schedule, usually daily. Within the day, the same visitor produces the same identifier, so sessions and unique counts work. Once the secret is rotated and destroyed, the identifiers become unlinkable, and yesterday’s visitor cannot be matched to today’s.
The rotation is doing the real work here. A plain hash of an IP address is not anonymisation: there are only about four billion IPv4 addresses, so anyone holding the hashes can compute the hash of every possible address and match them back in minutes. A secret salt defeats that, and rotating and deleting the salt is what makes the guarantee hold over time rather than just until the secret leaks.
3. Fingerprinting
The one to be careful about. A fingerprint combines device characteristics — screen resolution, installed fonts, canvas rendering quirks, hardware concurrency — into an identifier engineered to be stable, so the same device is recognisable weeks or months later. It stores nothing on the device, so it is technically cookieless, and it is routinely sold under that label.
Rotation is the whole distinction. A rotating identifier is designed to stop working; a fingerprint is designed not to. Everything else about them is similar, which is exactly why the word “cookieless” cannot be trusted on its own.
Regulators settled this a while ago. The Article 29 Working Party’s Opinion 9/2014 held that fingerprinting falls inside the scope of the same ePrivacy rule that governs cookies, and the EDPB’s Guidelines 2/2023 restated it — Article 5(3) is not about cookies specifically, and reaches tracking pixels, tracking links and device fingerprinting alike. Adopting a fingerprinting tool to escape a consent banner therefore tends to land you in a worse position than the cookie you were avoiding, not a better one.
What cookieless costs you in measurement
This is the part the category’s marketing pages skip, and it is the reason cookieless has historically belonged to web analytics rather than product analytics. A daily-rotating identifier is a new person every midnight. If you feed those identifiers into metrics that count people, the numbers do not degrade gracefully — they break in specific, predictable ways:
- Unique users inflate. A visitor who comes back on five days is counted as five people. The longer the reporting window, the worse the error.
- Per-user averages deflate. The denominator is inflated by the same factor, so “events per user” drifts toward one.
- Funnels leak at every day boundary. A signup flow that spans a night sees the person who came back to finish as a stranger who started at step two.
- Retention collapses to zero. Retention cohorts ask whether the same person returned on a later day. With rotating identifiers, the answer is structurally no — the metric returns approximately zero regardless of how good your product is.
- User flows fragment. Path analysis stitches one person’s journey; rotating identifiers cut it nightly.
What does not break is just as important. Total event counts are fine — a consent-declining visitor’s pageview is still a pageview, and excluding it would under-count your traffic. Session metrics are fine too, because a session is stitched from activity within a short window and never needs to know who the person is across days.
So the correct handling is not better hashing. It is to keep cookieless traffic in the metrics that count events and sessions, and keep it out of the metrics that count people — and to be explicit about which is which, so nobody reads an inflated unique-user chart as growth. What cookieless tracking does to funnels and retention works through each metric and the split in full.
Does it remove the consent banner?
For the analytics itself, often yes — if nothing is stored on or read from the device, there is nothing for the ePrivacy storage rule to attach to. That is a real and meaningful reduction in obligation, and it is why cookieless tools can report on close to 100% of traffic while consent-gated tools see only the share of visitors who click accept.
Two caveats worth stating plainly. First, GDPR still applies to the processing: an IP address is generally personal data, so using one as a hash input is processing that needs a lawful basis, transparency and minimisation, even when the input is never stored. Second, a banner covers your whole site, not one vendor — embedded video, ad pixels, chat widgets and A/B testing tools routinely set their own identifiers, and any one of them puts the banner back. Requirements vary by jurisdiction; this is general guidance, not legal advice.
How Pug does it
Pug’s Web SDK defaults to cookieless. It has three consent states and the
default is the middle one: events flow, nothing is written to the device, and identify() is disabled,
so an install that never mentions consent still stores no identifier before it has a basis to.
// the default — no configuration needed to stay cookieless
init(projectId, { apiKey })
// once the user agrees, via clear affirmative action:
optInTracking()Server-side, a visitor with no stored identity is given an ephemeral one derived from the request: a keyed hash (HMAC-SHA256) of the project, IP address and User-Agent, under a salt that changes every day. The IP and User-Agent are hash inputs only — they are never stored on the event and never returned by the API. The day’s salt is held under a TTL and deleted when it expires, and that deletion is the guarantee: once it is gone, the identifiers minted with it can no longer be linked to any IP or User-Agent, or to each other, by anyone. Sessions are stitched server-side on a 30-minute inactivity window, so session metrics stay correct without any device storage.
These identifiers carry a reserved cookieless- prefix so every part of the system can recognise them
from the value alone. That is what makes the measurement rule above enforceable rather than aspirational: they are
excluded by default from unique users, per-user averages, funnels, retention, user flows and user-level top-K, and
always included in total event counts and every session metric. The query API carries an
include_cookieless flag for the cases where you deliberately want them back in. In the events table and
live feed they render as cookieless with no profile link, because there is no profile to link to — an ephemeral
identifier is not a person, and the interface should not imply otherwise.
When a visitor does consent, identify() merges their anonymous history into a real profile, and
identity resolution takes over from there. Cookieless is the floor, not
the ceiling.
Choosing an approach
- Ask what the identifier is derived from, and how often it rotates. “Cookieless” with no rotation is fingerprinting with better branding.
- Ask whether the salt is deleted or merely changed. A retained history of old salts re-links everything it was supposed to separate.
- Ask whether IP and User-Agent are stored. Using them as hash inputs is very different from keeping them on the event.
- Check how unique users are counted. If a tool reports uniques from rotating identifiers without saying so, its headline number is inflated and you will not be told by how much.
- Decide what you need people-level metrics for. If funnels and retention drive your decisions, plan for a consent path rather than expecting cookieless to cover it.
- Control where it runs. Self-hosting means the IP never reaches a third party at all, which is a stronger claim than any hashing scheme.
Cookieless is a genuinely good default — it lets you measure honestly on day one, with nothing on the device and nothing to consent to. It just is not a free replacement for identity, and any tool that tells you otherwise is either not counting people or not telling you how. For the broader practice around it, see privacy-first analytics, and for auditing what your events actually carry, the free PII event auditor.