Bell Statistics

What is A/B testing?

A/B testing is a controlled experiment: users are randomly assigned to two or more versions of an experience, and the difference in outcomes between them estimates the effect of the change. Randomisation is what makes the comparison causal rather than merely observational.

Also called
split testing, online controlled experiment, randomised controlled trial
Allon Korem

Written by Allon Korem

Chief Executive Officer

Last updated

In plain English

An A/B test splits incoming users at random between a control experience and one or more variants, then compares an outcome metric across the groups. The mechanism that makes this worth doing is randomization, and it is doing more work than it appears to. Because assignment is random, the two groups are on average identical in every respect — including the ones you never measured and the ones you have never thought of — so any systematic difference in outcomes has to have come from the change. This is why an A/B test yields a causal estimate while a before-and-after comparison does not.

Everything else in the discipline is scaffolding around that one idea. You fix a primary metric before starting, so the result cannot be chosen after the fact. You compute a sample size from the smallest lift worth shipping, so the test has the statistical power to answer the question. You run it for whole weeks, because weekday and weekend users differ. And you check that traffic actually split the way you asked, because a sample ratio mismatch means the randomisation you are relying on did not happen.

The failures worth knowing are mostly failures of the assumption rather than of the arithmetic. Interference: if users in one arm affect users in the other — a marketplace where a variant consumes shared inventory, a social product where content crosses arms — the groups are no longer independent and the estimate is biased. Novelty and primacy: a visible change gets a temporary reaction that fades, so a two-week test on a redesign measures curiosity as much as value. And dilution, where the analysis includes users who never reached the surface you changed, which shrinks a real effect towards nothing.

There are also questions an A/B test simply cannot answer, and reaching for one anyway is the more expensive mistake. Anything you cannot randomise at the user level — a brand campaign, a pricing change with fairness constraints, a TV flight — needs a different design, usually a geo experiment that randomises regions instead. Anything whose effect accrues over months exceeds the horizon of a test you will actually wait for. And the cross-channel question — what did all our marketing do together — is what marketing mix modelling exists for.

Used well, the value is less about individual wins than about the rate of learning. A programme that runs properly powered tests, records the negatives as carefully as the positives, and resists the urge to slice a flat result until something appears will accumulate a genuine picture of what moves its metrics. A programme that runs underpowered tests and reports whichever segment came out green will accumulate confident nonsense, and will do it faster.

The formula

The estimator is a difference in averages; the machinery is in the standard error and the sample size. These are the two-proportion forms, which cover most product experiments.

The estimate
Δ̂ = p̂_variant − p̂_control

Unbiased for the average treatment effect, but only because assignment was random. Nothing in the arithmetic checks that it was.

Standard error of the difference
SE = √( p̂₁(1−p̂₁)/n₁ + p̂₂(1−p̂₂)/n₂ )

The 95% interval is Δ̂ ± 1.96·SE. Report that rather than the p-value alone.

Sample size per arm
n = ( z₁₋α/₂ + z₁₋β )² · ( p₁(1−p₁) + p₂(1−p₂) ) / (p₁ − p₂)²

The squared effect in the denominator is why halving the detectable lift costs four times the traffic — see the A/B test sample size calculator.

Sample ratio check
χ² = Σ (observed − expected)² / expected, df = k − 1

Run this on every experiment. A p below about 0.001 means the split is broken and the result should not be read.

Worked example

You want to test a redesigned product page. Conversion is 3.2%, and the smallest lift worth the engineering cost is 5% relative — 3.2% to 3.36%. You have 45,000 sessions a day to split between two arms and want the conventional 5% two-sided level at 80% power.

Baseline conversion
3.2%
Minimum detectable effect
+5% relative (3.20% → 3.36%)
Significance level
0.05, two-sided
Power
0.80
Sample needed per arm
≈ 185,000
Daily sessions per arm
22,500

About 8.2 days of traffic per arm, rounded up to two full weeks so that every day of the week appears twice in each group.

The rounding is not padding. Conversion differs systematically between weekdays and weekends, and a test that runs 8 days contains an unequal mix — which does not bias the comparison, since both arms see the same days, but does inflate the variance and can make a genuine effect harder to detect. Two whole weeks also gives novelty effects room to decay, so you can compare the first week's lift against the second and see whether the effect is stable. If it is not, the number to trust is the later one. And before reading anything, check the split: 22,500 against 22,500 should be within a few hundred, and a gap larger than chance allows means the randomisation is broken and the estimate is not causal.

Common misconceptions

We can just compare the week before and the week after the change.
That comparison confounds the change with everything else that differed between the two weeks — seasonality, campaigns, a competitor's promotion, the weather. Randomising users into concurrent groups is what removes all of it at once, including the confounders you never thought to list. A before-and-after is a selection bias waiting to happen.
The test is significant, so we should ship it.
Significance says the effect is probably not zero. Whether it is large enough to justify the build, the complexity and the maintenance is a separate question the confidence interval answers. Decide the smallest worthwhile effect before the test runs, then read the interval against it rather than against zero.
A/B testing works for anything you can change.
It works for anything you can randomise at the unit of analysis without the arms interfering. Brand advertising, pricing, marketplace supply and network-effect features all break one of those conditions, and a user-level test on them produces a confident, biased number. Those need geo experiments, switchback designs, or a model that states its assumptions.
If we run the test longer, the result will become clearer.
Only if you decided the duration in advance. Watching a test and stopping when it turns significant inflates the false-positive rate from 5% to roughly 25% over a fortnight of daily checks. Running longer than planned is fine; deciding to run longer *because* the result has not gone your way is not.

Frequently asked questions

How long should an A/B test run?
Long enough to reach the sample size you calculated in advance, and then rounded up to a whole number of weeks so both arms contain the same mix of weekdays and weekends. Two weeks is a common floor, because it also gives novelty effects room to fade and lets you compare the first week against the second. Stopping early because the result turned significant is the single most common way a programme inflates its own error rate.
What is the difference between A/B testing and multivariate testing?
An A/B test compares whole experiences; a multivariate test varies several elements independently and estimates each one's contribution plus their interactions. Multivariate answers a richer question and costs far more traffic, since the number of combinations grows multiplicatively — four elements with two options each is sixteen arms. For most teams the honest answer is that they do not have the traffic, and a sequence of A/B tests learns more per session.
Can I test more than two variants at once?
Yes, and it is often efficient because the arms share one control. The costs are that each arm needs its own sample, so four arms need roughly twice the total traffic of two, and that three comparisons against one control inflate the false-positive rate unless you use a procedure built for it, such as Dunnett's. Keep the arm count to what your traffic supports rather than what the tool allows.
Can I run A/B tests with low traffic?
You can, but you must be honest about what is detectable. At a few thousand sessions a week only large effects are visible, so the useful move is to test bold changes rather than button colours, and to say out loud that a flat result rules out nothing smaller than, say, 20%. Variance reduction and choosing a metric that moves earlier in the funnel both help. Running an underpowered test and recording the null as a finding does not.

Related terms

  • Guardrail metric

    A metric that can veto a launch but never justify one, and why that asymmetry is the whole point.

  • Minimum detectable effect

    The smallest lift you designed to catch — a business decision that gets outsourced to statistics.

  • Randomization

    The one mechanism that makes a comparison causal — and the four ways it silently fails.

  • Sample ratio mismatch

    The split is wrong, so the randomisation is broken — the cheapest and most decisive check you can run.

  • Sample size

    Four inputs, one number, fixed before the test runs — and the square law that makes small effects expensive.

  • Statistical power

    The probability your test finds a real effect — and why most tests that report nothing were never able to.

Calculate it

  • A/B test sample size

    Size a two-proportion experiment before you launch, then read the lift and its interval once it lands.

  • Two-sample t-test

    Compare the average of two independent groups — plan the sample size, then test the result.

  • One-proportion z-test

    Test one observed rate against a fixed target — an SLA, a benchmark, a contractual floor.

  • Chi-square test

    Test a contingency table of counts for association — any number of rows and columns.

Knowing the term is the easy part

Designing the test is the easy half. Choosing the metric, handling users who appear in both arms and deciding what to do when the result lands in the awkward middle is the work — see A/B Testing

References