Identifying visitors

For the developer wiring Optimeleon into a site that already knows who its visitors are: a logged-in account, an existing first-party analytics id, a CRM key. Handing Optimeleon that id makes the version a visitor sees a deterministic function of the id: the same person sees the same version on their phone and their laptop, this week and next. This describes shipped behavior.

This is optional. Without it, a visitor's version is stable for the whole visit (the __opti_cap_assign entry described in Consent, cookies & privacy) but a new tab or a new device starts fresh.

The snippet

Paste this above your Optimeleon install snippet, in the <head>:

<script>
  window.optimeleon =
    window.optimeleon ||
    function () {
      (optimeleon.q = optimeleon.q || []).push(arguments);
    };
  optimeleon('identify', { visitorId: 'YOUR_STABLE_VISITOR_ID' });
</script>

Replace YOUR_STABLE_VISITOR_ID with the id your own code has for this visitor. Render nothing at all for a visitor you cannot identify: never a placeholder, never an empty string.

If the Optimeleon snippet is already on the page, optimeleon('identify', { visitorId }) works on its own; the three-line stub above exists so the call also works when it runs before the snippet, which is where you want it.

Where to put it

• Above the install snippet is strongest. The call is then read before Optimeleon asks which version to show, so the very first page the visitor sees is already decided from your id.
• A late call is safe, and it is late. Calling identify after the page has been decided (from a router hook, after a login round-trip, from a tag manager) never changes the version already on screen. Optimeleon will not re-decide a page under a visitor who is already reading it. The id is kept for the tab and takes effect on the next page load.
• Calling it on every page load is correct and cheap. Calling it twice on one page is a correction: the last usable id wins.

What makes a good id

• Stable. The same person must get the same string every time. An id that changes per session buys you nothing over the default.
• Opaque. An account key, a UUID, a hash. Never personal data: no email address, no phone number, no name, no order id that resolves to a person in your systems. If the only stable key you have is an email, hash it (SHA-256 of the lowercased address, for example) and pass the hash.
• At most 128 characters, after leading and trailing whitespace is trimmed.
• Compared as an exact string. User_1 and user_1 are two different visitors.
• Anything unusable is ignored. A non-string, an empty or whitespace-only value, or an id past 128 characters leaves the visitor exactly where they would be without the call: it never breaks serving and never throws into your page.

What it guarantees

The same id gets the same version, on any device, for the same experiment. For an experiment with a fixed split, that is unconditional: the version is computed from the id, so it needs nothing stored, survives a new browser, a cleared cache, and a different device, and does not expire.

Two different ids on the same browser get independent versions, which is what a shared device needs. And a visitor whose id disappears (they log out) keeps the version they had: signing out is not a reason to change the page under someone.

On Smart Allocation

When a campaign runs on Smart Allocation, Optimeleon moves traffic toward the version that is winning. Cross-session assignment then follows the allocation in force at the moment the visitor is decided, and those weights move as the campaign learns. So within a visit the version holds still, and a visitor returning next week under a shifted allocation may be decided differently. The guarantee above is exact for a fixed split, and "follows the current weights" under Smart Allocation. If you need cross-session determinism for an analysis, run that experiment on a fixed split.

Turning it on for an existing campaign

Visitors who are already mid-visit keep the version they have. A version that was decided before your id arrived is honoured until it would naturally be decided again, so nothing flips on the day you deploy the snippet. From then on, every fresh decision uses your id.

If you want every visitor decided by id from a single instant, start a fresh experiment instead: a new campaign decides everyone from scratch.

Privacy

• The id never leaves the browser. Optimeleon derives an opaque, project-specific draw key from it and uses that to pick the version. The key cannot be turned back into your id, and the same person is uncorrelatable between two Optimeleon customers.
• It is never attached to analytics events, and it is never retained on our servers. Nothing in your Optimeleon reporting is keyed to it.
• It is not stored on the device either. Only the derived key is kept, inside the __opti_cap_assign entry you already declare. identify adds no new storage key, so your cookie declaration does not change.
• It has no effect on consent. Analytics capture stays fully gated on an analytics grant, exactly as described in Consent, cookies & privacy. Calling identify neither grants nor implies consent.

Passing your own id is your decision as controller: make sure the id you hand over is one you may use for optimising your own site, and that your privacy notice reflects it.