Cookieless tracking explained

Cookieless tracking is the idea that you can measure a website without writing identifiers into the visitor's browser. Instead of storing a cookie and reading it on the next visit, a cookieless tool derives what it needs from the request itself and throws the detail away. It sounds like a small technical difference. In practice it changes what you can measure, what you must ask permission for and how accurate your numbers are.

This article explains how cookieless analytics actually works, without marketing claims. The goal is that you understand the trade-offs well enough to choose a tool and to explain the choice to a colleague or a client.

The traditional cookie model

A classic analytics tool sets a cookie containing a random identifier. On the next page load it reads that identifier back, recognises the same browser and adds the new pageview to the same profile. That is how it counts unique visitors across days, stitches together multi-session journeys and attributes a purchase to a visit from a week ago. The identifier is not your name, but it is a stable handle tied to a device, and that is why it triggers consent requirements in many jurisdictions.

How cookieless tools work instead

A cookieless tool receives each request and computes a short-lived hash from signals available in that request, such as the IP address, user agent and a rotating daily salt. The hash lets it tell a new visit from a repeat view within a short window, without storing anything on the device. Crucially, the hash rotates: once the salt changes, yesterday's hash no longer matches today's, so the tool cannot follow a visitor over time.

Nothing persistent is written to the browser. No identifier is kept indefinitely. The raw IP is used to compute the hash and is not stored. That design is why a cookie-free tool can run without a consent banner in most setups: there is no device storage to consent to and no personal profile being built.

What cookieless tracking does well

• Counting pageviews and visitors over short windows.
• Referrers, UTM campaigns and traffic channels.
• Device, browser, screen size and language breakdowns.
• Core Web Vitals such as LCP, INP and CLS.
• Custom events like signups, downloads and outbound clicks.

What it cannot do

Without a persistent identifier, some things are genuinely harder or impossible. Long-term unique-visitor counts drift, because the same person can be counted again after the hash rotates. Cross-session journeys — someone clicking an ad on Monday and buying on Friday — are not attributable to the same person. Cross-device identity is out. And any workflow that depends on recognising an individual across weeks, such as ad frequency capping, is simply not a fit.

For an ad platform these gaps are disqualifying. For most websites they are not. The vast majority of traffic questions — which pages are read, which channels bring people, which devices they use, whether the site is fast — do not need a persistent identifier at all.

The accuracy trade you are making

Cookieless numbers are usually lower than cookie-based ones, and that is by design. Bots are filtered, ad-blocked requests never arrive, and there is no attempt to infer around missing data. The remaining number is closer to real people, even though it is smaller. If you are used to a cookie-based tool, expect a gap and resist the urge to treat the higher number as the truth.

The other trade is completeness versus consent. A cookie-based tool with a banner measures only the visitors who accept. A cookieless tool measures almost everyone who loads the page. In many cases the cookieless tool ends up with more usable data, not less — just a different kind of data.

How to choose

If your main needs are traffic, content performance, campaigns and page speed, cookieless analytics is enough and it is simpler to run. If you need advertising attribution, cross-device journeys or long-term individual identity, you still need a consent-based stack — and you should be honest about the complexity and trust cost that comes with it. Choose based on the questions you actually ask, not the capabilities on a feature list.

How the rotating hash works in practice

The magic is a salt that changes on a schedule, often daily. The tool hashes a few request signals together with that salt, uses the result to recognise a visit within the window, and discards the inputs. When the salt rotates, the old hashes no longer match, so the same person cannot be linked across days. This is why cookieless tools can count a session without storing anything on the device, and why they cannot build a long-term profile. The security of the approach depends on the hash being non-reversible and the salt being secret and rotated; a well-built tool is explicit about both.

What to tell your visitors

Even where no banner is required, a short privacy-policy note builds trust. Say that analytics is cookie-free, that no personal data is stored, and name the vendor and the retention window. Link to the vendor's documentation so a curious visitor can check the claim rather than taking your word for it. This is especially valuable for privacy-conscious audiences, who are often the same people who would otherwise block your analytics. Transparency costs a paragraph and buys credibility that no badge can. Keep the note short and specific: what is collected, what is not, how long it is kept and where the vendor is based. If the tool offers a data-processing agreement, mention that your business has one. These details are exactly what a privacy-conscious buyer or client will ask for, and having them ready turns a potential objection into a small demonstration of competence. A privacy page that names the tool, the data and the retention window is short, accurate and reassuring, and it takes less time to write than a banner takes to design. It is also the first thing a client or auditor will read, so make it clear and specific.