Snippet order of activation

  • Updated
  • Optimizely Web Experimentation
  • Optimizely Web Personalization

Optimizely Web Experimentation creates experiments on your site by executing a specific JavaScript snippet configured for your account and page. This snippet automatically updates every time you create, modify, or archive any asset or setting compiled into the snippet. The snippet makes your experiments work.

This article explains the snippet's order of operations. Knowing this can help you design more effective experiments that do not detract from your site's user experience. It is also a good place to troubleshoot timing issues in your experiments.

Order of snippet activation

When the snippet loads on the page where your experiment lives, it applies API calls in the window.optimizely array and runs Project JavaScript. When the snippet activates, it evaluates the URL targeting in the project. The snippet also can be reactivated after this point using the activate API call. Optimizely Web Experimentation pages include targeting conditions for the pages on your site and an activation mode (optional), which determines when the page targeting conditions are evaluated.

When the page's activation trigger fires and targeting conditions are passed, the page activates. Any page, regardless of activation mode, may also be triggered by name at any time by the page API call.

When a page activates, Optimizely Web Experimentation evaluates the experiments that include that page.

For each experiment that is included, Optimizely Web Experimentation evaluates whether a visitor is eligible to enter the experiment. Visitor eligibility is evaluated based on the experiment's traffic allocation and audience conditions.


If any audience conditions cannot be determined for a visitor based on known information (for example, geolocation), Optimizely Web Experimentation may wait a short time to gather this information before deciding whether the visitor qualifies for the audience.

If both audience and traffic conditions are passed, the experiment activates. 

Each visitor who is allocated to an experiment is assigned to a variation (which may be the control, or "original," variation). Based on the number of variations and the bucketing probabilities described by the experiment's traffic distribution, the visitor is bucketed into a specific variation. A decision event is logged at this stage.

After a visitor is bucketed into a variation (which determines what changes are made to the webpage), the snippet executes the code that applies those changes.

After all pages are evaluated and changes from relevant experiments are applied, the rest of the webpage loads.

When a visitor interacts with the webpage, they may trigger a conversion event that is tracked by Optimizely Web Experimentation. Optimizely Web Experimentation records the event and associates it with the variation.

You can follow a snippet's execution by reading the console logs.

How Optimizely Web Experimentation executes code

Shared custom JavaScript and CSS code run for all variations, including the original. Shared CSS and JavaScript code run immediately, exactly as written. All timing considerations must be written into the code itself.

At the variation level, changes from the Visual Editor can be configured to either run in sequence (where making one change depends on a prior change) or in parallel (where all changes execute as soon as the selector is ready). In contrast, variation custom code executes immediately, exactly as written. All timing considerations must be written into the code itself.

Custom variation CSS is added as a style tag to the bottom of the head.

How events are fired

Optimizely Web Experimentation tracks events that you configure, such as click and custom events. The snippet also natively emits certain events, such as when a visitor is bucketed; you can monitor these via Optimizely's event listeners. All events are emitted immediately when the triggering event occurs.

However, event tracking for Optimizely's Experimentation Results service can occasionally be delayed for data analysis and performance purposes. For example, the activation of a page may not be emitted until DOMContentLoaded to support the inclusion of visual tags with the event payload.