"Cookieless analytics" sounds like a marketing claim until you see the mechanism, at which point it becomes obvious — and its limitations become obvious with it. Both halves are worth understanding before you rely on the numbers.
The problem being solved
Analytics needs to answer one structural question: were these two pageviews the same person, or two people? Everything downstream — sessions, bounce rate, pages per visit, unique visitors — is built on the answer.
Conventional analytics answers it by giving the browser an identifier and asking for it back on each request. That works across days and across sites, and it is exactly the behaviour that triggers the consent requirement.
Cookieless analytics answers the same question without ever handing anything to the browser.
The mechanism, in full
When a pageview arrives, the server computes:
visitor_id = SHA-256( daily_salt + site_id + ip_address + user_agent )Four inputs, one irreversible output. Each input is doing a specific job.
The daily salt is a random secret regenerated every day and never written to disk — derived at the moment of use from a server-side secret and the current date. It is what makes the identifier expire. On Tuesday the salt is one value; on Wednesday it is another, and the same person hashes to something entirely unrelated.
The site id scopes the identifier to one website. The same person visiting two sites on the same server produces two unrelated identifiers, so nothing can be correlated across sites even by the operator.
The IP address and user-agent are the only things distinguishing one visitor from another. They are used and discarded — never stored, never logged.
The output is a fixed-length hash. It cannot be reversed: even knowing the IP address and user-agent, you cannot verify a match without the salt, and the salt no longer exists tomorrow.
What this makes possible
Within a single day, the identifier is stable, so everything computed inside a day is exact:
- Unique visitors per day — a real count, not an estimate.
- Sessions, stitched from consecutive pageviews by the same identifier with the usual inactivity timeout.
- Bounce rate and pages per visit, both of which need pageviews grouped into visits.
- Time on page, measured as visible time rather than as the gap between requests.
- Entry and exit pages, funnels within a visit, and conversion attribution to the referrer or campaign that started the visit.
That is the overwhelming majority of what anyone looks at.
What this makes impossible, on purpose
- Cross-day identity. A visitor on Monday and Wednesday is two daily visitors. No "returning visitor" metric across weeks, no retention cohorts, no multi-day user journeys.
- Multi-touch attribution across days. A visit from a search on Monday and a purchase from a direct visit on Friday are two unrelated visits.
- Any per-person lookup. Including one you might genuinely want to perform, such as responding to a data subject access request. There is no key that would make it possible, for anyone — which is itself the strongest possible answer to the request.
The last point is the one people underestimate. The design does not merely decline to build profiles; it makes them technically unavailable, permanently, including to whoever obtains the database later.
The obvious objection: shared IP addresses
Two people behind the same office NAT with the same browser version will hash to the same identifier and count as one visitor. Conversely, a phone moving from wifi to mobile data changes IP and counts as two.
Both are real, both are small in aggregate, and both are stable over time — which is what matters. Analytics is used to compare Tuesday with last Tuesday and this campaign with that one. A consistent method with a known bias supports those comparisons perfectly well. A method that is precise about individuals and requires consent from half of them does not, because the missing half is not a random sample.
Why the salt has to rotate daily
A salt that never changed would produce an identifier that was stable forever — a cookie stored on the server instead of the device. It would be pseudonymous rather than anonymous data, and a regulator would treat it accordingly.
Rotation is what converts the identifier from a persistent pseudonym into a same-day-only correlation key. Twenty-four hours is the compromise: long enough to make sessions and daily uniques accurate, short enough that no long-term profile can accumulate. Rotating hourly would break evening sessions; rotating weekly would create a profile worth attacking.
What is actually stored
Per pageview, a row containing: the path and query string, the referring host (never the full referring URL, which can carry search terms and tokens), country and region, device type, browser, operating system, language, any UTM parameters already in the link, a timestamp, and engaged time.
Notably absent: the IP address, the user-agent string, and any identifier that outlives the day. The daily hash itself is kept only as long as the row-level detail is kept — typically a rolling window of a few weeks — while the aggregate totals, which describe no individual at all, are kept indefinitely.
That split is what makes long retention safe. A row saying "on 12 March, /pricing had 412 views from Germany" is not personal data by any reading, and can be kept for a decade without anyone's interest being affected.
Common questions
How does cookieless analytics identify a returning visitor?
It does not, across days. The identifier is a hash of the IP address, user-agent, site id and a salt that is regenerated daily and never stored, so the same person produces a different identifier tomorrow. Within a single day the identifier is stable, which is what makes sessions, bounce rate and daily unique counts accurate.
Is a hashed IP address still personal data?
A hash computed with a secret salt that is never stored and rotates daily is generally treated as anonymous rather than pseudonymous, because no key exists that could reverse it — not even for the operator. The IP address itself, before hashing, is personal data, so its transient processing still needs a lawful basis under the GDPR.
What happens when several people share one IP address?
They are counted as a single visitor if their user-agent strings also match, which happens on office networks and shared connections. The bias is small in aggregate and consistent over time, so period-to-period comparisons remain valid even though the absolute count is slightly low.
Can cookieless analytics measure conversions?
Yes, as long as the conversion happens in the same visit as the traffic that produced it. Conversions are recorded with the full dimension set, so they can be broken down by country, device, referrer or campaign. Attribution across multiple days is what the design gives up.