Cookieless analytics, explained — no banner, still GDPR-clean

Every analytics vendor has a slide that says "privacy-first." Most of them still drop a cookie that lives on your visitor's machine for two years. Cookieless analytics is the version where the engineering actually backs the marketing: no cookies, no device storage, no persistent identifier following anyone around the web. You still get sessions, unique visitors, funnels, and retention — just computed in a way that forgets people by design. Here's how it works, why it stays GDPR-clean without a consent banner, and what you genuinely give up to get there.

What "cookieless" actually means

Cookieless is a precise claim, not a vibe. A truly cookieless analytics tool:

• Writes no cookies — not first-party, not third-party, not "essential" ones used as identifiers.
• Writes nothing to localStorage or sessionStorage that identifies the visitor.
• Assigns no persistent device ID — no fingerprint stored, no random UUID stashed on the device and reused tomorrow.
• Does no cross-site tracking — your visitor on site A is unknowable to site B.

Contrast that with cookie-based analytics. Google Analytics, for example, sets a _ga cookie containing a client ID — a random identifier like GA1.2.1234567890.1680000000. That cookie has a default expiry of two years. Every visit, GA reads it back, recognizes the same client ID, and stitches today's session to one from eight months ago. That persistence is the whole point of a cookie ID: it makes the visitor durable across days, weeks, and devices that share a login. It's also exactly the thing privacy regulation cares about.

Cookieless throws that durable identifier away. The interesting question is how you still count a "unique visitor" when you've deliberately refused to remember anyone.

How you get sessions and uniques without cookies

The technique is well established — it's what Plausible, Fathom, and TrackWhy use, with minor variations. Instead of storing an ID on the device, you derive one on the server from signals you already see in every request, then hash them with a secret that you throw away every day.

Conceptually:

visitor_id = sha256(daily_salt + site_domain + visitor_ip + user_agent)

Walk through the inputs:

• daily_salt — a random secret generated fresh every 24 hours and held only in memory/short-lived storage.
• site_domain — scopes the hash to one site, so the same person on two different sites never collides into one identity.
• visitor_ip — present on every HTTP request; never written to disk.
• user_agent — the browser/OS string, also on every request.

You run those through SHA-256 and get a fixed-length, opaque fingerprint for this visitor, on this site, today. Two requests from the same person within the same day produce the same hash, so you can group them into a session and count one unique. A request from someone else produces a different hash. No device storage required.

The load-bearing part is the daily salt rotation. At midnight (or on a rolling 24h window), you generate a new salt and discard the old one. From that moment, yesterday's hashes are permanently unlinkable to today's:

• The salt is secret, so the hash can't be reverse-engineered into the original IP and user agent. SHA-256 is one-way, and without the salt you can't even brute-force the small input space.
• Because the salt is gone, the same visitor returning tomorrow computes a different visitor_id. There is no key anywhere that says "these two hashes are the same human."

That's the privacy property in one sentence: a "unique visitor" is really a unique visitor per day. You can count how many distinct people showed up today, and reconstruct their journey within the day, but you structurally cannot follow an individual from one day to the next. The data model can't betray someone it never had the means to remember.

Why this stays GDPR / ePrivacy / CCPA-clean

A few things line up here, and they're worth keeping straight because they come from different laws.

The ePrivacy Directive — the actual "cookie law" — is what makes banners appear. It requires consent before you store or access information on a user's device for non-essential purposes. The trigger is the storing/reading on the device, not the analytics itself. A cookieless tool never writes or reads device storage for tracking, so that trigger isn't pulled. No storage access, no consent requirement under that provision, no banner.

GDPR governs personal data. The salted-daily-hash approach is designed so that no personal data lands in your store: the raw IP is used transiently to compute the hash and then discarded — it is never persisted — and the resulting visitor_id can't be tied back to a person once the salt rotates. No names, no emails, no durable identifier, no cross-site profile.

CCPA/CPRA centers on selling/sharing personal information and building cross-context behavioral profiles. With no persistent ID and no cross-site linkage, there's nothing to sell and no profile to share.

A careful caveat, because this is law and not a build flag: this is the widely-accepted basis that cookieless tools rely on, and consent for strictly necessary processing generally isn't required. But "GDPR-clean" depends on your full setup — what else you log, your data-processing agreements, your jurisdiction. None of this is legal advice. Confirm your specific configuration with your DPO or counsel before you tear down the banner.

The tradeoffs, honestly

Cookieless is not free. If anyone tells you it's strictly better with no downside, they're selling, not engineering.

What you give up:

• Cross-day individual journeys. You can't follow one specific person across multiple days. Within a day, yes. Across the boundary, no.
• Persistent user-level cohorts spanning days. "Users who signed up Monday and came back Thursday" as an individually-tracked cohort isn't reconstructable from the raw identifier the way cookie IDs allow.
• Unique visitors resets daily. Your daily-unique count is honest, but it is not a rolling distinct-humans-over-30-days figure built from one durable ID.
• Cross-device stitching is impossible. Same person on phone and laptop = two visitors. By design.

What you gain — and this is the trade most teams should take:

• Trust. Visitors aren't tracked, and you can say so without an asterisk.
• No banner friction. Consent banners measurably depress traffic and conversions: people bounce on the modal, and the ones who reject analytics vanish from your numbers entirely. Cookieless removes the banner and the blind spot it creates.
• Simpler compliance. Less personal data is less risk, fewer DPAs, less surface area for a complaint.
• Smaller, faster pages. No cookie plumbing, no consent SDK, less JavaScript shipped to every visitor.

Where TrackWhy lands

TrackWhy is cookieless by default — there's no setting to remember to turn on. The script is 1.7 KB, which is small enough that it doesn't show up in your performance budget. Web-vitals and JavaScript error capture are opt-in, so the baseline payload stays tiny and you only pay for what you switch on.

And within the daily session model, you still get the analysis that actually drives decisions: funnels, retention, and path analysis. Cookieless constrains the cross-day individual view; it does not turn your analytics into a glorified hit counter.

Myth-busting, briefly

• "Cookieless means inaccurate." False. The daily salted hash counts uniques and sessions reliably. Meanwhile cookie-based numbers get gutted by consent rejection and tracker-blocking — the banner is often the bigger source of inaccuracy.
• "You can't do funnels without cookies." False. Funnels and paths live inside a session; the session is exactly what the daily hash gives you. TrackWhy does both.
• "No cookie means no real data." False. You lose cross-day individual stitching, not aggregate truth. For most product and growth questions, the aggregate is the answer.
• "Cookieless is a legal gray area." It's the basis mainstream privacy-first tools already run on. Just verify your own configuration — don't assume.

The short version

Cookieless analytics swaps a two-year device ID for a hash that's deliberately forgotten every midnight. You trade cross-day individual tracking for trust, speed, and a banner you never have to ship. For the overwhelming majority of teams, that's not a compromise — it's the upgrade. Analytics with teeth, and nothing in its pockets.