Case study · Experimentation · Monte Carlo

Your A/B test “winner” may be noise: what 100,000 simulated tests show

Checking an experiment every day and stopping at the first significant result feels efficient. We simulated 100,000 experiments and read each one under six stopping plans to measure what it costs, then tested the fix.

ExperimentationA/B testingMonte Carlo simulationSequential testingStatistics
Independent project on public dataCode and data publishedUpdated 1 November 2026
24.6%
of no-difference tests declare a winner when checked daily, five times the 5% promised
5.0%
with a sequential boundary, even when looking every day
−2pts
power cost of the fix: 59% vs 61% for a real 10% lift
3.2days
sooner, on average, to stop a test with a real 10% lift

01The question

A p-value threshold of 0.05 promises that, if a change does nothing, you will wrongly call it a winner only 5% of the time. That promise holds only if you look once, at the sample size you planned.

In practice dashboards update live, stakeholders ask for early reads, and tests get stopped the moment they hit significance. We wanted to put a number on what that habit costs, and show a fix that still lets teams look whenever they like.

02The approach

  1. Simulate tests where nothing changed

    A/A tests: both versions convert at exactly 5%, 1,000 visitors each per day for 20 days. Any “winner” is a false one.

  2. Simulate tests where something did

    A/B tests with a real 10% relative lift (5.0% to 5.5%), to measure power and how quickly each plan calls a true winner.

  3. Compare six stopping plans

    Look once at day 20, weekly, every two days, daily, and daily with two sequential boundaries. The same 50,000 A/A and 50,000 A/B tests are read under every plan.

  4. Calibrate the fix by simulation

    We tuned Pocock (the same bar at every look) and O'Brien-Fleming (strict early, relaxed late) boundaries so exactly 5% of A/A tests ever cross them in 20 daily looks.

03What we found

Bar chart of false-winner rates: once at day 20 4.9%, weekly 10.4%, every 2 days 19.2%, daily 24.6%, daily with O'Brien-Fleming boundary 5.0%, daily with Pocock boundary 5.0%.
Figure 1. Looking weekly doubles the false-winner rate; looking daily multiplies it by five. Both sequential boundaries bring it back to 5% while still allowing a look every day.
Line chart of three simulated A/A tests against three stopping boundaries. One test crosses z = 1.96 on day 3 and fades by day 20; it stays below the O'Brien-Fleming and Pocock boundaries.
Figure 2. Why it happens. Random noise wanders above the 1.96 line early in a test, when samples are small, then fades. A sequential boundary sets a higher bar early on, when noise is loudest.
PlanFalse winnersPower (real 10% lift)Average days to stop
Look once at day 204.9%61%20.0
Look daily, stop at p < 0.0524.6%74%11.0
Daily with O'Brien-Fleming boundary5.0%59%16.8
Daily with Pocock boundary5.0%46%15.8

Daily peeking looks more “powerful” only because it calls more of everything, including five times as many false winners. The O'Brien-Fleming boundary keeps the error rate honest, gives up just two points of power, and stops tests with a real effect 3.2 days sooner on average.

You can look at your experiments every day. You just need a stopping rule designed for it.

04What it means for your team

Fewer phantom wins

A team running 40 tests a year in which nothing really works would ship about 10 false winners with daily peeking, and about 2 with a sequential boundary.

Faster real decisions

Real winners are called days earlier on average, so traffic moves on to the next idea sooner.

Results people trust

When product, marketing and finance agree on the stopping rule up front, nobody argues about early reads.

Audit the past

Re-analysing completed tests with the right boundary shows which past "wins" were probably noise.

05Limits

Simplifications

  • Traffic and conversion are constant from day to day. Real tests have weekday cycles and novelty effects, which make early looks even less reliable.
  • One metric and two arms. Several metrics or variants raise the false-winner rate further unless corrected.
  • The exact numbers depend on traffic, baseline rate and lift; the code lets you rerun them for yours.

06How we would do this for you

Week 1

Audit

Review how tests are designed, monitored and stopped, and re-analyse a sample of past results.

Week 2

Design

Sample sizes, a sequential stopping rule calibrated to your traffic, and guardrail metrics.

Week 3

Embed

A test-readout template or dashboard that applies the rule automatically, and a session with your team.

07Reproduce it

The simulation runs in about three seconds and takes your own traffic, baseline and lift as parameters.

Python 3NumPySciPypandasmatplotlib

This is an independent project built on public data to show how we work. It is not client work, and no client data was used. Figures are reproducible from the published code.

Running experiments and not sure you can trust the winners?

We audit testing programmes, set sample sizes and stopping rules, and re-analyse past tests to find the winners that were noise.

More case studies

Machine learning · NLP
1%of today's AI reviews caught by a detector trained on 2019's fakes

Can a model spot an AI-written review?

A detector that catches 86% of AI reviews while wrongly flagging 1% of genuine ones, the blind spot that makes older detectors useless, and a live demo you can try.

Machine learningNLPTrust and safetyModel evaluationExplainable AI
Read the case study
Simulation · Financial modelling
1.4–30+years for buying to beat renting, depending on place and prices

Is renting really “dead money”? A decision model tested against 21 years of history

A month-by-month simulation of a six-figure decision, a 2005–2026 backtest, sensitivity to rates and prices, and a calculator anyone can use.

SimulationFinancial modellingBacktestingSensitivity analysisPython and R
Read the case study