Configure4 min read
Cookieless and cookie mode
Every site tracks in one of two modes, set per site under Settings → Tracking. The mode controls how a returning visitor is recognized: nothing else about ingest changes.
Cookieless (default)
Mrkr computes a visitor id by hashing the visitor's IP address, user agent, site id, and a random daily salt (SHA-256, truncated). The salt rotates every UTC midnight and is never stored alongside the hash it produced, so the id for a given person changes every day and cannot be reversed back to their IP.
No cookie is written or read. The only thing the tracker keeps in the browser is a sessionStorage entry holding the current session id, which the browser destroys when the tab closes and which cannot recognize the visitor on a later visit. Because no persistent identifier is stored on the device, cookieless mode does not require a consent banner under GDPR / ePrivacy.
The salt rotates at UTC midnight, so the same person is a different visitor id tomorrow. Nothing in cookieless mode can attribute today's visit to yesterday's visitor: returning-visitor and multi-day retention figures are approximations built from within-day identity, not a cross-day identity graph. That is the trade cookieless makes, and it is the reason cookie mode exists. See Getting numbers you can defend.
Cookie mode
Mrkr sets a first-party _pw_id cookie holding a persistent client id, valid for one year and scoped to your own host (no Domain= attribute, so it can never identify the same person on another site). The same visitor is recognized across days, weeks, and sessions, which makes returning-visitor counts more accurate than the daily-rotating cookieless id.
The cookie is written in the browser before any request reaches Mrkr, so the server setting alone cannot enable it. Switching a site to cookie mode adds data-cookies="on" to your install snippet, and you have to re-paste the snippet for it to take effect. Until you do, the site keeps behaving cookielessly rather than writing a cookie on a guess. Switching back to cookieless also expires any _pw_id the tracker finds, so an identifier you previously planted is removed rather than left sitting in returning visitors' browsers.
Setting a cookie for analytics purposes requires a consent banner under GDPR / ePrivacy in applicable jurisdictions. This is a factual requirement of cookie mode, not a Mrkr policy choice: you're responsible for showing one if you enable it.
If the tracker can't read a client id (cookies blocked, a sandboxed iframe, a strict-privacy browser), Mrkr falls back to the same cookieless hash for that request rather than lumping every such visitor into one shared placeholder id.
What changes in your numbers
- Returning-visitor counts are more accurate in cookie mode: the same person is recognized past midnight, which cookieless can't do.
- Visitor display names: cookie-mode visitors get a stable friendly handle (e.g. "Calm Falcon") derived from their persistent id. Cookieless visitors are shown as
Visitor #xxxxxxx, a stable label only within a single day, since the underlying id itself rotates. - Session and pageview counts are unaffected: mode only changes how visitors are deduplicated across time, not what gets recorded.
Switching modes takes effect immediately for new events; it does not retroactively re-identify past visitors under the new scheme.