Cookieless vs cookie

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

You want…	Use
No cookie banner, GDPR/ePrivacy-friendly default	Cookieless
Accurate returning-visitor and retention counts	Cookie

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:

PATCH /api/sites/{siteKey}/tracking-mode

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:

const visitorId = window.clickbase.getVisitorId();

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.