Cookieless tracking in 2026: what actually still works

Third-party cookies are effectively finished, and the replacements have sorted themselves into two groups that get discussed as though they were one. The first group measures without identifying anyone. The second identifies people through a mechanism that is not a cookie, and is marketed as "cookieless" on that technicality.

Both are cookieless. Only one of them removes the compliance obligation, and the difference is worth understanding before choosing a vendor on the strength of the word.

What actually broke

Worth being precise, because the deprecation was narrower than the coverage suggested. What ended was the third-party cookie — one set by a domain other than the one in the address bar, which is what made cross-site tracking work.

First-party cookies still function. Safari's ITP caps JavaScript-set ones at seven days, and Firefox partitions them, so "still function" means something weaker than it did — a returning-visitor measurement built on a first-party cookie is substantially wrong on Safari and has been for years, quietly.

The four substitutes

Rotating hashes

Derive an id from request characteristics, salt it with a value that is thrown away and regenerated daily, and never store anything on the device.

Server-side

// A daily-rotating visitor id. No storage on the device,
// nothing to consent to, and it stops being linkable at midnight.
const visitorHash = sha256(
  dailySalt +        // regenerated every 24h, old salt discarded
  siteId +
  clientIp +         // hashed here, never stored raw
  userAgent
);

// What this buys: unique visitors per day, sessions, entry pages.
// What it costs: a returning visitor next week is a new visitor.

Nothing is written to the device and nothing is read from it beyond what the browser volunteers in an ordinary request, which is what keeps this outside 5(3). The cost is real and should be stated plainly: a visitor returning after the salt rotates is counted as new. Daily uniques are accurate. Monthly uniques are inflated, and cross-day retention is not available at all.

That is a genuine loss. It is also the honest price of not tracking people, and for most sites the metrics it costs were being read less often than the ones it preserves.

Fingerprinting

Combine enough device characteristics and the combination is unique. No storage is involved, which is the basis for calling it cookieless.

Client-side

// A fingerprint. Every line here is a signal that persists
// across days, which is precisely what makes it a legal problem
// rather than a technical one.
canvas.toDataURL()          // GPU + driver + font rendering
audioContext                // hardware audio stack
navigator.hardwareConcurrency
screen.width + screen.height + colorDepth
Intl.DateTimeFormat().resolvedOptions().timeZone
installedFonts              // enumerated via measurement

// Stable for months. Survives clearing cookies. Requires consent
// under ePrivacy in exactly the same way a cookie does.

This is the one to be careful about. It is stable across days, survives clearing site data, and cannot be opted out of by the visitor — which makes it more invasive than the cookie it replaced, not less. Regulators have addressed it directly and the position is settled: it needs consent.

A vendor selling "cookieless, no banner required" on top of fingerprinting is selling you a compliance position that does not hold. Ask what generates the identifier, and whether it is stable across days. That single question separates the two groups.

Server-side and first-party proxying

Route collection through your own domain so requests are same-origin.

Proxy routes

# Serving the tracker from your own domain.
# Fixes blocker evasion. Fixes nothing legal.

/js/script.js      ->  proxied to your analytics vendor
/api/event         ->  proxied to your analytics vendor

This genuinely helps with blocker evasion, and it changes nothing about your legal position — the obligation attaches to what you do with the data, not to which hostname received it. Proxying a fingerprinting vendor through your own domain gives you a fingerprinting vendor on your own domain.

Aggregate-only measurement

Store counts rather than rows. No visitor identifier of any kind: a pageview increments a counter for a path, a referrer, a country, a device class.

This is the strongest position available and it is more usable than it sounds, because the questions most sites actually ask — which pages grew, where traffic came from, what converts — are answered by aggregates. Cohort retention and individual journeys are not, and if you need those, you need an identifier and should choose one deliberately.

Choosing between them

The decision reduces to one question: does your analytics need to recognise the same person on a later day?

• No. Rotating hashes or aggregates. No banner, no consent dependency, no undercount from declines, and the numbers are the numbers.
• Yes, for logged-in users. Use your own account id. You already have a lawful basis for processing your customers' data, and it is far more accurate than any inferred identifier.
• Yes, for anonymous visitors. You are asking for persistent identification of people who have not identified themselves. That needs consent, and you should build for a consent rate around a third rather than assume the banner is a formality.

The trade, stated plainly

Cookieless measurement done honestly loses cross-day identity. Anyone claiming otherwise is either fingerprinting or measuring logged-in users and describing it imprecisely.

What it gains is worth more than it is usually credited for. Consent declines stop removing a third of your traffic. Blocker rates fall because there is no third-party request to block. And every number is a count of something that happened rather than a model of what probably happened — which, for anyone who has tried to reconcile two analytics tools, is not a small thing.