What cookieless analytics means for your numbers

“Cookieless” has become a label vendors attach to anything privacy-adjacent, so it is worth being precise. In TapCub it means one specific thing: no identifier is stored in the visitor’s browser, and visitors are counted from a hash that cannot be reversed and changes every day. That one design decision has consequences for your numbers, your consent banner and your legal footing. This article walks through the mechanism, what you give up, what you get, and the cases where you still want identity.

What cookieless means here

Cookie-based analytics writes an identifier into the browser and reads it back on every visit. That identifier is personal data under most privacy regimes, which is why the banner exists. Cookieless analytics never writes anything. It cannot recognise you tomorrow, which is precisely the point, and it also cannot be blocked by a cookie setting, which is why the coverage is better.

What TapCub does not do is equally important: it does not fingerprint. Fingerprinting builds a stable identifier from device characteristics so it can recognise you across days without a cookie. That is a cookie with extra steps. A daily hash is designed to forget.

How a visitor is counted

On each request the collector combines a handful of attributes that arrive anyway (the site, a coarse network identifier, the user agent) with a secret salt that is regenerated every day, hashes the result and keeps only the hash. The inputs are discarded. Two requests on the same day from the same browser produce the same hash and are counted as one visitor; tomorrow the salt is different, the hash is different, and yesterday’s visitor cannot be linked to today’s. In pseudocode:

// salt rotates at 00:00 UTC and is never written to disk
salt = dailySalt(today)

// inputs arrive with every request anyway
visitorId = sha256(siteKey + salt + coarseNetwork(ip) + userAgent)

// keep the hash, discard the inputs
store(event, visitorId)
forget(ip, userAgent)

What you lose

The honest trade-off is cross-day identity. A cookie-based tool can tell you that 40% of this month’s visitors came back on a later day; a cookieless tool cannot, because it chose not to be able to. Monthly unique visitors will be higher than in a cookie-based tool (each day’s visitors are new), and “new vs. returning” only works within a day or for identified users.

Retention reports therefore need an identity you provide: a login, an account ID, a customer number. Without one, retention is measured per identified user, not per anonymous visitor. For most businesses this is the right line: you want retention for customers, and customers have accounts.

What you gain

Three things. First, in most cases no analytics consent banner, because nothing is stored and nothing is personal. Second, complete coverage: visitors who decline cookies, use strict privacy browsers or clear storage are still counted, so the numbers stop depending on the consent rate in each region. Third, a cleaner legal position, documented on the privacy and security page.

In practice the coverage gain is large. Sites that migrated to TapCub from cookie-based tools typically see daily visitor counts rise, not because traffic changed but because the 30–40% who declined cookies are now visible. Read the UV reconciliation article before you compare the two.

Cookie vs. cookieless, side by side

The table summarises what each model can and cannot answer. Neither column is “better”; they answer different questions, and the right choice depends on which questions you need answered for anonymous visitors versus identified users.

When you still want identity

Cookieless measurement is the floor, not the ceiling. When a visitor logs in, your app can call identify() with a stable user ID, and from then on that person’s events are attached to the ID across days and devices. This is consented, first-party and exactly what you need for retention, lifetime value and user profiles. The user analytics view is built on it.

The rule we recommend: anonymous traffic is measured cookieless, with no banner. Identified users are measured by their account, with the consent that comes with having an account. Nothing in between.

This split also keeps the engineering simple. There is one snippet, one identify() call at login, and no consent-mode logic deciding which events to drop. Your developers do not maintain two measurement paths, and your reports do not have a footnote about which regions are under-counted.

Switching: what to check

If you are moving from a cookie-based tool, expect three changes: daily uniques go up (coverage), monthly uniques go up more (no cross-day linking), and returning-visitor reports need redefining around identified users. Update any dashboard that quotes monthly uniques, decide whether the analytics banner can go, and wire identify() into your login flow. The migration guide covers the parallel-run week, and the data platform page lists what is collected by default.