“Cookieless” has become a checkbox on landing pages, which is a shame, because it is actually a category with real legal consequences. A tool is either built so that it never needs access to a visitor’s device, or it is a conventional analytics product with a consent-mode wrapper. Those two things have different compliance postures and different failure modes.
Define the category
A defensible cookieless analytics setup has four properties:
- It writes nothing to the visitor’s device — no cookie, no localStorage, no IndexedDB, no cache-based identifier.
- It does not build a persistent cross-site or cross-device identifier by any other means, including fingerprinting from fonts, canvas or audio.
- It does not retain IP addresses. Deriving a country at request time and discarding the address is materially different from storing it.
- It can explain, in one page a non-lawyer can read, exactly what is stored and for how long.
Ours is on the privacy page, item by item.
What ePrivacy actually says (in general terms)
The ePrivacy Directive governs storing information on, or gaining access to information stored on, a user’s terminal equipment. That is the trigger: the storage or access, not the analytics. Consent obligations for cookies flow from that provision, which is why a tool that never reads or writes device storage sits outside the cookie-consent requirement — while remaining subject to the GDPR for whatever personal data it does process. The text is public at EUR-Lex, and reading Article 5(3) yourself takes two minutes. Do not take a vendor’s paraphrase — including this one — as legal advice.
The CNIL/EDPB lens
The French regulator has published guidance on the narrow conditions under which audience measurement can be exempted from consent, and the EDPB publishes guidance on related questions across the EU. Both bodies publish their own documents at cnil.fr and edpb.europa.eu. The practical takeaway, stripped of interpretation: exemptions are narrow, they hinge on the measurement being strictly necessary and not shared for other purposes, and no vendor can grant you one. Design so that you do not need the exemption.
Cloudflare’s __cf_bm cookie and how to disclose it
Here is the detail that trips up most “zero cookies” claims. If your site sits behind Cloudflare bot management, Cloudflare may set a __cf_bm cookie on your domain. It is documented publicly in Cloudflare’s cookie reference as a bot-management cookie, and it has nothing to do with your analytics — but it is still a cookie on your domain, and a visitor inspecting their browser will find it.
Do not pretend it is not there. Disclose it explicitly: name it, say who sets it, say what it is for, and say that your analytics does not read it. A privacy page that volunteers an inconvenient detail is worth more than one that claims perfection.
How to be defensible
- Choose collection that never touches device storage in the first place.
- Keep data residency explicit and configurable — EU or US, stated per property.
- Publish a plain-language collection list, including third-party cookies you did not choose.
- Retain the minimum, and say what the retention window is.
- Keep the classification logic auditable, as with our public crawler registry.
If you are weighing options in this category, the closest comparison is Citealytics vs Plausible — both cookieless, with different depth on AI attribution.