A/B Test Sample Size Calculator

How this tool computes its result

Runs a two-proportion sample-size formula for A/B tests. It reads a baseline conversion rate and a relative minimum detectable lift, computes the expected rate as baseline × (1 + lift/100), then pools the two rates to get n = [zα·√(2p̄(1-p̄)) + zβ·√(p1(1-p1)+p2(1-p2))]² / (p2-p1)². zα comes from a lookup table keyed by confidence level (80/90/95/99%) and test sidedness (two-sided vs one-sided use different tables), zβ comes from a separate power lookup (80/85/90/95%). If daily traffic and a split ratio are provided, it estimates test duration by dividing the required sample per variant by each variant's share of daily traffic and taking the longer of the two.

Worked example

With the tool's own defaults — baseline 2.5%, minimum detectable lift 15%, 95% confidence, 80% power, two-sided — the expected rate becomes 2.5% × 1.15 = 2.875%. Pooling the two rates and plugging zα = 1.96 and zβ = 0.842 into the formula gives roughly 29,200 required visitors per variant (about 58,400 total). Adding a daily traffic figure of 1,500 visitors with a 50/50 split produces an estimated ~39-day test, since each variant only receives 750 visitors/day.

When not to use this tool

This is a two-proportion (binary conversion) calculator only — it has no notion of continuous metrics like revenue per user or average order value, no correction for sequential testing or "peeking," and assumes flat, constant daily traffic with no seasonality baked into the duration estimate.

Common mistakes

• - Entering the lift as an absolute percentage-point change instead of a relative one — a "15% lift" on a 2.5% baseline means the expected rate is 2.875%, not 17.5%; the tool explicitly computes it as baseline × (1 + lift/100).
• - Typing the baseline rate as a decimal (e.g. "0.025") instead of a percentage integer (e.g. "2.5") — the field is divided by 100 internally, so a decimal entry silently produces a near-zero rate and an inflated sample size rather than an error.
• - Ignoring the note that an uneven traffic split (60/40, 70/30) extends the required runtime, since duration is driven by whichever variant receives the smaller share of daily traffic.

Related tools