Designing an A/B Test
P8.experimentation.02 · Audience: guest, it-ml, language-pro · Prerequisites: Why Randomize?
Randomization guarantees a fair comparison — but only of a test that was designed to answer something. Before a single user is split, four decisions are already made, and getting any one of them wrong quietly wastes the whole experiment: what you measure, whom you split, how long you run, and how big the test must be to notice the effect at all. This module is about making those four decisions on purpose, before the coin is flipped.
An experiment needs a single primary metric chosen before the data arrives — the one number that decides ship-or-not. Naming it in advance is not bureaucracy; it is the only defence against the human habit of hunting through a dozen metrics after the fact and celebrating whichever one happened to move.
Alongside it sit a few guardrail metrics — things that must not get worse even if the primary metric improves (page load time, error rate, unsubscribe rate). The primary metric says "did it help?"; the guardrails say "at what cost?".
ⓘ Concept: Primary metric and guardrails
Why it matters — With no pre-declared primary metric, every experiment 'succeeds', because some metric always moves by chance. Deciding the one number that matters — and the handful that must not degrade — before launch is what keeps the test an honest test rather than a fishing expedition. The pitfalls module shows exactly how fishing across many metrics manufactures fake wins.
Prefer a metric close to the value you actually want. "Clicks on the new button" is easy to move and easy to fool yourself with; "did the user complete a purchase" is harder to move and far harder to fake.
Ask the mentor about this module
Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.
🎓 Practice ladder
4 graded rungs · ~33 minFeel the sizing trade-off with your own hands: predict which effect needs the fewest users, simulate a power curve from scratch, invert it to the sample size that reaches 80% power, then reason about the duration trap a weekly cycle sets.
Rung 1 — Bigger lift, smaller sample (explorer)
Loading exercise…
Rung 2 — Simulate the power curve
Loading exercise…
Rung 3 — Find the sample size
Loading exercise…
Rung 4 — The duration trap (senior)
Loading exercise…
Try it yourself
A scratch console for this page's ideas — ungraded, nothing you run here is recorded.
Scratch console
A scratch console with the scientific stack (pandas, numpy, scikit-learn). Runs on the server — no network, resource-limited and measured.
Output appears here.
Where next?
Later in Experimentation
This module unlocks