GDPR & cookieless tracking
Two tracking snippets, one dashboard — pick based on how much accuracy you're willing to trade for skipping a consent banner.
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.
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.
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.