Choose how your website measures visits

Cookie vs cookieless: what changes?

The extra input is an optional random cookie ID and consent flag. Stored events contain its site-specific pseudonym, never the raw cookie ID. Both modes expose the same metrics. Cookie recognition improves deduplication of browser estimates; it does not guarantee more recorded traffic, because rejection and blockers still exclude visits.

Visits in both modes end after 30 minutes of inactivity and split at UTC midnight. Mixed-mode counts do not merge a browser between modes. Daily cookie visitor counts cannot be summed into a unique multi-day total. API queries, export fields and examples.

1. Pick a mode

• Cookieless: no tracker cookies, localStorage or sessionStorage. Website-specific IP/User-Agent estimates rotate daily. Shared networks can merge browsers; address changes can split them. Assess the legal basis for your particular deployment.
• Cookieless after consent: same measurement, but no analytics request until acceptance.
• Cookie after consent: a random first-party browser ID, scoped to this hostname and website, expires after at most 90 days without renewal. No analytics before consent. No fingerprinting fallback intended to bypass a rejected choice. If the browser blocks cookies after consent, collection uses daily estimates.

Changing the dropdown generates installation code; it does not change an already installed script. Replace the existing snippet rather than adding a second tracker.

2. Give visitors a real choice

The generated choice panel offers Reject analytics and Allow analytics with equal styling. No preselected acceptance, scrolling consent or cookie wall. A persistent Analytics preferences button permits withdrawal. Set the privacy notice link to your website's actual notice before publishing.

The panel stores crumbs_choice_v1_SITE (allow/deny) for 90 days only after a choice. Cookie mode additionally uses crumbs_v1_SITE (random UUID and fixed expiry), at most 90 days. Both are host-only, Path=/, SameSite=Lax and Secure on HTTPS. They are first-party JavaScript cookies, not HttpOnly. The preference is not a server-side consent ledger.

Withdrawal stops further events, clears the memory queue, aborts pending fetches where possible and deletes the identifier. Already committed events and a request already received by the server cannot be recalled; normal retention and deletion procedures still apply. GPC/DNT always override acceptance.

3. Already using a consent manager?

Disable “Include the visitor choice panel”, keep data-consent="required", and connect your CMP's analytics category. Register the handler after tracker.js loads; apply the current CMP state on every page and subscribe to changes. Do not grant consent merely because the banner was closed.

// Run after tracker.js has loaded, from your CMP callback:
if (analyticsConsent === true) window.crumbs.grantConsent();
else window.crumbs.revokeConsent();

The tracker does not remember consent itself. Your CMP handles expiry, records, jurisdiction-specific policy and changing/revoking the choice. Repeated grant callbacks are idempotent and do not create extra pageviews.

Host the supplied consent.js and consent.css with the tracker (as the generated snippet does). Permit those origins in CSP script-src/style-src and the collector in connect-src. No inline script is required. Optional Node deployments still serve consent assets from the dashboard or your website; the Node collector serves tracker.js only.

4. Verify before enabling for everyone

1. Use an isolated test website ID. Before consent: no analytics request or identifier; reject: only the choice cookie; accept: one pageview and, in cookie mode, one browser ID.
2. Repeat acceptance, change SPA routes, reload, then withdraw. Verify no duplicate acceptance pageview and no further analytics after withdrawal. Reopen preferences with keyboard and test at a narrow viewport.
3. Inspect crumbs.status(): accepted means canister commit; queued-at-collector means only the optional Node queue. Invalid receipt, retry errors, queue-full and dropped counts are not successful delivery.
4. Compare recorded pageviews with the expected test sequence; do not compare unique people with daily visitor estimates. Use Overview → More details → Collection mode to filter cookie and cookieless traffic separately.

What consensus does—and does not—guarantee

The initial HTTP query asks the gateway to perform an update and stores nothing. The update commits accepted events before returning a canister receipt. Replica execution does not multiply the stored event count. Retries use the same event ID and are deduplicated; a conflicting payload is rejected. A successful browser send or beacon alone is not a durable receipt.

Blocked scripts, offline closes, discarded browser memory, rate limits, undetected bots and forged public requests still affect measurements. Timestamps are first receipt time, so delayed arrivals can move to another reporting bucket. Native mode does not infer geographic location. The browser queue is bounded at 100 events and is not a persistent delivery log. This is not a promise of complete human-visitor counts or proven production throughput.