How to use the Avada Marketing Experiments Feature

Last Update: October 20, 2026

Experiments let you split traffic between two or more versions of a page, measure which one performs better, or simply watch a funnel of visitor behaviour — all without leaving the page builder. This guide covers setup, traffic splitting, conditional rendering, events, and results.

1. What it’s for

Experiments is a built-in split-testing and behaviour-analytics engine, sitting alongside Contacts, Campaigns, Abandoned Cart and Links in the Marketing area. Every experiment is one of two types:

Split test — Two or more variations compete for traffic. Visitors are randomly bucketed into one variation, and elements or containers render conditionally based on that assignment: a true A/B (or A/B/n) test.
Analytics — No splitting. A single “Global” variation is created automatically so you can track a funnel or conversion rate on a page or flow, without changing what any visitor sees.

2. Turning it on

Experiments depends on visitor tracking, which has its own consent-aware switch. Go to Avada > Global Options > Marketing > Experiments & Links:

Visitor Tracking — master switch. Must be on for anything below it to work.
A/B Testing — enables the Experiments module itself. Requires Visitor Tracking.
Anonymize IP — strips the last IP octet before it’s used for geolocation or cookieless bucketing.
Geolocation — optional. Powers the country/continent breakdown in Audience results.

Once enabled, the module lives at Avada > Marketing > Experiments in wp-admin.

3. Creating an experiment

Open Experiments > Add New. Every experiment is built from four sections, saved together.

Step 1: Details

Name it, describe what you’re testing, and choose the type (Split or Analytics). The Active switch is also the start/stop control — there is no separate “launch” step. Turn it off to pause; turn it on to resume where it left off.

Step 2: Variations

Add a row per version you want to test, for example “Control” and “New Headline”. Each has a weight slider (0–1) that sets its relative share of traffic; weights don’t need to add up to 1, they are normalised against each other. Each variation can be switched active or inactive independently.

Important: a Split test needs at least two active variations. With only one, there is nothing to compare — the builder warns you, and that single variation is silently excluded from the condition picker in Step 5, since it would always be “active” for everyone.

For an Analytics experiment you can skip this step. Leaving it empty auto-creates one “Global” variation at 100% weight.

Step 3: Conditions

This is audience/page targeting for the experiment as a whole — the same condition builder used everywhere else in Avada (page, post type, user role, device, date range, and so on). It decides whether the experiment runs at all for a given request, before any variation is picked.

Step 4: Events

Attach one or more events to measure — either create a new one or reuse an existing definition from another experiment. Mark any event as the conversion (goal) for this experiment; that’s the metric used to judge a winner. See the Events & Goals section below for the full type list.

Saving posts everything in one call. Useful row actions from the list view: Clone (duplicates variations and events, resets impression counts for a clean re-run) and Delete (single or bulk).

4. How visitors get split

Assignment happens on the server, on the first request of a visit — not in the browser after the page has already rendered, so there is no flash of the wrong variation.

A new visitor requests a page.
Avada checks for an existing assignment: a cookie named awb_exp_, or (if cookies aren't available yet) a deterministic hash of the visitor's IP and the experiment ID.
If an assignment already exists, the same variation is reused.
If not, a variation is picked at random, weighted by each active variation’s weight.
The assignment is stored for one month, and the chosen variation’s impression count is incremented by one.

Once a visitor lands in a variation, they keep seeing it for the life of the cookie (or hash bucket, if consent hasn’t cleared cookies yet), so results aren’t muddied by people flipping between versions.

Consent-aware fallbacks

Depending on your site’s tracking level and the visitor’s consent state, assignment uses one of three strategies automatically — this isn’t configured per experiment:

Strategy	When it’s used	How it sticks
Cookie	Normal case, consent granted	`awb_exp_{experiment_id}` cookie, 1 month
IP + ID hash	Consent pending / cookieless mode	Deterministic checksum of (anonymised) IP + experiment ID — same visitor, same bucket, no cookie
Session only	Tracking capped below full	Re-evaluated if it can’t persist across visits

5. Showing variants on the page

Variations don’t create separate pages — you build one page and use a render condition to show or hide the pieces that differ.

Select the element or container to vary. This can be a container, column, or individual element: a headline, a button, a whole section.
Add a condition of type “Experiment Variation”. It appears in the Marketing group of the condition builder, alongside User Role, Device, Date Range, etc.
Pick the experiment and variation, and a comparison. Experiments are listed as group headers with their variations underneath. Choose Is Active to show this element when the visitor is bucketed into that variation, or Is Inactive to show it to everyone else.
Repeat for each variation’s content. Build the “Control” version of a section with Variation A > Is Active, and the alternate version with Variation B > Is Active, so exactly one shows per visitor.

This reuses Avada’s existing conditional-rendering engine end to end. It is evaluated server-side during the page render, the same as every other condition type, so there is no client-side swap or layout flash.

6. Events & goals

An event is a trackable interaction. Attach one or more to an experiment in the Events step, and flag one as the conversion — that’s your goal metric. Events fire either in the browser (JS) or on the server (PHP).

Event	Fires on	Typical use as a goal
click	JS	CSS selector + which mouse button, e.g. a CTA button
element_view	JS	Element scrolled into view past a set % threshold
page_view	PHP / JS	Any page, a specific post, or URL match; JS mode if you also require time-on-page or scroll depth
form_submit	JS	Lead-gen and contact forms
custom	JS	Anything you fire yourself against the tracker
add_to_cart	JS	WooCommerce add-to-cart
checkout	PHP	Checkout page reached
purchase	PHP	Order complete — the primary revenue goal; filter by product and minimum order value, de-duplicated per order
cart_abandoned / cart_recovery	PHP	Back the Abandoned Cart feature
product_wishlisted	JS	Wishlist add
product_compared	JS	Product Compare add
price_tracker_subscribe	PHP	Price-drop alert sign-up

Tracking frequency

Each event on an experiment sets how often one visitor’s action counts, checked against their session so it can’t be gamed by refreshing:

Every time — logs every occurrence.
Once per page — one log per page load.
Once per session — one log for the whole visit, useful for goals like Purchase.

Reusable definitions: events are stored independently of experiments. Build a “Newsletter Signup” click event once and attach it to several experiments via “Select Existing Event”, instead of redefining it each time.

7. Reading the results

Open an experiment from the list to see its report, broken into a few views:

Overview & variations — per variation: impressions, sessions, event counts, and two conversion rates — gross (conversions ÷ sessions) and flow (unique converting sessions ÷ sessions) — plus average time on page and scroll depth.
Funnel — pick a sequence of events and see the session drop-off from one step to the next, in order. Good for a multi-step signup or checkout flow.
Audience — breakdown by device, browser, platform and country (needs Geolocation enabled), filterable by variation.
Revenue — sums purchase events per variation into revenue, average order value and revenue-per-visitor, and names a winner: the variation with the highest total revenue, with its lift % over the first variation as baseline.

There is no stored “winner” field or status — every number here is computed live from the underlying event log each time you open the report, so it always reflects current data, including anything logged while the experiment was briefly paused.

8. Quick checklist

Enable Visitor Tracking and A/B Testing in Global Options > Marketing.
Create the experiment: name it, set type (Split to compare, Analytics to just measure).
Add at least two active variations for a Split test, with sensible weights.
Set page/audience conditions so it only runs where it should.
Attach the event(s) you care about and mark one as the conversion goal.
On the page, wrap each version of the content in an Experiment Variation condition matching the right variation.
Let it run, then check Overview / Funnel / Revenue for a clear lift before rolling out the winner permanently.