Skip to main content
Every site tracks in one of two modes. The mode decides how a returning visitor is recognized — and whether the widget sets any cookie at all. It’s a per-site setting delivered to the widget as tracking_mode in its remote configuration.

​
The two modes

  • Cookieless (default) — no cookies, no local storage, no consent banner. A visitor is identified by a daily-rotating salted hash derived from request signals. Because the salt rotates every day, the identifier cannot be used to follow someone across days, which is exactly what keeps it privacy-friendly. The trade-off: a visitor returning tomorrow counts as new.
  • Cookie — the widget sets a first-party visitor id so the same person is recognized across days and sessions. Use this when cross-day continuity matters more than avoiding a consent prompt.

​
Which to pick

Cookieless is the right default for most marketing sites. Reach for cookie mode when you rely on cross-day identity — for example, multi-day retention cohorts.

​
Switching modes

Change the mode in the site’s settings, or through the API:
See Update tracking mode. The change invalidates the widget’s config cache, so visitors pick up the new mode on their next load.

​
Reading the visitor id

In cookie mode you can read the current visitor id from the widget — never read the cookie yourself:
It returns null before the widget has loaded, and in cookieless mode where there is no stored id. The main use is bridging a server-side Stripe checkout back to the visit that earned it — see Track revenue → Attribute a Stripe checkout.