Experiments (A/B Testing)

An experiment splits your traffic between two or more versions of a funnel and measures which one earns more. You decide what to compare, web2wave assigns every visitor to a variant and keeps them on it for their whole journey, and the results view shows how each variant performed.

There are two ways to run a test:

Route users to different funnels. Half of your traffic gets paywall A, half gets paywall B. Each user sees exactly one of them. Use this for structural changes — a different paywall layout, a different set of plans, a different quiz flow.
Change content inside one funnel. Everyone stays in the same quiz, but a headline, an image or a button label differs per group. Use this for copy and design tests. Several of these can run at the same time for the same user. This mode needs Allow experiments intersection and conditional logic.

Don't see Experiments in the sidebar? Access comes with your project role — the Analyst and Editor roles include Experiments. Ask your project owner to update your access in project settings.

Before you start

Write down one hypothesis and one primary metric. "A shorter plan list increases subscriptions" is testable. "Make the paywall better" is not.
Pick the distribution point. This is the quiz or paywall that all of your traffic already reaches — the step where the split happens. It's what you put in Run on, and your campaign links keep pointing at it, unchanged.
Prepare the variants. For a routing test, duplicate the quiz or paywall you're testing and change one thing in the copy. One change per experiment keeps the result readable.
Check you have the traffic. Aim for a few hundred conversions per variant before you expect a verdict. On low volume, test big changes, not button colours.

Step 1 — Create the experiment

In the cabinet, switch to the project you want to test.
Click Experiments in the left sidebar. You'll see every experiment in the project with its current status.
Click New Experiment.

Fill in the basics:

Field	What to put there
Name	Something you'll recognise in three months — what changes and when, e.g. `Paywall — 3 plans vs 4 plans — May`
Project	The project the experiment runs in
Type	What you are comparing: Quiz or Paywall
Run on	The distribution point — the quiz or paywall your traffic already lands on. Users who open it are the ones the experiment splits
Start date	When assignment begins
End date	Optional. Leave it empty to run until you stop it yourself

Step 2 — Add variants and set the split

Each variant points to a quiz or paywall and carries a share — the percentage of users who will be sent to it.

Field	What to put there
Variant name	A label you'll read in the results, e.g. `Control`, `Variant A`
Quiz / Paywall	What users in this variant will see
Share (%)	Percentage of newly assigned users. All shares must add up to 100%

Example — a 50/50 paywall test

Control → your current paywall → 50%
Variant A → the new paywall → 50%

A few rules worth knowing:

Shares must total 100%. Uneven splits are fine — 80/20 is a good way to try something risky on a small slice of traffic.
Assignment sticks. Once a user is assigned, they keep the same variant on every later visit, so nobody sees the price change between sessions.
Call your baseline Control. The results view compares everything against it, and names like Test 1 / Test 2 become meaningless a month later.
A variant may point at the same funnel as the control. That's exactly what you do for content tests — see Test content inside one funnel.

Step 3 — Choose whether experiments may intersect

Allow experiments intersection decides whether a user can be in this experiment and other experiments at the same time.

Setting	What happens
Off (default)	The classic A/B test. A user takes part in one experiment on that funnel and sees one variant of it.
On	The user can be assigned to this experiment on top of other intersection experiments. Each assignment is stored on the user as a property named `exp_` plus the experiment's ID — `exp_42` for experiment 42 — holding the variant name: `Control`, `Variant A`, and so on.

Turn it on when you want to vary pieces of content inside a single funnel, and use those exp_* properties in conditional logic instead of routing people to a separate quiz.

Keep it off when you're comparing two genuinely different funnels and want the cleanest possible read.

Overlapping tests blur the result. If two intersection experiments change the same screen for the same people, you can't tell which change moved the metric. Vary different things, or run them one after the other. When tests do overlap, the results view can exclude users who were in more than one experiment at the same time — see Read the results.

Step 4 — Narrow the audience with filters

By default an experiment runs for everyone who opens the distribution point. Click Add Filter to restrict it.

Filter	Use it to
Country	Run only for visitors in chosen countries
Language	Run only for a specific browser language
Device	Target mobile or desktop
User agent	Match specific browsers
IP address	Include or exclude specific addresses — handy for keeping your own team out of the data
UTM parameters	Run only for traffic from a given source, medium or campaign

Add as many filters as you need — a user has to match all of them to enter the experiment. Users who don't match simply carry on through the funnel as usual and never appear in the results.

Examples

Filter Country = United States to test a new price screen on US traffic only.
Filter UTM source to a single ad account so a test doesn't touch your organic traffic.
Filter by Country with a single variant to route a region to a dedicated paywall — a supported way to serve country-specific prices from one campaign link.

Step 5 — Start it and follow the status

A new experiment is saved as Draft and isn't serving anything yet. Start it from the experiments list, or open it and set the status to Active.

Status	What it means
Draft	Saved, not running. Nothing is assigned yet and everything is still editable.
Active	Running. New users are being assigned and results are collected.
Pause	Temporarily halted — no new users are assigned, everyone already in keeps their variant. Use it during a release or an incident, then switch back to Active.
Stop	Stopped for new users, but the experiment stays in the main list and results keep updating. Use it when you want to freeze traffic and keep reading the numbers.
Success	You've decided this test won. No new users are assigned.
Fail	The hypothesis didn't hold. No new users are assigned.
Archive	Stopped and moved out of the default list, via Stop and move to archive. Find archived tests by filtering the list by status.

How they move:

Draft → Active starts assignment. Activating sets the start date if it's empty, and clears an end date that's already in the past.
Active → Pause / Stop / Success / Fail all stop new assignment; the difference is what you're telling your team. Success, Fail, Stop and Archive set the end date if it isn't set yet.
Anything → Archive takes it out of the working list once you're done.
You can't go back to Draft. Once an experiment has been activated, that state is gone for good — so review the setup before you start it.

What locks when the experiment starts

Once it leaves Draft, these can no longer change:

Project
Type — Quiz or Paywall
Run on — the distribution point
The quiz or paywall behind each variant

Still editable: the name, start and end dates, filters, and Allow experiments intersection.

Need a different setup after you started? Stop the current experiment and create a new one. Swapping the thing you're measuring halfway through mixes two populations into one number and the result won't mean anything.

How users get assigned

A user opens the quiz or paywall named in Run on.
web2wave checks the experiments running on it.
Filters are applied. A user who doesn't match every filter of an experiment is skipped for it.
The user is assigned: to one variant of one classic experiment, and to every intersection experiment they match.
The assigned variant is what they see, and it stays theirs on later visits.

On click vs. go to next screen — the mistake we see most often

The split happens when a user opens the quiz or paywall set in Run on. It does not happen when a button is clicked.

So if a button in your funnel links straight to one specific paywall address, everyone who clicks it lands on that one paywall and the experiment never gets to choose a variant. The same is true for an answer option wired to jump to a specific screen instead of continuing through the flow.

Let users move on the normal way — the next-step navigation of the quiz, and the paywall selected in the quiz settings — and point Run on at that step. Then every variant gets its share.

Quick check: an hour after you start, the results should show users in every variant. Zero users in one variant almost always means the traffic isn't passing through the distribution point.

Two more things that surprise people:

A user is recognised across visits, which is why they keep their variant. If a quiz has cookie creation disabled, visitors are harder to recognise, so treat its numbers with care.
Users assigned before a change stay where they were. Editing shares or filters affects who is assigned from that point on, not the people already in the test.

Test content inside one funnel

This is the intersection mode in practice: instead of building a second quiz, you keep one quiz and let a few properties differ per group.

Goal: test two versions of a headline — "Lose weight in 4 weeks" against "Get fit in just 21 days".

Create the experiment with Type = Quiz and Run on = your quiz.
Add two variants that both point to that same quiz — Control 50%, Variant A 50%. Routing is deliberately doing nothing here; the difference comes from the content.
Turn on Allow experiments intersection and start the experiment.
Note the experiment's ID. Users assigned to it get a property named exp_ plus that ID — for experiment 42, exp_42.
Open the quiz in the editor, select the screen and the headline block, and open conditional logic for the text property.
Add an override rule: when exp_42 equals Variant A, use Get fit in just 21 days. The text you typed into the block stays as the default, so Control users see "Lose weight in 4 weeks".

The value field suggests your actual variant names once you pick an exp_* property, so you don't have to remember the exact spelling. You can use the same condition anywhere conditional logic is available — text, images, styles, screen visibility — and a user can carry several exp_* properties at once, one per intersection experiment they're in.

Because both variants point at the same quiz, the whole test lives in those override rules. If you forget to add them, both groups see identical screens and the results come back flat.

Full reference for rules, operators and more examples: Conditional logic for fields and screens.

Read the results

Open the experiment and switch to its results. Numbers are collected as regular snapshots, so you see both the current standing and the trend since the start.

What's measured, per variant

Volume — users assigned, quiz starts, paywall views, checkouts started, subscriptions.
Conversion rates between those steps — open to quiz start, to registration, to checkout, to subscription, and view-to-buy.
Revenue — average revenue per user and per paying user.

How to tell a winner from noise

Compare each variant against Control, both as an absolute difference and as a relative lift.
The results include a significance value and a confidence interval per metric. A wide interval that crosses zero means "we don't know yet", not "no difference".
Decide on your primary metric before you look. A test that wins on one of a dozen metrics has usually just found noise.
Let it run long enough to cover a full weekly cycle and to clear a few hundred conversions per variant. Checking the numbers daily is fine; calling the result on day one is not.

When tests overlap

If intersection experiments were running at the same time, you can exclude users who took part in more than one of them and read the comparison on the remaining, cleaner population. Expect the numbers to move — the excluded users were being influenced by several changes at once.

Take the result out of the cabinet

Export Results gives you the per-variant metrics as a spreadsheet, and you can narrow the export to a date range, a traffic source or a country before you download it.
You can also export the participants — every user in the test and the variant they were given — for one variant or for all of them.
The experiment name and the assigned variant travel with your event data, so you can slice performance in your own tools: see webhook formats and export events and user properties.

Then close it out

Mark the experiment Success or Fail so your team can see what was decided, roll the winner out to all traffic, and archive the test.

Common questions

One variant has no users at all.
Traffic isn't reaching the distribution point — check the on-click note above — or a filter is excluding everyone. Confirm that Run on really is the step your users hit.

The split doesn't look like 50/50.
Assignment is random per user, so small numbers wobble; the gap narrows as volume grows. A persistent gap usually means shares were edited mid-run, or the variants have very different drop-off before the metric you're looking at.

Can I run two experiments on the same funnel?
Yes, if they're intersection experiments — that's what the setting is for. Two classic experiments on the same funnel will compete for the same users, so run them one after the other instead.

Can I change the paywall a variant points at while the test runs?
No — that's locked once the experiment is active, and for good reason: it would silently change what your numbers mean. Start a new experiment.

Users say they see a different version than a colleague.
That's the test working. To review a specific variant yourself, open that quiz or paywall directly instead of going through the distribution point.

Conditional logic for fields and screens — the rules engine behind content tests, including exp_* properties.
Experiments video walkthrough — the same flow, recorded.
Analytics and events — where the funnel metrics behind your results come from.
Experiments API — list experiments, read assignments and pull result snapshots from your own tools.