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.
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 baseline conversion rate is 4% and you want to detect a 10% relative lift (so the variant would need to reach about 4.4%) at 95% significance and 80% power. Plugging those into a standard two-proportion sample-size formula, you need about 39,475 visitors per variant, or roughly 79,000 in total for a two-arm A/B test.
Now watch what the inverse-square relationship does. Halve the MDE to a 5% relative lift on the same 4% baseline and the requirement jumps to roughly 158,000 per variant. Same page, same confidence, same power, four times the traffic, all because you asked to see a smaller effect. You can run these numbers yourself in the A/B test calculator, which uses exactly this method.
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. Once you have an MDE, our guide on how long to run an A/B test turns the sample size into a finish date, and the guide on the peeking problem explains why you should wait for that date rather than stopping early.
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.