Cookieless analytics: how it counts and what you give up

“Cookieless” tells you one thing for certain: the tool doesn’t set a cookie. It doesn’t tell you how people get counted, what else is kept, or whether you still have to ask for consent. Those are the questions that matter, so while building Trailic I read what six tools say about themselves in their own docs and source code. Here’s what I found, checked in November 2026.

What the word covers

Three different techniques get sold under the same label.

Storage that isn’t a cookie. A script can keep an ID in localStorage and truthfully say it sets no cookies. For the visitor nothing changes: the ID lasts. The French regulator’s guidelines name local storage next to cookies among the technologies its rule covers.

Fingerprinting. Combine enough attributes of a browser and you get an ID that lasts without storing anything. The European Data Protection Board recalls that fingerprinting falls within the scope of Article 5(3) of the ePrivacy Directive, the rule behind cookie banners.

A short-lived hash computed on the server. Nothing is kept in the browser. The server hashes what every request already carries, with a salt that changes, so the ID dies by itself. This is what most privacy-minded tools mean by the word, and it’s what the rest of this post is about. See the glossary entry on cookieless tracking for the short version.

You’ll also meet Google’s consent mode. In its advanced form, tags load even when someone refuses, and send “measurements without cookies” along with the refusal, to feed a model. That’s a way of handling a refusal alongside a banner, so it belongs to a different discussion.

How six tools count

Two differences are worth more than the shared recipe.

The first is the rotation. A month-long salt, Umami’s default, recognises someone across a month as long as their address and browser hold still. A daily salt can’t. That’s a real trade: better monthly counts against a longer period during which visits can be linked.

The second is what happens to the salt. Plausible and PostHog say they delete it. Trailic derives each day’s salt from TRAILIC_SECRET, so that the collector never has to read a database. The cost is that whoever holds the secret can recompute any past day. I go through that in how the daily salted hash works.

What you give up

Here’s an invented example to show the arithmetic. A thousand people visit your site in a month, on three separate days each on average.

The daily hash gives you person-days. It’s a fine trend line and a poor answer to “how many people”. PostHog’s docs describe the same effect as “high unique user counts beyond one day”, and Matomo says unique, new and returning visitors become inaccurate without cookies.

More broadly:

And what you get in return: nothing written to the device, no ID that outlives the day, no way to follow someone from one site to another, and less to explain to your visitors.

A tool behind a banner also counts only the people who accept, while a tool without one counts everyone a blocker lets through. Vendors publish percentages on that gap. I don’t have a figure for your site, and neither do they. If it matters to you, run both for a few weeks and measure it.

No cookies doesn’t settle consent

Article 5(3) is about storing information on a device and gaining access to information stored on it. The EDPB’s guidelines say it “does not exclusively apply to cookies”, that JavaScript telling a browser to send information falls within it, and that collecting information through the user agent or the address can bring it into play. They also say that the article applying doesn’t always mean consent is needed.

So a hash on the server may well sit inside the rule and still be allowed without consent, depending on your country and on what you do with it. In France, the CNIL has an exemption with precise conditions. I went through them, criterion by criterion, in do analytics need a cookie banner. The decision is yours as the site’s owner, and this post isn’t legal advice.

Which one fits

What Trailic does

No cookies, ever, and nothing in browser storage before a site calls identify, which keeps the ID it was given in localStorage. About 1.5 KB gzipped in the browser. If you decide you want to ask first, the library holds everything in memory until you say so:

<Trailic siteKey="site_…" endpoint="https://your-instance.example/api/e" consent={accepted} />

The limits are stated plainly on the privacy approach page: everyone behind one address with the same browser is one visitor, which is a known undercount, and someone holding TRAILIC_SECRET who knows a person’s address and browser could compute their hash for a day.

Where Trailic stands

Trailic is a first version. It works end to end on a test instance with real browsers, a real assistant and five million synthetic events, but it hasn’t collected real traffic yet. Its Vercel Queues buffer has only run against a stand-in for that service, its data model may change, and there’s no upgrade path between versions. There’s no hosted version, and the library isn’t on npm yet: it lives in the repo at packages/trailic. The tools above are running on real traffic today. Don’t make Trailic your only analytics yet. The code is on GitHub, and I’d like to hear what’s wrong in the issues.

Sources

• EDPB, Guidelines 2/2023 on the technical scope of Art. 5(3) of the ePrivacy Directive, version 2.0
• CNIL, guidelines on cookies and other trackers, deliberation 2020-091 (in French)
• Plausible, data policy
• PostHog, how to do cookieless tracking (source of the page)
• Matomo, does Matomo use a fingerprint?
• Matomo, how cookieless tracking affects report accuracy
• Umami, the collection route in its source code and its salt function
• Vercel, Web Analytics documentation
• Google, consent mode overview
• Trailic, product specification