Experimentation and personalization

Optimizely

Optimizely Web runs A/B tests and personalization by changing the page in the browser. The c15t optimizelyWeb helper waits for experience consent before it loads the Optimizely Web Experimentation or Personalization snippet. Until then, the helper creates no Optimizely global and makes no Optimizely request.

On withdrawal, c15t removes the snippet and reloads the page. The running SDK can't be unloaded, so without the reload it keeps changing the page and sending events.

Configure Optimizely

In Optimizely, open Settings > Implementation and copy the project number just before .js in the snippet URL. Replace the example project number below with yours. Use one Optimizely snippet per page. Remove the original Optimizely snippet and any tag-manager copy so c15t controls when it loads.

npm install @c15t/integrations

src/consent-scripts.ts

import { optimizelyWeb } from '@c15t/integrations/optimizely';

export const scripts = [optimizelyWeb({ projectId: '12345678' })];

The default loader URL is https://cdn.optimizely.com/js/<projectId>.js.

Register the scripts

Complete your framework quickstart first. Keep its Inth endpoint, policy, styles and consent UI. Remove the vendor's original script, SDK initializer or tag-manager entry, so the vendor loads only through c15t.

The vendor pages put the helper in src/consent-scripts.ts. If your framework quickstart already has a scripts array, such as the one in c15t.config.ts in the Next.js guide, add the helper to that array instead of creating a second file. The scripts export is a configuration, not an initializer. Add it to the c15t provider you already have, at the registration point for your framework below. These are edits to that provider, not a second provider.

Add the configuration to scripts in c15t.config.ts, next to next.config.ts:

import { defineConsentConfig } from 'c15t/next';
import { scripts } from './src/consent-scripts';

export default defineConsentConfig({ scripts });

Keep the rest of your config, such as mode and routePrefix, in the same call. ConsentRoot reads the config in the browser, so the layout keeps passing only state. App Router, Pages Router and static export all read the same file. See Next.js scripts and embeds.

Options

Option	Default	Behavior
`projectId`	Required	Public project number as a string or safe integer. Surrounding whitespace is trimmed. Use a string above `Number.MAX_SAFE_INTEGER`. Missing, blank, nonnumeric or unsafe numeric values log an error and skip the loader.
`category`	`'experience'`	Consent category or condition required before loading, such as `'measurement'` or `{ and: ['experience', 'measurement'] }`.
`scriptSrc`	`https://cdn.optimizely.com/js/<projectId>.js`	Custom snippet or proxy URL. The project ID is still required. A blank override uses the default. This doesn't proxy the SDK's other requests.
`nonce`	None	CSP nonce for the loader element. Surrounding whitespace is trimmed. You can also supply the nonce through your consent provider.

Optimizely leaves cookie classification to the site owner. The helper uses experience because the snippet changes and tests user experiences. If your policy also requires measurement consent, pass both categories in an and condition.

Loading and revocation

Page flicker

After consent, c15t inserts the loader into <head> with async: false. Optimizely activates the configured experiments when the snippet runs. The helper doesn't call sendEvents, start a second SDK or replace an existing window.optimizely.

Optimizely recommends a synchronous snippet near the start of <head> and warns against loading it through a tag manager. A script inserted at runtime with async: false doesn't block the HTML parser. While c15t waits for consent, visitors can see the original page before Optimizely applies a variation. Plan your experiments for this flicker and for visitors who don't grant consent.

The helper has no early-load or event-holding mode. Optimizely's holdEvents API holds event delivery, but the SDK still runs and queues events in localStorage. sendEvents releases those queued events, including events stored on earlier pages. Loading the snippet early would break this helper's consent gate.

Revocation

Keep your provider's reloadOnConsentRevoked enabled. When a visitor revokes the mapped category or turns off the Optimizely vendor, c15t removes the loader and reloads the page after pending saves settle. The new page keeps the snippet blocked until consent is granted again.

The standalone core createScriptLoader removes script elements but doesn't reload the page. If you use it directly, your app must persist the denied choice and reload. Permission changes caused by expiry or policy updates also don't trigger the provider's visitor-action reload.

Removing the loader doesn't unload the running SDK, undo its page changes or delete its cookies and localStorage. A browser can also finish running an in-flight script after its element is removed. Optimizely can keep running until the page unloads, including while c15t waits for a save to finish. The reload ends it in the current document. If you turn reloads off, the helper can't make Optimizely stop tracking or changing the page after revocation.

Optimizely documents disable for calls made before the snippet loads. It isn't a documented way to stop a snippet that is already running. holdEvents also leaves local collection active, so it isn't a full stop API.

Persistent Optimizely opt-out

For a deliberate persistent opt-out, import optOutOptimizely from @c15t/integrations/optimizely and call optOutOptimizely(). It sends window.optimizely.push({ type: 'optOut', isOptOut: true }) through an existing SDK or queue, and does nothing if neither exists.

Optimizely records this choice in the ten-year optimizelyOptOut cookie. Granting consent again in c15t doesn't clear that cookie, so the helper never calls this utility on ordinary revocation. The command returns no completion promise and doesn't undo changes already applied to the page. Keep the page reload enabled when you use it.

To reverse an explicit opt-out after the visitor grants consent, follow Optimizely's cookie implementation guidance: delete optimizelyOptOut or set its value to false, using the cookie's existing domain and path, then reload or navigate to another page. On that page, c15t must allow the snippet to load. Optimizely's API reference warns that an opt-in command alone can't restart a snippet blocked by the opt-out cookie. Your app must reset the cookie; optimizelyWeb and optOutOptimizely don't.

Cookies and localStorage

Optimizely's storage reference lists these first-party cookies. Browser policies can shorten their lifetimes.

Cookie	Documented lifetime	Purpose
`optimizelyEndUserId`	Six months from the last visit, configurable	Visitor identifier.
`optimizelySession`	Six months	New or returning session detection.
`optimizelyRedirectData`	Five seconds	Data passed across redirect experiments.
`optimizelyDomainTestCookie`	Removed right after a successful test	Domain detection.
`optimizelyOptOut`	Ten years	Persistent Optimizely opt-out. The helper sets no opt-out cookie itself.

The SDK stores events, experiment assignments, visitor profiles and pending requests under localStorage keys that start with optimizely_data$$. The full key includes the visitor ID and the project or account namespace, followed by a name such as events, event_queue, variation_map, session_state, visitor_profile, layer_states, layer_map, tracker_optimizely, pending_events or contextual_mab.

Cross-origin tracking can use origin-specific prefixes and sync through an account-specific cdn.optimizely.com origin. Edge Delivery can add OPTY$$...$$VPROF and OPTY$$...$$VMAP cookies with six-month lifetimes. Sampled Real User Monitoring uses session cookies on rum.optimizely.com, including AWSELB, AWSELBCORS and optimizelyRumLB. This helper loads the browser snippet. It doesn't configure an Edge Delivery worker.

A reload keeps existing storage. Use your framework's clear-on-revocation configuration to remove the storage your site uses. Check the actual names and domains in DevTools. Cleanup on your origin can't clear cookies or localStorage on an Optimizely-owned origin. Optimizely warns that cookie and localStorage formats can change, so don't read them as an app API.

Verify Optimizely

Use your own test project. With consent denied in a clean browser profile, filter Network by optimizely.com and check that the snippet doesn't load. The optimizely global, Optimizely cookies and localStorage keys should be absent.

Grant the mapped consent and check for the project .js request. After a valid snippet runs, window.optimizely.get is a function. That shows an SDK API exists, not that a particular experiment activated or an event was accepted. Check experiment targeting and behavior in your test project. Deny the vendor inside an allowed category and confirm that the reload blocks its snippet too. Grant again to confirm that ordinary revocation hasn't created a persistent opt-out. If you use optOutOptimizely, also test the cookie reset and reload described above before you expect a later grant to resume experiments.

Sources: implement the one-line snippet, hold and send event timing, disable API and persistent opt-out API.

Test in a private window with an opt-in policy. Open DevTools Network, disable the cache and filter by the vendor's domain:

Load the page. No request goes to the vendor before you choose.
Click Reject, then reload. There is still no vendor request.
Open Privacy settings and allow the helper's category. The vendor script loads without a page reload.
Turn the category off again and save. c15t reloads the page, and the new page makes no vendor request.

c15t reloads on revocation because removing a script element does not stop code that already ran. The vendor's listeners, timers and queued events stay alive until the page unloads. If you set reloadOnConsentRevoked: false, stop the vendor yourself. Register a callback-only script whose onConsentChange calls the vendor's opt-out API, as shown in custom integrations, and check the permission before each of your own event calls. The reload does not delete cookies the vendor already set; see clear on revocation for your framework.

The helper lists its vendor by name in the preference dialog, so a visitor can turn it off inside an allowed category. See vendor consent for your framework. The consent verification guide covers navigation, expiry and hosting checks.