Consent & Tracking

The core idea: two independent paths

When the Embeditor script runs on your page it does two very different things, and they are deliberately decoupled:

Assignment never needs consent. The variation is chosen by a local, deterministic hash and applied before first paint — nothing is stored on the device to do it. Your test runs at full speed regardless of consent, with no “wait for the banner” delay and no flicker.

Tracking is what consent controls. Only the persistent visitor identifier and the viewer-level beacons are gated — the part that, under ePrivacy/GDPR, requires a lawful basis.

The consent states

The runtime is always in one of these states. The default is Granted (tracking on), matching how most A/B tools ship. Switch a site to required mode for a denied-by-default, consent-gated posture (Google Consent Mode v2 style).

Granted (default)

• A stable viewer_id is stored so a returning visitor keeps the same variation.
• Full viewer-level exposure, metrics, and conversion tracking.
• This is implied mode: you assert consent isn’t required (or is handled by your banner) — your responsibility under the DPA.

Denied — cookieless

• The state before consent in required mode, or after an explicit CMP/GPC denial.
• Assignment runs on an ephemeral in-memory id that is never written to the device — no ePrivacy trigger.
• Aggregate pings still fire under that ephemeral id, so views, conversion rate, bounce, and scroll keep counting — they just can’t be tied to a person across visits.
• Tradeoff: a returning visitor may be re-bucketed, since there is no stored id to make assignment sticky.

Denied — off (optional)

• Assignment still runs in memory, but all tracking is buffered and nothing is sent until consent, then the queue flushes.
• Strictest option; you lose data from visitors who never consent.

How the script learns consent

Consent originates on your page — only your site knows what the visitor chose. The script can’t invent it, but it can read it, four ways, from zero code to one line.

1. A mainstream CMP — zero code

The runtime auto-detects IAB TCF v2 (OneTrust, Cookiebot, Quantcast, Didomi, Usercentrics…) via __tcfapi and Google Consent Mode via analytics_storage. If you use one, there is nothing to add to your page.

2. A custom banner — one line

window.embeditor.setConsent(true);   // on accept
window.embeditor.setConsent(false);  // on reject / withdraw

3. A named consent cookie — configuration

Configure the cookie name (and optional value) in your site settings and the runtime polls it — no page code.

4. GPC / DNT — automatic

A browser Global Privacy Control or Do Not Track signal is treated as an automatic denial and overrides everything else, including the default implied mode.

JavaScript API

window.embeditor.setConsent(true);   // grant  — persist id, full tracking, flush queue
window.embeditor.setConsent(false);  // revoke — clear device identity, stop viewer-level tracking
window.embeditor.getConsent();       // => boolean, current state

setConsent(true) is ignored if a GPC/DNT denial is in effect. Load any page with ?ab_debug=1 to print [embeditor] logs, including the consent state and every grant/revoke transition.

Configuration reference

Where responsibility sits

You are the controller: you decide to run tests, you own the visitor relationship, and you are responsible for your privacy notice and any legally required consent. Embeditor is the processor and gives you the mechanisms above to enforce your choice. See the Data Processing Addendum for the full allocation.