GDPR & cookieless tracking

Two snippets, one choice

Every site gets a cookie-based snippet by default, and can switch to a cookieless alternative from the Tracking code panel on the site page. Both send the same event shape (pageviews, goals, UTM params, identify) to the same dashboard — the only difference is how a visitor is recognized across pageviews and visits. Whichever variant you pick is saved against the site (not just remembered in your browser), so it also determines which dashboard views are available for that site — see below.

Cookie-based (default)

script.js generates a visitor_id once and stores it in localStorage, mirrored into a first-party shonylabs_visitor_id cookie so your own backend can read it (that's how the transactions APIlinks a purchase back to a visitor). This gives the most accurate analytics and revenue attribution, including journeys that span days or weeks — but because it persists an identifier on the visitor's device specifically to recognize them later, most guidance treats this as requiring consent (e.g. a cookie banner) in jurisdictions covered by GDPR/ePrivacy, same as any analytics tool that works this way.

<script defer data-site="YOUR_SITE_ID" src="https://api.shonylabs.com/js/YOUR_SITE_ID.js"></script>

Cookieless

script-cookieless.js never reads or writes a cookie, localStorage, or sessionStorage— nothing is stored on the visitor's device at all. Instead, backend/server.js derives a visitor_id and session_idfrom a salted hash of the request's IP address and user agent (computeCookielessIds()), rotating automatically roughly once every 24 hours. Because there's no persistent identifier written to the browser, this snippet is designed so you typically do not need a cookie banner for it out of the box.

<script defer data-site="YOUR_SITE_ID" src="https://api.shonylabs.com/js/YOUR_SITE_ID-c.js"></script>

The trade-off

The cookieless hash rotates roughly daily, so a visitor who comes back tomorrow looks like a new visitor — this makes returning-visitor counts and long-window revenue attribution less accurate than the cookie-based script, a limitation shared by any cookieless web analytics approach. It also means the shonylabs_visitor_id cookie used by the transactions API is never set, so your backend has no stable visitor id to attach a purchase to under this mode.

What changes in the dashboard

A cookieless visitor identifier is a same-day hash, not a stable identity — it rotates roughly every 24 hours and was never written anywhere the visitor (or you) can look it up again. Presenting that as a persistent "visitor profile" would overstate what the cookieless snippet actually tracks, so a site declared cookieless (Settings > Script) hides two things from its dashboard:

• The Engagement > Visitors and Journeytabs on the site's main page.
• The standalone per-visitor journey page (linking directly to one no longer resolves).

Aggregate analytics — visitor counts, breakdowns, goals, funnels — are unaffected; only the views built around treating one visitor_id as one person over time go away. For the same reason, the per-visitor erasure tool described in our DPAisn't offered for a cookieless site — there's no stable id left for a later request to target.

Heatmaps & session replay

These two opt-in features (Settings > Script) are affected differently by cookieless mode:

• Heatmapswork the same either way. A captured click carries no visitor or session id at all — just a page and a coordinate — so there's nothing about cookieless mode that changes what gets recorded.
• Session replay isn't available in cookieless mode.Recording and later playing back one visit needs a stable identifier for the length of that session; a hash that rotates roughly every 24 hours can't anchor a recording to a visitor. Turning this on for a cookieless-declared site does nothing — the Settings > Script panel disables the control and explains why instead of letting you enable something that will never actually record.

Choosing

• Want the most accurate analytics and revenue attribution, and are prepared to run a cookie banner where required? Use the cookie-based snippet.
• Want to avoid a consent banner and can accept less precise long-window attribution? Use the cookieless snippet.
• You can switch between the two at any time — both write to the same site and dashboard.