Cookies & Storage

Dalton uses a small set of first-party cookies and browser storage entries to keep visitors in the same experiment variation across page views and visits. Nothing is shared across domains and no personal data is ever stored.

This page is the authoritative reference for what Dalton writes to the browser and the two things you may need to add to your site:

1. Allow Dalton's domains in your Content Security Policy (CSP)
2. Declare Dalton's cookies in your cookie banner / consent tool

Cookies vs. storage at a glance

Dalton uses two storage mechanisms with different rules:

	What it is	When it's written	Cleared after
Browser storage (localStorage + sessionStorage)	Anonymous experiment cache	Always — needed to render the right variation without flicker	24 hours
Cookies	Anonymous session & device IDs	Only after analytics/performance consent	24 hours

Because the experiment data lives in localStorage/sessionStorage (which contain no personal data), visitors always see a consistent experience during their session — even before they accept cookies. Cookies are only used to recognise the same session across cookie-aware contexts, and are written only once analytics consent is granted.

Cookies set by Dalton

All cookies are first-party (set on your own domain), Secure, and SameSite=Lax. They are written only after analytics/performance consent (see Consent handling).

Cookie	Purpose	Data stored	Duration
dalton_session_id_<customer_id>	Keeps the visitor in the same experiment variation across page views	Random anonymous session ID + the experiment/variation IDs the visitor is enrolled in	24 hours
dalton_device	Recognises a returning visitor so variations stay consistent across visits	Random anonymous device ID (UUID)	24 hours

No personal data

These cookies contain only randomly generated identifiers and experiment assignments. No names, emails, IP addresses, or cross-site identifiers are stored.

Browser storage set by Dalton

These entries hold the anonymous experiment cache. They are written regardless of consent because they contain no personal data, and they are what lets Dalton apply the right variation instantly with no flicker.

Key	Location	Purpose	Duration
dalton_session	localStorage + sessionStorage	Cached experiment assignments and variation content for the current session	24 hours
dalton_device	localStorage + sessionStorage	Anonymous device ID for returning-visitor consistency	Until cleared
dalton_st_redirected_<id>	sessionStorage	Prevents a URL split test from redirecting the same visitor more than once per session	Session

Expired entries are removed automatically the next time Dalton runs.

Consent handling

Dalton detects consent automatically and supports almost every cookie banner out of the box. Cookies are only written once analytics/performance consent is granted. Browser storage (above) is always available so the experience stays consistent.

Dalton recognises consent from, among others:

• OneTrust — performance/analytics category (C0002)
• Google Consent Mode v2 — analytics_storage: "granted" on the dataLayer
• Trustpilot cookie compliance events
• Common consent cookies (e.g. cookieconsent_status, ot_eu_consent, cookielawinfo-checkbox-analytics)

When OneTrust is present, Dalton respects only OneTrust's decision.

If your banner isn't detected automatically

If you use a custom or less common consent tool, set the consent flag yourself once the visitor accepts analytics cookies:

// Grant consent (allows Dalton to write its cookies)
window.dalton = window.dalton || {};
window.dalton.consent = true;

Set it back to false to stop new cookies from being written. Dalton re-checks this flag continuously, so it takes effect immediately when your banner state changes.

---

What to add to your pages

The Dalton snippet itself is all most sites need — see Installation. The two items below only apply if you run a strict CSP/firewall or maintain a manual cookie declaration.

1. Allow Dalton's domains (CSP / firewall)

If your site sends a Content-Security-Policy header (or sits behind a firewall/content filter), allow Dalton's two domains:

Domain	Used for	CSP directive
https://cdn.getdalton.com	Loading the Dalton script	script-src
https://global.dalton-cdn.com	Session & tracking API calls	connect-src

Example policy additions:

Content-Security-Policy:
  script-src 'self' https://cdn.getdalton.com;
  connect-src 'self' https://global.dalton-cdn.com;

For the fastest load, also preconnect to both (Dalton's standard snippet already includes these):

<link rel="preconnect" href="https://cdn.getdalton.com" />
<link rel="preconnect" href="https://global.dalton-cdn.com" />

WARNING

If your CSP includes require-trusted-types-for 'script', Dalton (like most experimentation tools) cannot apply DOM changes. Exclude that directive on pages where Dalton runs.

2. Declare Dalton in your cookie banner

If you maintain a manual cookie declaration, add Dalton's cookies under your Analytics / Performance category so they are governed by the visitor's analytics consent:

Cookie	Category	Type	Duration
dalton_session_id_<customer_id>	Analytics / Performance	First-party	24 hours
dalton_device	Analytics / Performance	First-party	24 hours

• OneTrust: map both cookies to the Performance Cookies (C0002) group. No code changes are needed — Dalton reads the OneTrust decision automatically.
• Google Consent Mode: no action needed; Dalton honours analytics_storage automatically.
• Custom tools: declare the cookies as above and signal consent with window.dalton.consent as shown in Consent handling.

Most scanners also detect the localStorage/sessionStorage entries listed under Browser storage; declare them in the same Analytics / Performance category if your tool tracks storage.

Questions?

For privacy or security questions, email info@getdalton.com or see our Privacy & Security overview and full Privacy Policy.