How Variant Delivery Works Internally

Most users don’t need to know how Nelio A/B Testing delivers variants behind the scenes—the plugin handles everything automatically. However, understanding the internal workflow can be helpful when troubleshooting caching issues, integrating with custom infrastructure, or simply satisfying your curiosity.

This article explains what happens from the moment a visitor requests a page until the correct variant is displayed.

Overview

When a visitor loads a page on your website, Nelio A/B Testing follows these steps:

1. Determine whether the requested page belongs to an active test.
2. Assign the visitor to a variant (or retrieve an existing assignment).
3. Deliver the correct version of the page.
4. Track page views and conversion events.

The exact delivery mechanism depends on the type of test and your site’s caching configuration.

Step 1: WordPress Generates the Page

Suppose a visitor requests the following URL:

https://example.com/some-page/Code language: JavaScript (javascript)

WordPress generates the page normally.

If the page is part of an active test, Nelio A/B Testing injects:

• an inline JavaScript configuration containing information about the active tests affecting the page; and
• the public tracking script responsible for variant selection, variant loading, and event tracking.

At this point, Nelio A/B Testing has not yet determined which variant should be displayed to the visitor.

Step 2: The Tracking Script Initializes

Once the browser receives the page, the tracking script checks whether the current page belongs to one or more active tests.

If the page is not affected by any test, no further action is required and the script simply tracks any relevant events.

If the page is under test, the visitor must be assigned to a variant.

Step 3: Assigning the Visitor to a Variant

Each visitor receives a random assignment the first time they participate in a test.

That assignment is stored in a browser cookie named nabAlternative.

The cookie ensures the visitor continues seeing the same variant during future visits, preventing inconsistent experiences and preserving the integrity of the test.

If the visitor already has a valid assignment, the existing value is reused instead of generating a new one.

Step 4: Delivering the Correct Variant

Once the visitor has been assigned to a variant, Nelio A/B Testing must display the corresponding version of the content.

If you’re running a CSS and Text test or a JavaScript test, the plugin can load the appropriate variant right away, because all the alternative information is already available in this first request.

However, if you’re using any other type of test, the plugin will need to reload the page to retrieve the appropriate variant using a query argument.

Option 1: Query-Argument Delivery

This is the default delivery method and is compatible with virtually every WordPress installation.

If the visitor should see the original version, no additional action is required.

If another variant should be displayed, the tracking script redirects the browser to the corresponding variant URL by adding the nab query parameter.

For example:

Original page
https://example.com/some-page/

Variant B
https://example.com/some-page/?nab=1

Each variant has its own URL, allowing cache plugins and CDNs to cache every version independently.

When the redirected page loads, the tracking script confirms that the displayed variant matches the visitor’s assignment and tracking begins.

Option 2: Cookie-Based Delivery (Dynamic Caching)

Some cache solutions support varying cached pages based on cookies. When dynamic caching is enabled, Nelio A/B Testing can deliver the correct variant directly from the cache without performing a browser redirect.

For example:

• if the nabAlternative cookie indicates Variant A, the cache serves Variant A;
• if it indicates Variant B, the cache serves Variant B.

This approach generally produces the fastest experience because visitors receive the correct version immediately. However, it requires a caching solution capable of varying cached content based on cookies.

For configuration instructions, see the caching documentation.

Step 5: Tracking Begins

Once the visitor is viewing the correct variant, Nelio A/B Testing starts tracking the test.

The tracking script records events such as:

• page views;
• conversion actions;
• custom goals;
• heatmap interactions (when enabled); and
• session recordings (when enabled).

Tracking data is sent directly from the visitor’s browser to Nelio Cloud, where it is processed and included in your test reports.

Your WordPress server is not responsible for processing analytics data, helping reduce server load.

Why Use This Architecture?

Nelio A/B Testing’s delivery system has been designed to balance compatibility, performance, and statistical reliability. Some of its advantages include:

• Visitors consistently see the same variant throughout the test.
• Most cache plugins work without additional configuration using query-argument delivery.
• Compatible cache systems can eliminate redirects through dynamic caching.
• Analytics are processed in Nelio Cloud instead of your WordPress server.
• The tracking script remains lightweight to minimize its impact on page performance.