Understand cookieless analytics.
The hashing scheme, what it guarantees, and what it costs.
The mechanism
There is no identifier stored anywhere. A visitor is computed at ingest and immediately reduced to a hash:
visitor_id = blake2b(user_agent + ip + domain, key=daily_salt)
- Nothing is written to or read from the visitor’s device.
- The IP and user agent are inputs only — neither is stored.
- The salt rotates every 24 hours and is deleted after 48, so older hashes cannot be recomputed by anyone, including us.
- The domain is inside the hash, so the same person on two tracked sites is stored as two different identifiers.
Why the domain being inside matters
It designs cross-site joining out of the stored data rather than merely disallowing it: the two hashes are different values, and nothing we keep links them. That is a property of the scheme, not a promise layered on top of one.
It is a claim about the data at rest, and not more than that. Somebody holding a current salt could compute candidate hashes for both domains from the same user agent and IP and match them — the inputs are not secret and not high-entropy. Deleting the salt after 48 hours is what actually closes that window.
What it costs
Visitor counts are per-day, and there is no user journey that spans days. A tool that recognises the same person across weeks can tell you precisely how many came back; one that refuses to recognise anybody cannot. Any product claiming both no identifiers and exact returning-visitor counts is misrepresenting one of them.
What it does not settle
A cookieless design does not by itself establish a consent exemption or any compliance status. It changes the shape of the question — there is less to disclose when nothing is stored — but the answer depends on your jurisdictions and on what you choose to put in custom event properties, which are fields you control.