Feature
A tracking mode that writes nothing to the visitor’s device. It is a technical configuration, not a legal opinion, and this page will not blur the two.
No cookie is set.
The SDK never writes a cookie in this mode, first-party or otherwise, and getDeviceId() returns null because there is no persistent device identifier to return.
Nothing durable is written to the device.
A failed send is buffered in sessionStorage so an offline visitor’s events are not lost, and that buffer is cleared on tab close. It holds queued events, not an identity.
The visitor identifier does not survive the day.
A hash is computed from the connection’s IP and a few request properties, salted with a key that lives in memory for 24 hours and is then destroyed. The same visitor gets a different, unrelated hash tomorrow. Nothing links the two.
The raw IP address is never stored.
It exists in memory long enough to resolve a country and compute that hash, in the same request, then it is discarded. There is no column for it in any table.
Global Privacy Control and Do Not Track are honoured by default.
Either signal suppresses collection for that visitor entirely. Only an aggregate count of suppressed visits is kept, nothing per-visitor.
Consent state is still a first-class field.
Three modes exist per project: collect immediately, buffer in memory until consent('granted'), or send nothing at all until then. Cookieless mode does not require using the first one.
That this removes your obligation to show a consent banner. ePrivacy Article 5(3) covers storing or accessing information on a visitor’s terminal device, not specifically cookies, so the question is not “does this use cookies” but “does this store or access anything on the device, and is what remains genuinely anonymous.” Several vendors in this category answer that question for you with a flat no. It is the single most common piece of misinformation in web analytics, and we are not going to add to it.
Whether your configuration needs consent depends on what you store on the device beyond this tool, whether the resulting data is genuinely anonymous in your specific setup, your legal basis under the GDPR, and your national regulator’s position, which is not uniform across the EU. Cookieless mode is the strongest technical position we can offer: no persistent identifier, no cookie, an IP that is never stored, and a daily key that makes yesterday’s data unlinkable to any individual. Whether that is sufficient for your site is not something a script can determine. Ask your counsel.
Without a persistent identifier, a visitor who returns tomorrow looks like someone new. Unique-visitor counts are daily-distinct and summed across a range, which overstates true uniques the longer the range gets, and there is no cross-day retention or cohort analysis for anonymous traffic. Multi-day retention and identified-user analytics need a durable id, which today means calling identify() with your own user id. Cookie mode is a project setting for the same purpose, but the SDK does not yet generate or persist that cookie automatically, so identify() is the one that actually works right now. Nothing about either switch is required to use the rest of the product.
Related: how visitor identity is derived is covered on Privacy architecture, and the full posture for a vendor questionnaire is on Privacy.