Execution Order

Every time a visitor loads a page on your website, the A vs B snippet does the same thing, in the same order. First, it reads your project's datafile (the small JSON file listing every live experiment for your project). A variation is one specific version being tested: the control or one of the challengers. Knowing the order tells you exactly when your variation code runs, when events are tracked, and what to expect when you debug.

The full sequence

The first tag hides the page, before any paint

The browser parses your <head> and runs the first of the two install tags. That tag defines the early-call queue (avsb.ready, avsb.on, avsb.consent.set). It also applies opacity: 0 to the <html> element while the page is still being parsed, so the visitor never sees the original content. The same tag starts a safety timer, 3 seconds by default, that reveals the page on its own if the bundle never arrives. This is called anti-flicker: hiding the page until the right variation is ready to show. See Anti-Flicker for the full detail.

The loader fetches the bundle

The second tag is async, so the browser downloads snippet.js from the CDN without blocking the rest of your page. The page stays hidden while this happens.

Datafile fetches from CDN

Once the bundle runs, it reads your snippet key from the loader tag's data-avsb attribute and requests the datafile described above. It is cached at CDN edge nodes close to the visitor, so this request is normally fast. Three things can go wrong here: a missing key, an unrecognised key, or a blocked request. Each prints its own plain-English console error naming the fix, for example [avsb] Snippet key "abc123" not recognised (404 ...). Check it in Project Settings > Snippet. Whichever happens, the snippet reveals the page rather than leaving it hidden.

Visitor cookie created or read

The snippet checks the visitor's browser for an existing A vs B cookie. A returning visitor's cookie holds their unique visitor ID and every past variation assignment. A first-time visitor gets a new visitor ID and a new cookie. This cookie keeps a visitor in the same variation on every later visit. That technique is called sticky bucketing (assigning a visitor using a consistent hash of their id, so they land in the same group every time).

Public API (window.avsb) initialized

The snippet builds the public window.avsb object. This is the interface your code, and your Project JavaScript, uses to talk to the snippet. Methods like avsb.track.event(), window.avsb.forceVariation(), and window.avsb.getVariation() are available from this point on.

Project JavaScript executes

If you have written any Project JavaScript, it runs now. You write it under Project Settings, Snippet tab. It always runs after the API is ready, but before any experiment is evaluated. This is the right place for global setup code, helper functions, or a call to window.avsb.forceVariation() for QA. See Project JavaScript for the full detail, including what happens if your code throws.

Each experiment is evaluated in order

The snippet works through every running experiment, one eligibility check at a time, then applies its variation. The full checklist is below.

Metric tracking is armed

The snippet sets up tracking for the metrics on running experiments. A click metric gets a click listener; a pageview metric gets an immediate URL check. This happens before the page is revealed, so a click in the first instant the page is visible is never missed.

Page is revealed

The snippet removes the inline opacity from <html>. It removes the style rather than setting it to 1, so a site that sets its own html { opacity } keeps that value. The visitor sees the page for the first time, already showing the correct variation.

Events are sent in batches

From here on, a metric event, a button click, a pageview, a custom event, queues the moment it fires. Queued events go out every 2 seconds, or the instant 10 are queued, whichever comes first. Leaving the page flushes everything immediately, using the browser's sendBeacon API. See Event Tracking for the full detail.

For each experiment, evaluation runs through this checklist, in order. Any failed check skips the experiment for this visitor:

URL targeting rules (conditions that decide which visitors see which variation): the current page must match them, or the experiment is skipped.
Audiences (named, reusable groups of visitors): if the experiment has one configured, the visitor must match it, or the experiment is skipped.
Traffic allocation is the percentage of visitors let into this experiment at all. This visitor must fall inside it, or the experiment is skipped.
Trigger: a custom trigger function, if the experiment has one, decides exactly when (and whether) the variation code is injected.
Variation injection: the variation's CSS goes into <head>, its JavaScript into <body>.

The two network fetches dominate: the bundle and the datafile, both served from a CDN edge close to the visitor. Everything after they arrive, bucketing, targeting, injection, is typically a handful of milliseconds. On a fast connection the whole sequence finishes before the visitor notices the page was ever hidden.

When a visitor navigates within a single-page application, the sequence above runs again from the Project JavaScript step onward. The install tags do not re-run. The visitor's cookie is already set, and the datafile is already in memory, so this re-run is much faster than the first page load.

The page is not re-hidden, since it is already visible. There is one exception. A split URL experiment redirects to a separate URL for its variation. If the new route matches that experiment's control page, the snippet re-hides briefly. This stops the visitor from seeing the control render just before the redirect. See SPA Navigation for the full details.