How cookieless analytics works (and what it can't tell you)
How a tool can count visitors without cookies: daily-rotating hashes, what is stored, why returning visitors are harder to spot, and the trade-offs you accept.
How a tool can count visitors without cookies: daily-rotating hashes, what is stored, why returning visitors are harder to spot, and the trade-offs you accept.
“Cookieless analytics” sounds like a contradiction: how do you count people without remembering them? The answer is that you count them just well enough to be useful, and deliberately not well enough to follow anyone around the web. This article explains the mechanism, using Tidemark as the worked example, and is honest about what you give up.
A cookie lets a site tell that two requests came from the same browser. Analytics tools used that to separate “100 visits from 80 people” from “100 visits from 1 person”, and to recognize returning visitors across days and weeks. The same ability is what makes cookies a privacy concern, because a stable identifier can be combined with other data to build a profile.
A cookieless tool needs a way to say “this request and that request are probably the same visitor today” without leaving anything on the visitor’s device. The usual approach is a hash:
Two requests from the same browser on the same day produce the same hash, so they count as one visitor. Nothing was written to the visitor’s device, and the stored id cannot be turned back into an IP address.
If the salt were fixed, the same person would get the same id every day, and you would have rebuilt a persistent identifier with extra steps. So the salt is combined with the date and rotates daily. Tomorrow the same person produces a completely different id.
That is the privacy property: the tool can say how many people visited today, but it cannot say that today’s visitor 4F2A is the same person as last Tuesday’s visitor 9C71. In Tidemark, the visitor id is an HMAC of the site, IP address and user agent, keyed by a salt that includes the current date, and the raw IP address and user agent never reach the database.
Within a day, the tool also groups page views into visits. Tidemark ends a visit after 30 minutes of inactivity, which is a common convention. A visit that has only one page view or event counts as a bounce, and the visit duration is the time between its first and last event. Because the id is the same all day, “unique visitors” for a week is the number of distinct daily ids, which counts someone who came on three days as three visitors.
Be clear about the trade-offs before you rely on the numbers:
For content sites, documentation, marketing pages and most small businesses, these limits cost very little, because the questions you ask are about volume and sources, not individuals. For products where you need to follow users through a funnel over weeks, you need a different kind of tool.
For each page view a cookieless tool like Tidemark keeps aggregate-friendly fields: the page, the referrer and its source category, the country (and region or city when your CDN provides them), the browser, the operating system, the device type and the day-rotating id. It does not store the IP address, the raw user agent, or anything it could use to recognise a person later. You can read the exact list on our privacy page.
Not automatically. Whether you need a consent banner depends on the rules in your country and on everything else your site does. We cover that in Do you need a cookie banner for analytics?. What cookieless counting does is make the analytics part easy to describe and low risk.
You can open the live Tidemark dashboard that measures this site and see exactly what is collected, or read how the metrics are defined.