We will not tell you that cookieless means no cookie banner

If you shop for privacy-friendly analytics, you will read some version of this sentence: our analytics is cookieless, so you do not need a cookie banner. It is on pricing pages, in comparison tables and in sales emails. It is stated as settled fact.

We are not going to say it, and the reason is worth eight minutes of your time, because the same reasoning tells you what to actually look for.

The rule is not about cookies

The consent obligation people are thinking of comes from ePrivacy, Article 5(3). It covers the storing of information, or the gaining of access to information already stored, on a subscriber or user's terminal equipment. The word cookie does not appear in it.

That wording is deliberately technology-neutral. It was written that way precisely so that a new storage mechanism would not create a loophole every few years. Local storage is covered. IndexedDB is covered. A device fingerprint assembled by reading properties of the device is arguably covered, because it gains access to information stored on the terminal.

So the honest question is not does this tool set a cookie. It is does this tool store anything on the device, or read anything from it, beyond what is strictly necessary for a service the user asked for.

Which makes the answer configuration-dependent

In cookieless mode Metricward stores nothing on the visitor's device. No cookie, no local storage entry that survives the tab, no identifier of any kind. The visitor identifier is derived server-side from the request, using a salt that is destroyed every 24 hours, and it is scoped to one project so the same person on two customer sites produces two unrelated values.

That is a strong position. It is very likely the strongest technically available while still producing analytics anybody would pay for. It is not the same thing as a legal conclusion about your website.

• ·Whether the resulting data is genuinely anonymous, which depends on your traffic volume as well as our design.
• ·Whether you call identify() and turn anonymous analytics into personal data, which many of our customers deliberately do.
• ·What your national regulator has said, which varies more across the EU than vendors like to admit.
• ·What your own legal basis and privacy notice already say.
• ·Whether you also run other tools on the same page, which is usually where the actual consent obligation comes from.

Why vendors say it anyway

Because it closes deals. A cookie banner costs a site 40 to 70 percent of its measured traffic in some European markets, and a vendor who promises to remove the banner is promising to give that traffic back. It is the single most effective line in the category.

It is also not the vendor's risk. If a regulator disagrees with that sentence, the enforcement lands on the controller, which is you. The vendor who wrote the sentence is a processor and will not be the one explaining it.

A claim that costs the person making it nothing, and costs you everything if it turns out to be wrong, deserves more suspicion than it usually gets.

What we do instead

We build the technical controls that make the strongest case available to you, we document exactly what they do, and we leave the conclusion where it belongs.

• ·Nothing is stored on the visitor's device in cookieless mode.
• ·IP addresses are used in memory to derive a country and a daily hash, and are never written to disk. There is no column for one.
• ·The hash salt is per project and destroyed every 24 hours, so yesterday's identifiers cannot be reversed by us or by anyone who obtains our database.
• ·Query strings pass an allowlist, so an email address or a token in a URL never reaches our servers at all.
• ·Turning on identify() requires an explicit project setting, with a confirmation that says plainly what it changes, because that is the switch that turns anonymous analytics into personal data.

What to ask a vendor who does make the claim

You do not have to take our word for any of this either. Three questions separate a designed system from a marketing position, and they work on us too.

• ·What exactly is stored on the visitor's device, and for how long? A precise answer or nothing.
• ·What happens to the IP address, in order, from the moment it reaches your server? If the answer is anonymised, ask when, and whether the original is written down first.
• ·If your identifier is derived from a salt, who holds the salt, where does it live, and what happens to it? A salt on disk, or in a backup, is a salt that can be used to reverse the identifiers it protected.

The uncomfortable summary

Cookieless analytics may well mean you do not need a consent banner for analytics. It might not. It depends on your setup and your regulator, and the honest answer to a legal question asked of a software company is that you should ask someone whose job that is.

We would rather lose the deal where somebody else's flat no wins it. A vendor who will tell you a comfortable thing about the law will also tell you a comfortable thing about your numbers, and the numbers are what you are actually buying.