Minimum detectable effect (MDE), explained
A methodology guide for CRO teams. Published 7 July 2026.
Minimum detectable effect is the number that decides how big your test has to be. Get it right and you plan a test you can actually finish. Get it wrong and you either wait forever for traffic you do not have, or you run a test too small to see the effect you were hoping for. It is worth ten minutes to understand properly.
MDE is the smallest real lift your A/B test is designed to catch. You choose it before launch based on the smallest improvement worth shipping, and it directly sets the sample size you need. A larger MDE means fewer visitors; a smaller MDE means disproportionately more, because required traffic scales with roughly the inverse square of the effect.
What MDE means
The minimum detectable effect is the smallest true difference between control and variant that your test is powered to detect reliably. Set an MDE of a 10% relative lift and you are saying: if the variant genuinely improves conversions by 10% or more, I want a good chance of catching it. If the real effect is smaller than your MDE, the test will usually come back inconclusive even though a difference exists, simply because you did not collect enough data to separate that smaller signal from the noise.
The key thing to internalise: MDE is an input you choose before launch, not an output the test reports. You are declaring the sensitivity you want, and that declaration sets the sample size.
How MDE drives sample size
Sample size depends on four things: your baseline conversion rate, your MDE, your significance level (conventionally 95%, meaning a 5% false-positive rate), and your statistical power (conventionally 80%, meaning an 80% chance of detecting a true effect of MDE size). Fix three of them and the fourth follows from the maths.
The relationship that surprises people is between MDE and sample size. Required visitors scale with roughly the inverse square of the MDE. In plain terms, halving the effect you want to detect roughly quadruples the traffic you need. Wanting to catch a 5% lift instead of a 10% lift does not cost you twice the visitors, it costs you about four times as many. Chasing tiny effects gets expensive fast.
Baseline rate matters too. Lower baseline conversion rates need more traffic for the same relative MDE, because rare events carry more relative noise. That is why a 2% checkout page needs more visitors than a 20% newsletter signup to detect the same percentage lift.
A worked example
Say your checkout page converts at 3.2% and you want to detect a 15% relative lift, meaning the variant would need to reach 3.68% (an absolute increase of 0.48 percentage points). You are using the standard settings: 95% confidence (alpha = 0.05, so Zalpha/2 = 1.96) and 80% power (beta = 0.20, so Zbeta = 0.84).
The two proportion z test sample size formula per variant is:
n = (Zalpha/2 + Zbeta)2 × (p1(1 − p1) + p2(1 − p2)) / (p2 − p1)2
Substituting the numbers:
- p1 = 0.032 (control), p2 = 0.0368 (variant)
- p1(1 − p1) = 0.032 × 0.968 = 0.030976
- p2(1 − p2) = 0.0368 × 0.9632 = 0.035446
- (Zalpha/2 + Zbeta)2 = (1.96 + 0.84)2 = 7.84
- (p2 − p1)2 = (0.0048)2 = 0.00002304
n = 7.84 × (0.030976 + 0.035446) / 0.00002304 = 7.84 × 0.066422 / 0.00002304 ≈ 22,610 visitors per variant, or about 45,220 total for a two arm test.
Now see what happens when you change the MDE. On the same 3.2% baseline, here is the sample size per variant for three different relative lifts:
| Relative MDE | Variant rate | Absolute difference | Visitors per variant | Total (two arm) |
|---|---|---|---|---|
| 5% | 3.36% | 0.16 pp | ~203,212 | ~406,424 |
| 15% | 3.68% | 0.48 pp | ~22,610 | ~45,220 |
| 20% | 3.84% | 0.64 pp | ~12,724 | ~25,448 |
Dropping from a 15% MDE to a 5% MDE multiplies the traffic requirement by roughly nine. Raising it to 20% cuts the requirement almost in half. The inverse square relationship is dramatic at low baseline rates. You can run these numbers yourself in the sample size card of the A/B test calculator.
Common baseline and MDE combinations
The table below shows approximate sample sizes per variant at 95% confidence and 80% power for baseline rates and relative MDEs you are likely to encounter in practice.
| Baseline rate | 5% relative MDE | 10% relative MDE | 15% relative MDE | 20% relative MDE |
|---|---|---|---|---|
| 1% | ~3,177,000 | ~794,000 | ~353,000 | ~199,000 |
| 3% | ~1,035,000 | ~259,000 | ~115,000 | ~65,000 |
| 5% | ~608,000 | ~152,000 | ~68,000 | ~38,000 |
| 10% | ~289,000 | ~72,000 | ~32,000 | ~18,000 |
| 20% | ~128,000 | ~32,000 | ~14,000 | ~8,000 |
Two patterns stand out. First, lower baselines need far more traffic for the same relative MDE. Second, a 5% relative MDE consistently requires roughly 16 times the traffic of a 20% relative MDE, which is exactly the inverse square law in action (0.20/0.05 = 4, and 42 = 16).
How to choose a sensible MDE
The honest way to pick an MDE is to work backwards from business value, not to reach for a round number. Ask: what is the smallest lift that would actually be worth shipping this change, given the effort to build it and the risk of maintaining it? If a 3% lift on this page would meaningfully move revenue and is realistic for the change you made, that is your MDE. If only a 15% lift would justify the work, do not power the test for 3%, because you would be buying sensitivity you do not need and paying for it in weeks of traffic.
Anchor the number to two realities at once: what lift is plausible for a change of this kind, and what lift is worth acting on. A good MDE sits where those overlap.
The over-optimistic MDE trap
The most common mistake is setting the MDE too high to make the sample size look achievable. You want the test to finish this month, so you tell the calculator you are hunting a 20% lift, it quotes a comfortable sample size, and you launch feeling efficient. The problem is that most real winning variants deliver low single-digit or low double-digit lifts, not 20%. Your test is now underpowered for the effects you are actually likely to get. It will frequently come back inconclusive on changes that genuinely helped, and you will wrongly conclude they did nothing.
An underpowered test is worse than no test, because it launders a guess into a confident-looking null result. If the honest MDE demands more traffic than you have, the right response is to test higher up the funnel, test bolder changes with larger expected effects, or accept a longer run, not to pretend the effect is bigger than it is.
The short version
MDE is the smallest true effect your test can reliably catch, and you choose it before you launch. Smaller MDE means disproportionately more traffic, because sample size scales with the inverse square of the effect. Tie the number to the lift that would actually be worth shipping, and resist the temptation to inflate it just to shrink the sample.
Further reading
- A/B test sample size calculator to compute the exact visitor count for your baseline and MDE.
- How long to run an A/B test turns the sample size into a calendar finish date.
- The peeking problem explains why you should wait for that date rather than stopping early.
- Statistics engines documentation covers how ABTestly computes results across its frequentist, sequential, and Bayesian methods.
FAQ
What is the minimum detectable effect?
The MDE is the smallest true difference between your control and variant that your test is powered to detect reliably. If the real effect is smaller than your MDE, the test will usually fail to reach significance even though a difference exists. It is a design choice you make before launching, not a result the test hands back.
Why does a smaller MDE need so much more traffic?
Sample size scales with roughly the inverse square of the MDE. Halving the effect you want to detect roughly quadruples the visitors you need per variant, because separating a smaller signal from the same noise takes far more data.
How do I choose a good MDE?
Tie it to the smallest lift that would actually be worth shipping, given the effort and risk of the change. Do not pick an optimistic number just to shrink the sample size, because that produces an underpowered test that cannot detect the realistic effects you are likely to get.
How ABTestly computes results is public: see the results methodology docs and the SRM docs.