A/B test sample-size calculator
How many visitors per variant do you need for a meaningful result?
Current conversion rate in percent, 0.1 to 99, for example 3 for 3 out of 100 visitors.
Current conversion rate of your control
Smallest improvement the test should detect, in percent of the current rate, 1 to 500. Example: 20 means from 3% to 3.6%.
Relative improvement you want to detect (e.g. +20% = 2.0% → 2.4%)
How certain a result must be not to be chance. 0.05, i.e. 95% certainty, is common; smaller values need more visitors.
How likely the test is to find a real effect. 80% is common; higher values need more visitors.
Unchecked, the calculator works two-tailed, for improvement and decline. One-tailed needs fewer visitors but misses a decline.
Per variant
21,109
visitors
Total
42,218
visitors (control + variant)
Expected conversion
2.00% → 2.40%
control → variant
Days to significance
| Daily visitors | Days |
|---|---|
| 100 | 423 days |
| 500 | 85 days |
| 1,000 | 43 days |
| 5,000 | 9 days |
| 10,000 | 5 days |
Two-proportion z-test, computed entirely in your browser (no data leaves your device).
How this tool works
How many visitors per variant do you need for an A/B test result that is not just noise? This calculator uses the two-proportion z-test (standard for conversion-rate tests) and computes from baseline conversion, minimum detectable effect (MDE), significance level (α) and power (1−β) the required sample size per variant. Plus days-to-significance for 5 typical traffic volumes. Computed entirely in your browser — no data leaves your device.
Typical use cases
- Before test start: set realistic runtime expectation (3 days instead of "until next standup")
- Stakeholder pitch: show that a claim after 100 visitors is statistically worthless
- With low baseline (1-3% conversion) realistically assess whether a test is worthwhile at all
- Reverse-power calculation: with a fixed sample, read which MDE is detectable
- Plan multi-variant tests: sample per variant × number of variants = total traffic need
- Estimate sequential-testing correction (peeking problem) via conservative MDE choice
Frequently asked questions
What does MDE (Minimum Detectable Effect) mean?
The smallest relative difference you still want to detect. MDE=20 at baseline=2% means: you want to detect if the variant reaches at least 2.4%. Smaller MDE = larger sample needed. Rule of thumb: 10-20% is realistic, anything below 5% needs huge data.
Why 80% power and 95% significance as defaults?
α=0.05 → 5% chance of false positive. Power=0.8 → 20% chance of false negative. This combo is industry standard since Jacob Cohen 1988 — higher power costs disproportionately more sample.
One-tailed or two-tailed?
Two-tailed (default): test if variant is significantly different (better OR worse). One-tailed: only if variant is better — ~20% less sample, but you must NOT switch to one-tailed post-hoc. That is p-hacking.
My test needs 50 days — now what?
Three options: raise MDE (detect 25% instead of 10% — dramatically less sample), direct more traffic (90/10 split), or accept that only bold changes are testable with your baseline + traffic.
What about peeking / sequential testing?
If you check daily and stop at first significant result, real false-positive rate is much higher than α=5%. Sample-size calc assumes you check ONCE at the endpoint. Fix: stick to fixed runtime, or use sequential frameworks (CUPED, Bayesian) with peeking correction.
Related tools
Continuous monitoring vs. one-shot?
XICTRAQ monitors uptime, SSL, security headers, GDPR and performance 24/7. Free plan, no credit card.