How Optimeleon works
Four layers (understanding your page, generating variants, serving them at the edge, and measuring the outcome) wrapped in a loop that never stops running.
Optimeleon is a loop, not a tool you operate. It decomposes into four layers, and every page you optimize travels through all four, continuously.
| Layer | What happens |
|---|---|
| Page understanding | A scan reads the live page: its sections, its product, its audiences, its claims, its voice. The result is what you see in Brand Center, and it is the raw material for everything that follows. |
| Variant generation | Leo proposes competing directions, then builds the one you pick, in a real browser, on your real page, checking itself on desktop and mobile as it goes. |
| Edge execution | Published variants are served from Optimeleon's edge network. The decision about which version a visitor sees is made before your page paints, so there is no flash of the original. |
| Tracking | Pageviews, behavior and your conversion events flow first-party to Optimeleon's own collector. That data is the reward signal the optimizer learns from. |
Continuous optimization, not discrete A/B tests
This is the difference that matters most, and it changes how you should think about the product.
A classic A/B testing tool asks you to define an experiment, freeze it, wait for significance, declare a winner, and start over. Optimeleon runs one campaign per page, indefinitely. New variants join it as new arms. Strong arms gain traffic, weak ones lose it, and arms that have clearly been beaten are retired to make room for what comes next. You are never between tests, because there is no such thing as between tests.
Concretely: one Page has exactly one active Campaign at a time, and that campaign accumulates Variants over its lifetime. You evolve it in place.
How traffic gets allocated
Allocation is handled by an algorithm built on multi-armed bandit theory, and it does two jobs rather than one.
It reallocates. Instead of splitting traffic evenly until a fixed sample size is reached, it re-decides continuously, weighing how confident it currently is about each version. Versions that keep converting earn more traffic. Versions that keep losing get less.
It also swaps. A version that has clearly lost is not left running at a trickle for the rest of the campaign's life. It is retired, and the capacity it was occupying is freed for a new version to move into. The line-up turns over.
That second half is what makes a campaign genuinely continuous rather than a slowly ossifying set of arms, and it is why a losing variant costs you far less here than in a fixed-split A/B test. You stop paying for it while the evidence comes in rather than after the test concludes, and its place goes to your next idea.
What the script actually does
The snippet you paste installs three things, and it is worth knowing which is which when you are debugging.
| Part | Job |
|---|---|
/b/ | The experimentation bundle. Fetches the variant decision for this visitor and applies it to the page. This is what claims the window.optimeleon function. |
/c/ | The tracking bundle. Owns capture: pageviews, behavior, your conversion events. Loads in parallel with /b/, never behind it. |
| Inline bootstrap | A few hundred bytes that run during HTML parse: a queue so early calls are never lost, and the anti-flicker guard. |
Anti-flicker
If a variant were applied after the original had already painted, visitors would see the page change under them. To prevent that, the inline bootstrap hides the body the moment it parses and reveals it as soon as the decision has been applied.
Hiding a page is only safe if the un-hiding is guaranteed, so the guard also carries its own timeout. If the bundle never loads at all (a CSP blocks it, an ad blocker eats it, the network is down), the page reveals itself anyway after roughly 800 ms. Your page can never stay blank because of Optimeleon.
<head> as you can put it, and why it must not be deferred, delayed, or moved into a tag manager. Every millisecond the bootstrap is late is a millisecond closer to a visible flicker. See Google Tag Manager and WordPress & caching.Measurement is consented-only
Optimeleon captures nothing before a visitor grants analytics consent. No events, no cookies, no visitor id.
This has one important statistical property. Because consent does not depend on which variant a visitor is served, measuring only consented visitors gives you a smaller sample, not a biased one. You reach confidence more slowly. You never reach a skewed answer.
Variants still serve to everyone, consented or not, so visitors always see the optimized page. Only the measurement waits.