Optimizely Web Experimentation Cookie Consent Integration Guide: A/B Testing Under GDPR in 2026
Optimizely sits in a strange position relative to the consent conversation. A reasonable person looking at experimentation tooling might assume it is a low-risk category — the test is about which button colour drives more clicks, not about who the visitor is. The reality, under the framework the GDPR set and that the EDPB has been actively reinforcing since 2023, is that experimentation engages exactly the same processing categories as analytics or marketing whenever the platform writes a persistent identifier and ties experimental variants to it. The Optimizely Web Experimentation SDK does precisely that: it assigns a visitor to a variant by hashing a persistent identifier, writes the assignment to a first-party cookie so the visitor sees the same variant across sessions, and emits exposure and conversion events tied to that identifier. Each of those steps engages a consent gate. The good news is that Optimizely ships with one of the more thoughtful consent integrations in the experimentation category, including a dedicated consent attribute and the ability to operate in anonymous-only mode. The work is in actually using it.
Why Optimizely Web Experimentation requires consent
A default Optimizely initialisation does several things in the first paint of the page. It sets a first-party cookie under optimizelyEndUserId containing the persistent visitor identifier, evaluates the visitor against the active experiments, writes the variant assignments to a second cookie under optimizelyOptOut namespace markers, fires a decision event to logx.optimizely.com, and applies the variant changes to the rendered page. When the operator has connected an analytics integration — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap, or the Optimizely Data Platform — the SDK also fires variant-exposure events into the analytics layer, which then tie the variant to the visitor's broader analytics profile.
Each of those activities engages a separate consent gate. Persisting the visitor identifier is a storage-and-access operation under Article 5(3) of the ePrivacy Directive requiring prior, freely given, specific, informed, and unambiguous consent across the EEA, the UK, and any jurisdiction that has imported the same standard. Tying experimental variant assignments to that identifier across sessions is processing of personal data under the GDPR because the combination of identifier, IP address, and variant exposure is sufficient to single out an individual and to characterise their interaction with the experimentation programme. Cross-tool propagation of variant data — Optimizely exposing the variant assignment to Google Analytics, for example — adds the analytics gate to the chain. The EDPB's 2023 guidance has been explicit that experimentation that engages persistent identification is subject to the same consent rules as analytics; the CNIL has been the most vocal regulator on this point but is not alone.
What Optimizely writes before consent — and what must be suppressed
The standard Optimizely snippet installs the JavaScript SDK directly into the page head and initialises immediately on load. That is the documented quickstart and the source of the most common compliance failure: the SDK runs before the cookie banner has rendered, the optimizelyEndUserId cookie is written within milliseconds, the variant assignment is made, and the decision event is fired regardless of what the visitor later decides. Every European regulator that has ruled on this pattern has ruled the same way: cookies set before consent are unlawful, the variant assignment captured before consent is unlawful processing, and the publisher carries the liability.
A compliant integration must therefore prevent Optimizely from writing the persistent identifier and firing decision events until the relevant consent category has been granted. Optimizely supports two patterns for this. The first is the dedicated consent attribute — pass OPTIMIZELY_OPT_OUT=true as a query string or set the optimizely.opt_out cookie before SDK initialisation — which puts the SDK into opt-out mode where no identifier is written and no events are fired. The second is the anonymous-only mode supported in the SDK configuration, where the SDK runs in a sessionless mode that assigns variants based on session-local identification only, without persistent identification across visits. The anonymous mode allows the experimentation programme to run under a legitimate-interest basis for the rendering decision while deferring persistent identification until consent is granted.
The cookies and storage Optimizely writes
The Optimizely Web Experimentation SDK writes the following identifiers on initialisation, all of which are non-essential and require consent: optimizelyEndUserId with a multi-year expiry containing the persistent visitor identifier, optimizelyOptOut markers tracking opt-out state, optimizelyDomainTestCookie for cross-subdomain experimentation, and additional namespace cookies when the operator has enabled cross-domain identification. Withdrawing consent must therefore both expire the cookies and put the SDK into opt-out mode via optimizely.push({ type: 'user', attributes: { opt_out: true } }) to stop further event collection.
Mapping Optimizely to consent frameworks
Optimizely does not natively implement IAB TCF or the IAB Global Privacy Platform — it is a first-party experimentation platform, not an ad-tech vendor — but it does expose a native opt-out API, supports a documented Consent Mode integration via the Optimizely Data Platform, and respects the publisher's CMP via the OPTIMIZELY_OPT_OUT attribute. The pattern that survives a regulator's review treats each Optimizely capability as a separate gate bound to a specific CMP signal.
- Anonymous experimentation can run under a legitimate-interest basis with session-local identification, which is appropriate for rendering decisions that do not require persistent identification across visits and that do not propagate to downstream analytics. This mode binds to the strictly-necessary or functional category.
- Persistent experimentation with a stable identifier binds to the analytics purpose. In TCF terms this maps to purpose 8 combined with purpose 1; for Consent Mode this maps to analytics_storage.
- Cross-tool integration — variant exposure events propagated to Google Analytics, Amplitude, or the Optimizely Data Platform — inherits the analytics gate from the receiving tool and must not fire if that tool's gate is not granted.
- Personalisation and audience-based targeting built on top of experimentation engages the marketing gate because it crosses from experimental measurement into user-level targeting.
The integration pattern that works
The reference deployment has four parts: a CMP that exposes a real-time consent change event, a deferred bootstrap that initialises the Optimizely SDK with opt-out enabled or anonymous mode active, a consent listener that flips the SDK out of opt-out and starts persistent identification when the analytics gate opens, and a withdrawal path that puts the SDK back into opt-out mode, expires the optimizely cookies via document.cookie, and propagates the withdrawal to any downstream analytics integrations.
Web implementation with the deferred bootstrap
On the web the cleanest pattern is to load the Optimizely snippet with window.optimizelyOptOut = true set before SDK initialisation. Subscribe to the CMP's consent change event. When the analytics category transitions to true, call window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) and let the SDK initialise normally. When the gate withdraws, push the opt-out attribute back to true, expire the optimizelyEndUserId cookie, and propagate the change to any integrated analytics platforms via their respective consent APIs.
Server-side experimentation via the Decision Service
Optimizely also supports server-side experimentation via the Decision Service API. Server-side decisions are not exempt from consent — the legal basis follows the data — but server-side execution gives the publisher full control over which identifiers are propagated. The pattern that works is to pass an ephemeral session identifier to the Decision Service when the analytics gate is closed, and to switch to the persistent identifier only when the gate is open. The variant assignments returned by the Decision Service can still be applied to the rendered page; what changes is whether they are tied to a stable visitor record.
Validating the integration and the audit trail
The validation step is what regulators check and what publishers most often skip on experimentation tools. A correctly integrated Optimizely deployment must pass four tests in sequence. First, a clean browser session with the banner shown but no choice made must produce zero requests to logx.optimizely.com beyond the SDK file fetch and zero optimizely cookies in document.cookie. Second, declining analytics must keep that state — no persistent identifier, no decision event, no variant assignment tied to a stable record. Third, accepting analytics must produce the expected optimizelyEndUserId cookie and decision-event traffic, with the variant assignment correctly applied. Fourth, withdrawing consent must immediately stop further decision events, expire the cookies, and propagate the opt-out to any downstream analytics integrations.
The audit-trail expectation under the EDPB's 2023 cookie banner guidelines and the renewed 2026 task force priorities is that the publisher can prove, for any specific experimental exposure in the Optimizely project, that the visitor had given valid consent at the moment of exposure. The standard pattern is to set the consent version and timestamp as a custom attribute on the Optimizely visitor profile via the SDK's attribute API so that any individual exposure is traceable back to a specific consent log entry. A correctly gated deployment, paired with anonymous-mode handling for the pre-consent rendering decisions and a withdrawal path that propagates downstream, is what turns Optimizely from a hidden experimentation-tier liability into a defensible part of a publisher's product and growth stack.