A metric moving after a launch doesn't prove the launch caused it โ an A/B test is what actually isolates the one variable you're testing from everything else happening at the same time.
1Same Time, Different Groups Is the Whole Point
An A/B test's value comes specifically from running both variants at the same time, under the same external conditions, with only the tested change differing between the groups โ that's what lets you attribute an observed difference to the change itself rather than to something else happening in the world at the same time.
2A Dramatic-Looking Result Can Still Be Noise
With a small enough sample, random variation alone can produce a result that looks meaningful. Statistical significance is the specific check for whether an observed difference is unlikely to be pure chance โ skipping it risks confidently acting on noise.
3Step-by-Step Breakdown
Comparing metrics before and after a change confounds the change with everything else happening at the same time โ a holiday, a competitor's outage, pure random variation. An A/B test avoids this by splitting real users into groups at the same time, so only the thing you're testing differs between them.
A result from 20 users in each group can look dramatic and still be pure noise. Statistical significance is the check for whether an observed difference is large and consistent enough to be unlikely by chance alone โ without it, you risk confidently 'learning' from what's actually random variation.
Why does a before/after comparison risk misleading conclusions that a proper A/B test avoids?
- โBefore/after comparisons are always more accurate, not less
- โAnything else that changed between the before and after periods (seasonality, other launches, random variation) gets confounded with the change being tested, while a simultaneous A/B split isolates just that one difference
- โA/B tests don't require real user data
- โThere's no meaningful difference between the two approaches
Formal A/B testing with significance calculations is worth the overhead for meaningful, hard-to-reverse decisions with enough traffic to reach a real sample size in reasonable time. For a tiny team with low traffic or a trivially reversible decision, a simpler before/after check plus judgment is often the more practical, proportionate choice.
When is a full, rigorous A/B test worth its overhead, versus a simpler comparison?
- โAlways โ every product decision should go through formal A/B testing
- โFor meaningful, hard-to-reverse decisions where there's enough real traffic to reach statistical significance in a reasonable time frame
- โNever โ A/B testing is only useful for large companies
- โOnly for pricing changes specifically
Level Up ๐
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Make Sure Both A/B Variants Meet the Same Accessibility Bar
It's easy to accidentally test a variant that's less accessible than the control (e.g. a new component without full keyboard support) โ verify both variants independently meet baseline accessibility requirements before launching the test, not just the winning variant afterward.
// Before launching the test: verify BOTH variant A and variant B
// pass the same accessibility checklist independentlySEO Implications
- 1
Target 'A/B testing for engineers' and 'when to A/B test vs just ship' as distinct from statistician-oriented A/B testing theory
The target reader wants the practical judgment call of when rigor is worth it, not a deep statistics course.
Best Practices
Decide the Sample Size and Duration Before Starting the Test
Commit to a minimum sample size or test duration before launching, based on your traffic volume โ checking results early and stopping the moment they look favorable ('peeking') is a common way small samples produce misleadingly confident, noisy conclusions.
Frequent Bugs
Ending an A/B test as soon as one variant appears to be winning, without reaching the pre-determined sample size or duration.
Commit to a stopping point (sample size or duration) before the test starts, and hold to it even if an early trend looks promising โ early trends in small samples are frequently reversed as more data comes in.
Real-World Examples
The Reversal at Full Sample Size
A team peeked at an A/B test after 2 days and saw variant B up 15% โ they nearly shipped it early. Waiting for the pre-committed full sample size revealed the gap had narrowed to a statistically insignificant 2%, well within normal noise.
// Day 2 (n=40/group): B leads by 15% -- tempting, but not significant yet
// Day 14 (n=2000/group, pre-committed): B leads by 2%, not significant