Consent & cookies

Optimeleon is suppress-only. Until a visitor grants analytics consent, it sends no analytics events, builds no visitor id, and writes one entry to the device: a per-tab note of which version the tab was shown. This is the default on every page and it does not branch on the visitor's country.

Variants still serve before consent, so the visitor sees the optimized page. Only the measurement waits.

Two technical signals can reach Optimeleon before consent, and neither carries a visitor id: the one-off check sent when you open your site with the install test link, and a notice when your site serves a copy of the Optimeleon script instead of loading it from us.

The consent API

window.optimeleon('consent', { analytics: true,  marketing: true  }); // grant
window.optimeleon('consent', { analytics: false, marketing: false }); // withdraw

window.optimeleon(…) is available immediately. The inline bootstrap installs a queue, so calls made before the bundle finishes loading are replayed in order. Call it on every page load with the visitor's stored choice, as early as your CMP knows it, not only when the banner is clicked. Calling it again later, when the visitor changes their mind, is honoured at any point in the page's life.

• Pass a boolean per category. Unknown categories and non-boolean values are ignored, so forwarding extra categories from your CMP is safe.
• Omitting a category leaves it unchanged.
• Repeating an identical signal is a no-op, with no double counting and no churn.

What a grant and a withdrawal do

Returning visitors

A visitor who consented on an earlier visit still has Optimeleon's identity in their browser. Optimeleon does not treat that as consent on its own. On every page it waits for your CMP's answer before it records anything, and in the meantime only reads what it stored earlier, so the visitor keeps the version they saw.

The last row is why the stored choice has to reach Optimeleon on every page load. A CMP that only reports when the banner is clicked makes Optimeleon wait out those 3 seconds on every page, for every returning visitor.

Mapping your CMP's categories

Optimeleon's storage falls under analytics / statistics in standard taxonomies.

Example: Cookiebot

window.addEventListener('CookiebotOnConsentReady', function () {
  window.optimeleon('consent', {
    analytics: Cookiebot.consent.statistics,
    marketing: Cookiebot.consent.marketing,
  });
});

Example: Google Consent Mode

// Wherever you already react to a consent update:
window.optimeleon('consent', { analytics: analyticsStorageGranted === 'granted' });

If your cookie tool blocks scripts automatically

Some cookie tools block scripts on their own, without you marking them up. Cookiebot does this when its script tag carries data-blockingmode="auto". Usercentrics, OneTrust and consentmanager call it auto-blocking, and TrustArc does it in Strict Mode. In that mode the tool can block Optimeleon for every visitor who declines cookies or has not chosen yet. Your page still loads, but those visitors only ever see the original version.

Optimeleon does not need to be blocked: it sends nothing and stores nothing identifying until the visitor grants analytics consent. So tell your cookie tool to let it load:

1. In Optimeleon, open Setup (or Settings → Script & tracking) and pick your cookie tool just above the tracking code.
2. Copy the code again. Every Optimeleon <script> tag now carries your tool's exemption.
3. Replace the code on your site. Then open a page in a private window, choose “necessary cookies only”, and check that it still loads.

Using a tool that is not listed, such as CookieYes or Osano? Set it to always allow scripts from edge.optimeleon.com. Automatic blocking can also catch your own site's code, so if parts of your page stop working after a visitor declines, check which of your own scripts the tool blocks before looking at Optimeleon.

Cookie and storage reference

Register these in your CMP. Match by exact name, except __opti_cap_assign and __opti_route_cache, whose runtime keys carry your project's edge token as a suffix. Register those two by prefix, as __opti_cap_assign* and __opti_route_cache*.

Before consent: one entry, strictly necessary

Before consent Optimeleon writes exactly one entry. No cookies, no localStorage, no technical checks.

Why it is strictly necessary. The version a visitor sees is decided fresh on every full page load unless something remembers the last decision. Without this entry, a visitor who has not answered your banner, or who declined, would see a different version on every reload: a confusing page for them, and a contaminated result for you. It is the minimum that prevents that, and before consent it is used for nothing else.

A withdrawal erases it along with everything else. A plain decline does not, so the visitor keeps a stable page for the rest of the visit.

After analytics consent: statistics

Every key below is written only after an analytics grant, except the momentary cookie check noted in its row, and is cleared when consent is withdrawn. Two of the lifetimes are your settings: the cookie and storage duration (365 days by default) and the session timeout (30 minutes by default), both in Settings → General.

Shopify checkout adds two

Opening your site with a debug or preview parameter, or through a preview link, writes a few more keys in that browser. They exist for testing, and an ordinary visit never writes them. See Preview & debug.

Test your integration

1. Open a campaign page in a fresh private window and decline analytics. In DevTools → Application there should be no Optimeleon cookie and no localStorage key. The only sessionStorage key is __opti_cap_assign:…, once a variant has been served. Reload a few times: the variant must not change.
2. Accept analytics. The __opti_vid cookie appears on your top-level domain, along with the keys in the statistics table above.
3. Reload. In the browser console, optimeleon('consent') should report resolved: true almost at once. If that takes about 3 seconds, your CMP is not passing on the stored choice at page load.
4. Withdraw. The cookie is removed, every key in the statistics table is cleared, and so is the per-tab note.

Cross-subdomain identity

The __opti_vid cookie is written at your apex domain, so a visitor recognised on www.example.com is the same visitor on shop.example.com. __opti_arm carries the served variant across that boundary for a short window, which is what lets a purchase completed on another subdomain be credited to the variant that earned it.

Every subdomain involved still has to be on your tracking allowlist.

What Optimeleon never does

• No IP storage. A visitor's IP is used momentarily to estimate a rough city, then dropped.
• No personal profiles. Everything ties to a random id, never a name or an email.
• No third-party ad tracking. No advertising cookies, no outside ad-network trackers. Data goes only to Optimeleon's own collector at edge.optimeleon.com, and is never sold or shared with ad networks or data brokers.
• On Shopify, a purchase is recorded with its amount, currency and products, never the order number, the checkout token, or any customer detail from your admin.

Retention and visitor rights

Analytics is deleted 12 months after it is recorded, plus up to one further month to complete a late deletion request, and never beyond 13 months. That policy is fixed.

What sits in the visitor's browser lasts as long as your cookie and storage duration: 365 days by default, and anything from one day to a year in Settings → General. The storage table above says what each entry counts from. Shortening the duration also applies to what is already stored: entries past the new limit are deleted on that visitor's next page view. A visitor can clear them, or withdraw consent, at any time to remove them immediately.

If a visitor asks to see or delete their data, send us their visitor id and we will export or erase their records. Deleting a project removes all of its data.