Install the Tracking Code Synchronously (and Why)

Overview

The Explore tracking code can be integrated synchronously or asynchronously, either directly on your website or through a tag management system. Through a tag manager, it always loads asynchronously.

We strongly recommend synchronous integration, placed in the <head> of your website, for a seamless user experience during A/B testing and personalization.

Why synchronous matters

Loading the tracking code asynchronously instead of synchronously causes several problems:

The flicker effect

Asynchronous loading creates a flicker that looks unpolished and can confuse visitors, especially with substantial changes - imagine removing a wishlist button in a test, right after the visitor clicked it.

Warning

Flicker doesn't just look bad - it can contaminate your experiment results. The flicker draws attention to the modified elements, changing how visitors interact with them compared to how they would without the flicker. If that variation wins and you implement it permanently, visitor behavior on the live site may differ from what you measured during the experiment.

Undesired interaction with Control and Variation

A visitor may briefly interact with the Control before the Variation loads and overrides it. Example: an experiment that pre-ticks checkboxes in a form (vs. unticked by default in Control) - a visitor might start ticking boxes manually, then have the Variation tick all of them, forcing them to untick some afterward.

Inconsistent display across multiple pages

If the same design change is meant to appear consistently across several pages, async loading can create a visibly different experience from page to page, even though the intent was a single unified design.

Coordination of elements

Beyond A/B tests, other features are affected too - like an Overlay's configured delay. A 3-second delay could effectively become 5, 7, or 10+ seconds depending on what other scripts load before the Explore code (especially likely in tag managers if Explore's script has low priority).

Tracking accuracy

The sooner the tracking code loads, the sooner other elements on the page can be tracked - even ones unrelated to the current experiment. Example: an experiment changing a product page's image gallery still needs accurate "Add to cart" tracking; the earlier the code runs, the more accurate that data will be.

If synchronous in `<head>` isn't possible

In order of preference:

Asynchronous, as high in the page as possible.
Deferred (including at the end of <body>) - similar approach, but with weaker tracking accuracy.
Via a tag manager - the last choice. If used, ensure the Explore script has the highest possible priority.

Expected loading time impact

Asynchronous - page loading time is unaffected. Perceived delay averages 50ms, or around 150ms if experiments are active on the page (with a small flicker visible for active A/B tests).
Synchronous - better user experience with no flicker, but perceived loading delay is roughly 60-300ms.

What happens if the Explore server stops responding?

In this extreme scenario, active experiments simply won't trigger and their results are unaffected. Worst case, there may be a small delay of around 1 second in page load time - other elements and resources on your website are not affected.

Note

This 1-second threshold is Explore's protocol for emergency situations: the tracking code skips loading and won't apply any changes if load time exceeds 1 second, to prevent any negative influence on your page's load time or user experience.

If you want to avoid even the small perceived delay temporarily, disable the tracking code rather than removing it from your website - this avoids losing your experiments' historical data.

Slow connections and Loading Tolerance

If a visitor's connection is slow, the tracking code has a security check called Loading Tolerance that skips applying changes entirely, rather than influencing the page's load time or user experience. See Configure Website Settings for how to adjust this.