Both skip the cookie. That is where it ends.
A fingerprinting vendor and a privacy-first analytics vendor will both tell you their product is cookieless, and both will be telling the truth. Neither writes anything to the device. Both derive an identifier from what the request already reveals. On an architecture diagram they look similar enough that the word covers both.
They are close to opposites in what they are built to do, and the difference is not subtle once you look at it directly:
A fingerprint is engineered to stay stable — the value is worthless if the same device is not recognisable next month. A rotating identifier is engineered to expire — the value is worthless if it can still be linked to anyone tomorrow. Same category, opposite success criteria.
Everything that follows — the legal treatment, the diligence questions, what you can honestly tell your users — comes out of that one difference. “Cookieless” describes the mechanism they share and says nothing about the property that matters.
What a fingerprint actually is
Browser fingerprinting builds an identifier out of characteristics your browser reveals as a side effect of working normally: screen resolution and colour depth, timezone, installed fonts, hardware concurrency, WebGL and canvas rendering quirks, audio-stack behaviour, supported codecs. None of these identifies you alone. Combined, they frequently do — the combination is rare enough across a large population to single out one device.
Two properties are worth naming because they are what the technique is optimised for. It is stable: a good fingerprint survives browser restarts, cache clears, private-browsing windows and IP changes, which is exactly what makes it commercially attractive. And it is silent: there is nothing stored for a user to inspect, clear or block, so the ordinary controls people rely on — clearing cookies, declining a banner — have no effect on it and give no indication that they had none.
That last part is why fingerprinting attracts the regulatory attention it does. A cookie is at least visible and deletable. A fingerprint routes around every control a user has, which makes “we don’t use cookies” a considerably less reassuring statement than it sounds.
What a rotating derived identifier is
The other approach derives an identifier from transport facts the request already carries — typically the IP address and User-Agent — through a keyed hash under a secret that changes on a schedule, usually daily. Cookieless analytics, explained covers the construction; the property that matters here is what happens at the boundary. When the secret is destroyed, the identifiers minted under it cannot be linked back to a device, or to each other, by anyone — including the operator holding the database.
That imposes a real cost, which is the honest tell that the guarantee is genuine. Rotation is what breaks funnels, retention and multi-day unique counts. A vendor accepting that damage is accepting it for a reason. A vendor claiming cookieless measurement and intact cross-week retention is describing something that persists, whatever they call it.
The test that separates them
You can skip most of the marketing by asking two questions:
- Is the identifier designed to persist? Not “does it happen to change sometimes” — is stability a feature the vendor would fix a bug to protect? If yes, it is a fingerprint regardless of the label on the box.
- What is it used for? First-party audience measurement on one site is a different activity from following someone across unrelated sites, and the law treats them differently even when the mechanism is identical.
Note what is not on that list: whether a cookie is involved. It was never the operative fact — it was just the most common implementation at the time the rules were written, which is how it ended up in the informal name for them.
What the law actually says
The rule that produces consent banners is Article 5(3) of the ePrivacy Directive, and it is written about storing or gaining access to information on a user’s terminal equipment. It does not say “cookies”. That has been the settled reading for over a decade: the Article 29 Working Party’s Opinion 9/2014 addressed device fingerprinting specifically and placed it inside Article 5(3)’s technical scope.
The EDPB’s Guidelines 2/2023 on the technical scope of Article 5(3), finalised in October 2024, restated and extended that. The guidelines confirm the article reaches tracking pixels and tracking links, device fingerprinting, certain kinds of local processing where information is then transferred off the device, IoT reporting, and certain instances of IP tracking. The practical effect is that “we replaced our cookies with something else” stopped being a defence, because the guidelines were written specifically to address the wave of techniques adopted to make that argument.
The part most vendors leave out
Guidelines 2/2023 also addresses IP addresses directly, and it is more demanding than the cookieless marketing around it suggests. Accessing an IP address engages Article 5(3) where that information originates from the user’s terminal equipment — and the guidelines treat a static outbound IPv4 from a user’s router, and IPv6 addresses (which are partly defined by the host), as falling within that. Unless you can establish that the address does not originate from terminal equipment, the obligations apply.
So the honest position — including for the approach Pug takes — is that deriving an identifier from an IP address is not automatically outside ePrivacy scope, and a vendor telling you their IP hashing is categorically exempt is overstating a genuinely unsettled question. What rotation and deletion do is materially improve the position: no persistent identifier exists, nothing is retained that could re-link anyone, and the purpose is first-party measurement rather than cross-site tracking. That is a much better set of facts to assess against. It is not the same thing as being out of scope, and the difference is worth knowing before you write it into a privacy policy.
What changed in 2026
If you have relied on the French CNIL’s list of approved analytics tools, it no longer exists — the CNIL retired it on 1 January 2026, replacing it with self-assessment against criteria it published in July 2025. The exemption itself remains available for genuine first-party audience measurement, on conditions that have been broadly consistent: strictly first-party use, no cross-site tracking, no onward sharing with third parties, and a bounded retention window.
The shift matters for how you evaluate vendors. Nobody can point at a list anymore, so a claim of exemption is now an assertion by whoever makes it. And because the criteria are about deployment rather than software alone — what you collect, who you share it with, how long you keep it — the assessment lands on the party running the tool. A vendor can make the exemption reachable. It cannot make it for you.
Diligence questions worth asking
- What goes into the identifier? Screen resolution, fonts, canvas, WebGL and hardware concurrency have no purpose in first-party measurement other than distinguishing devices. IP and User-Agent are facts the request carries anyway. The difference is whether entropy is being actively harvested.
- Is the secret deleted, or rotated and kept? This is the question that separates a real guarantee from a scheduling detail. Retained salts mean the entire history stays re-linkable at the vendor’s discretion.
- Are IP and User-Agent stored on the event? Using them as hash inputs is very different from keeping them on every row, where they remain available to anyone with database access.
- Does cross-week retention still work? An unusually revealing question. If the tool reports intact multi-week people-metrics without a consent path, the identifier is persisting.
- Can you verify any of it? With closed-source tools these answers are assertions. Open source makes them checkable, which is a different category of assurance.
Where Pug sits
Pug’s Web SDK stores nothing on the device by default. Consent-declining visitors are given a server-derived identifier: a keyed hash of project, IP and User-Agent under a salt that changes daily and is deleted when its TTL expires rather than archived. IP and User-Agent are hash inputs only — never written to the event, never returned by the API. No device characteristics are collected or used, so there is no fingerprint to build from.
We accept the measurement cost that comes with that. Those identifiers are excluded by default from unique users, funnels, retention and user flows, because a daily-rotating value counted as a person inflates every one of them. The alternative — quietly keeping the identifier stable so the charts look better — is the trade we are declining to make, and it is the trade that turns a cookieless tool into a fingerprinting one.
What we will not tell you is that this places you outside ePrivacy scope, because as above, that is not a settled question and it depends on your deployment as much as on our code. Pug is AGPL-3.0, so you can read the derivation and verify every claim here rather than take it on trust — and if you self-host, the IP never reaches a third party at all, which is a stronger fact than any hashing scheme. For the wider compliance picture, see GDPR compliance for analytics. None of this is legal advice; the assessment is yours to make with qualified counsel. The construction itself — the HMAC, the framing, and why the salt is deleted rather than archived — is written up in cookieless identity, built on a self-deleting salt.