For years, “counting visitors” meant dropping a cookie (or three), stitching sessions across days, and hoping the consent banner was enough. A growing set of products take a different path: measure traffic with no cookie on the visitor by default, keep reports at the aggregate level, and treat person-level profiles as an explicit opt-in — not the starting point.
This piece has two layers. First, the general technique behind cookieless / privacy-friendly analytics (industry knowledge — not unique to any one vendor). Second, what DataVisitors documents about its own approach on its privacy, how-it-works, and product pages. Those two layers stay separate on purpose.
Important: DataVisitors is waitlist-only right now. Accounts open by invitation. There is no “start a free trial” or “create an account now” path on the public site — join the waitlist, confirm the email, and wait for a seat. You can explore the live demo without an account.
Nothing in this article is legal advice. Cookie banners, consent, and ePrivacy rules depend on your jurisdiction, your other trackers, and how you configure the product. Talk to counsel for compliance decisions.
Why cookies became the default (and why people want out)
Classic web analytics often:
- Sets a first-party cookie with a stable visitor ID.
- Reuses that ID across days and sometimes across subdomains.
- Builds funnels, retention, and “who is this person?” views from that ID.
That model is powerful. It is also exactly what many privacy laws and browser features push against: persistent identifiers on the device, cross-context tracking, and opaque third-party beacons. Cookieless analytics try to answer a narrower question well — how many visits, from where, to which pages, completing which goals — without needing a durable ID in the browser.
The general technique: daily salted hashes (illustrative)
A common cookieless pattern looks like this (simplified; illustrative, not a claim that any specific product uses this exact code):
// ILLUSTRATIVE ONLY — not DataVisitors source code
import crypto from 'node:crypto';
function dailyVisitorKey({ ip, userAgent, projectId, utcDate, dailySalt }) {
// Salt rotates once per UTC day; projectId keeps sites from sharing IDs
const material = [utcDate, dailySalt, projectId, ip, userAgent].join('|');
return crypto.createHash('sha256').update(material).digest('hex');
}
// Count uniques inside one UTC day by inserting the key into a set/HLL
What this buys you:
- Same person, same day, same site → same key → counts once toward daily uniques.
- Next UTC day → new salt → new key → you cannot stitch a continuous multi-day journey from the identifier alone.
-
Same person on two projects → different
projectIdin the hash → two numbers, not one cross-site profile.
Trade-offs (general industry knowledge):
| You gain | You usually lose |
|---|---|
| No cookie required for basic counting | Reliable cross-day “unique visitors” as one person |
| Harder to build a stalking-style profile from the analytics ID | Some retention / returning-user charts unless another consented ID exists |
| Smaller consent surface for analytics-only setups (still context-dependent) | Perfect bot resistance from the ID alone |
A rotating identifier is not a guarantee that all data is anonymous. IP addresses, referrers, and rare page paths can still be identifying in combination. Privacy-friendly products typically also drop or coarsen fields (e.g. country instead of precise location) and keep public share links at aggregate totals only.
What DataVisitors says it does
The following is taken from DataVisitors’ own pages — privacy approach, how it works, FAQ, web analytics, and integrations.
No cookie on a visitor (by default)
The privacy page states: “The tracking script sets no cookie. It starts stateless.” The FAQ repeats that the tracker starts stateless and that whether device storage is ever used depends on the project’s privacy regime and the visitor’s consent.
A daily, project-scoped identifier
Privacy approach: a visit is counted with “the day’s salt, minted once per UTC day.” The stored sample record describes the visitor as a “daily-salted hash, project-scoped.” Explicitly: “One person on two sites is two numbers” because the project is inside the hash — visitors cannot be joined across sites via that identifier.
FAQ phrasing: “Stateless measurement uses a daily identifier that differs between projects. Device storage depends on the project's privacy mode and the visitor's consent. A rotating identifier does not guarantee that all data is anonymous.” That last sentence is worth quoting in full — it matches the honest industry caveat above.
Privacy regimes you choose per project
DataVisitors documents three regimes (privacy approach):
- Automatic (default): Stateless where the law is strict; device storage elsewhere when allowed.
- Strict: Nothing stored on the device anywhere until your site’s consent allows it; until then every visit uses the daily salt only.
- Relaxed (opt-out): A first-party id may be kept on the device by default; Global Privacy Control, Do Not Track, and an opt-out call are honoured.
The page also says Global Privacy Control and Do Not Track are respected in all regimes; only an explicit consent from your own banner outranks them. In the EEA, UK, Switzerland, or an unresolved country, nothing is stored on the device until your site’s consent allows it (Automatic / Strict behaviour as documented).
Aggregates first; People off by default
Public share links show aggregates only, never an individual visitor. The People feature stays closed until an administrator opens it, and switching it on is recorded. Exports, erasure, and account closure are described as available on every plan — erasure removes a person’s events and traits and keeps a hashed tombstone.
What you can measure (web analytics)
The web analytics feature page describes visitors, page views, sessions, sources (referrer / channel / UTM), pages, engagement (bounce, duration, scroll depth), goals, bot/referrer-spam filtering, and an AI assistants channel for recognized referrers such as ChatGPT, Claude, Perplexity, Gemini, and Copilot. It also clarifies visitor vs session vs page view, and warns that dual-counting page views from both browser and server will inflate totals.
How you connect it (when invited)
How it works and the browser integration document a deferred snippet shaped like:
<script
defer
src="https://api.datavisitors.com/assets/sg.js"
data-key="YOUR-INSTALL-KEY"
></script>
Set allowed origins and privacy settings before the first event. Use one source for page views (browser or server, not both for the same load). Server-side and webhook events go through the HTTP API with separate ingest and read keys.
Pricing context (no “start now”)
Pricing lists Free / Starter / Growth / Business with event ceilings and feature gates, but prices are marked “not published yet.” Every plan CTA is Join the waitlist. Past an events ceiling, the site says collection continues; the plan gates reading. That is product documentation, not an invitation to sign up today.
How this compares to “just turn off cookies in GA”
Flipping a cookieless flag in a cookie-first product is not the same architecture as designing aggregates + daily salts from day one. Cookie-first tools often still lean on device storage when allowed, and their mental model remains “user ID → journey.” Privacy-first tools push you toward questions the aggregate can answer: which sources convert, which pages bounce, whether a release moved the needle — and they make person-level data a deliberate switch.
If you also run free browser-only utilities for day-to-day debugging (headers, JSON, PDF chores), that is a separate trust story from analytics — FindUtils keeps those tools client-side. Analytics still needs a server somewhere to store counts; the privacy question is what you store and how you identify a visit.
Practical checklist if you are evaluating cookieless analytics
- Read the privacy page, not only the homepage. Look for: cookies or not, salt rotation period, cross-site joining, consent behaviour, GPC/DNT.
- Decide your regime before the first event. Changing later does not rewrite history the way you might hope.
- One page-view source. Dual instrumentation doubles page views.
- Goals over vanity uniques. A signup goal survives cookieless limits better than “users this month” marketing slides.
- Ask what public links expose. Aggregate-only share URLs are a strong signal.
- For DataVisitors specifically: explore the demo, read privacy and FAQ, then join the waitlist. Do not expect a self-serve signup today.
Wrap-up
Cookie-free analytics usually means: no cookie by default, a short-lived or salted identifier for same-day counting, project scoping so IDs do not federate across sites, and aggregates as the default report. DataVisitors documents exactly that pattern — daily-salted, project-scoped hashes; three privacy regimes; People off until an admin enables it; waitlist-gated accounts.
Start at datavisitors.com, dig into the privacy approach and how it works, try the demo, and join the waitlist if you want a seat when invitations open.
Top comments (2)
the daily-salt framing is the honest part. most cookieless pitches hide the multi-day stitching loss in fine print, this one puts it in the trade-off table up front. rotating the salt is basically a 24h ttl on identity, and that’s the whole bargain.
Thanks, that's a great way to put it. A 24-hour TTL on identity is exactly the bargain, and we'd rather be upfront about what you give up (multi-day journeys, returning-visitor counts) than bury it in fine print. For most sites, knowing which pages and sources work matters more than following individuals across days anyway. Appreciate you reading closely!