Most sites have a cookie banner because their analytics needs one. Remove the requirement and the banner can go with it, along with the consent rate problem underneath it, which is the part that actually costs you.
This is a summary of how the rules work in practice, not legal advice. If your situation is unusual, ask somebody qualified.
The rule is about storage, not about cookies
The relevant text is Article 5(3) of the ePrivacy Directive, which every EU member state has implemented in its own law. It does not mention cookies. It covers storing information on, or gaining access to information stored on, a user's terminal equipment: their phone, their laptop.
That wording is deliberately technology-neutral, and it settles a question people still argue about. localStorage is storage on the user's device. So is sessionStorage, an IndexedDB record, a cache entry used as an identifier, and a canvas fingerprint. That last one counts because reading device characteristics is "gaining access to information stored on" the device.
Swapping document.cookie for localStorage.setItem changes nothing legally. A great many "cookieless" analytics tools do exactly that, and describe themselves as cookie-free on the strength of it. The test is whether something is written to or read from the visitor's machine, not what the API is called.
The exemption, and why analytics rarely fits it
Article 5(3) has two exemptions. Storage is allowed without consent when it is either for the sole purpose of carrying out a transmission, or strictly necessary for a service the user explicitly requested.
"Strictly necessary" means necessary for the thing the visitor asked for. A shopping basket qualifies: without it the checkout the visitor asked for does not work. A login session qualifies. Analytics does not, because the site works perfectly for the visitor whether or not you are counting them. The measurement is something you requested.
Some regulators have carved out narrow room for first-party audience measurement. France's CNIL is the clearest example: it publishes an exemption for analytics that is strictly limited to measuring the site's own audience, used only by the site operator, with no cross-site tracking and a retention limit. The conditions are specific and worth reading if you operate in France. Most member states have no equivalent, which is why a tool that avoids device storage entirely is the simpler position.
What a banner costs you
Aside from being ugly, a consent banner has a measurable cost: the visitors who decline are missing from your data.
The exact rate depends on your audience, your geography, and how the banner is worded, so treat any published figure with suspicion, including the confident ones. What is consistent is the direction. The people most likely to decline skew toward the privacy-conscious, the technical, and the ad-blocking, and those are not a random sample of your traffic. Your analytics stops being a count and becomes a survey with a self-selected respondent group.
That distortion propagates. Conversion rate is computed against a denominator that is missing an unknown fraction of visits. Channel attribution is missing the channels those visitors came from. A/B test results are drawn from the subset that agreed to be measured.
Worse, the loss is silent. Nothing in the dashboard says "and 30% more visits happened that you cannot see". The numbers look complete.
What identity without device storage looks like
If nothing can be written to the device, the obvious question is how anybody tells one visitor from another.
The answer is to derive an identifier on the server from things the request already contains, typically the IP address, the user agent, the site and the date, and to hash them together with a secret that rotates. Rotating the secret daily means the identifier for a given visitor is different tomorrow and cannot be reconstructed afterwards, even by whoever holds the data.
That gives you accurate counts within a day and deliberately loses the ability to follow somebody across days. It is a real trade, and it is worth being blunt about which reports it costs you:
- Unique visitors per day, sessions, bounce rate, sources, pages, conversions all work normally.
- Returning-visitor rates and multi-day retention cohorts do not. They cannot, because the whole point is that yesterday's identifier is unrecoverable.
Anybody claiming you can have cross-day identity with nothing stored on the device and no persistent identifier is describing a fingerprint, whatever else they call it, and a fingerprint is squarely inside Article 5(3).
Where Skomi sits
Skomi derives identity on the server from a salt that rotates daily and is never written down. The tracker writes no cookie and touches no storage on the visitor's device; the code that would do so is not merely switched off but removed from the file the browser downloads, which is a materially different claim from "we do not use it".
Retention cohorts are the report this costs, and that is stated plainly on the Analytics page rather than buried. A site that wants them can opt in to device-stored identity per site, at which point it needs a banner again, which is the honest description of what that switch does.
The other thing worth checking in any tool you evaluate: whether the vendor can tie your visitors together across the other sites it measures. A per-site identifier that never crosses site boundaries is a different privacy posture from a global one, and it is not usually advertised.
What to check on your own site
- Open your site in a private window with the developer tools open.
- Before accepting anything, look at Application → Local Storage, Session Storage, IndexedDB and Cookies.
- Anything there was written before consent. If your analytics put it there, the banner is doing nothing for you legally, because the storage already happened.
That third point catches more sites than any other single mistake. A banner that appears after the tracker has already written its identifier is decoration.
If you want the tool itself to be the reason the banner can go, that is what Skomi's default is built for. The comparison pages say which of the alternatives share that default and which do not, including the rows where they win.
The mechanism has a name and a definition: cookieless means identity derived on the server from a rotating daily salt, which is also why a returning visitor next week is counted as a new one.