One of the useful PostHog experiment updates from May 21, 2026 is the new organization-level default minimum detectable effect, or MDE.
For the exact release note, you can check PostHog’s official changelog.
This update is small, but it fixes a real workflow problem. Before this, if your team wanted to use a stricter MDE for every experiment, you had to remember to re-enter it each time you created a new experiment. That sounds minor until you are running multiple tests, moving quickly, or working with several people who do not all use the same statistical defaults.
Now you can set the default MDE once in PostHog’s Experiments Settings. Every new experiment will inherit that value automatically, while still allowing you to override it for a specific experiment when needed.
What Changed in PostHog Experiments?
PostHog now supports a default minimum detectable effect at the organization level.
In practical terms, this means:
- You set the default MDE once in Experiments Settings.
- New experiments automatically inherit that MDE.
- Individual experiments can still override the default.
- Teams no longer need to manually re-enter the same stricter threshold every time.
What Is Minimum Detectable Effect?
Minimum detectable effect is the smallest effect size you want your experiment to be able to detect with statistical significance.
If you set a lower MDE, you are asking the experiment to detect smaller changes. That usually requires more traffic, more conversions, and a longer runtime.
If you set a higher MDE, the experiment can usually reach a decision faster, but it may miss smaller improvements that still matter commercially.
That trade-off is why this setting matters. MDE is not just a statistical field. It shapes how sensitive your experiment is, how long it needs to run, and what kind of business impact you are actually trying to detect.
Why This Update Matters for CRO Teams
For CRO and experimentation work, consistency is often more important than convenience.
If one experiment is created with a loose MDE and the next one uses a stricter threshold, your experiment system becomes harder to compare over time. The team may think it is running a consistent testing program, but the decision standards are quietly changing from test to test.
This update helps reduce that risk.
With a default MDE, teams can align on a baseline sensitivity for experiments once, then let PostHog apply it automatically. That makes experiment setup faster and makes the statistical expectations more consistent across the organization.
It is especially useful for teams that:
- Run experiments regularly in PostHog.
- Want stricter experiment defaults than PostHog’s starting value.
- Have multiple people creating experiments.
- Need consistent testing standards across product, marketing, and CRO work.
- Want to reduce setup mistakes before launching tests.
How to Set the Default MDE in PostHog
To configure the default MDE:
- Open PostHog.
- Go to
Experiments. - Open the
Settingstab. - Find
Default minimum detectable effect. - Set the MDE value using the slider or percentage input.
- Create a new experiment and confirm that it inherits the default value.

This setting applies to new experiments in the environment. It does not mean every experiment must use the same MDE forever. You can still override the value per experiment when the test requires a different sensitivity.
How to Choose a Good Default MDE
There is no universal best MDE. The right default depends on your traffic, conversion volume, experiment cadence, and the size of effect that is worth acting on.
As a practical rule:
- Use a lower MDE when small improvements are commercially meaningful and you have enough traffic to wait for them.
- Use a higher MDE when you only want to act on larger changes or your traffic is too limited for small-effect testing.
- Avoid setting an unrealistically low MDE just because it looks more precise. It can make experiments run too long and delay decisions.
For many teams, the default MDE should reflect the smallest lift they would actually care about. If a 2% relative lift would not change a decision, do not build your default around detecting 2%.
How to Verify the Setting Works
After setting the organization-level default MDE, create a test experiment and check the experiment configuration before launch.
Success looks like this:
- The new experiment automatically shows the default MDE you configured.
- The value can still be changed inside the experiment if needed.
- Your team no longer needs to manually re-enter the same threshold for every new experiment.
If the value does not appear as expected, check that you are in the correct PostHog environment and that you changed the setting under the Experiments Settings page, not only inside one experiment.
Common Mistakes to Avoid
The biggest mistake is treating the default MDE as a universal law.
It is a starting point, not a replacement for experiment judgment. Some tests need a stricter MDE because small effects matter. Other tests can use a larger MDE because only a major behavior change would justify rollout.
Other mistakes to watch for:
- Setting the MDE too low for your traffic volume.
- Using the same MDE for high-volume and low-volume funnels without thinking through runtime.
- Forgetting that lower MDE values require more data and longer test duration.
- Changing the default without telling the team.
- Comparing old and new experiments without checking whether their MDE settings were different.
When to Override the Default MDE
Override the default when the business question changes.
For example, a checkout experiment on a high-value purchase flow might justify detecting a smaller effect because even a small lift can produce meaningful revenue. A homepage layout test with noisy behavior and limited conversion volume may need a larger MDE to stay practical.
The default should make normal experiment setup cleaner. It should not stop you from setting the right threshold for a specific test.
Why I Like This Update
This is not a flashy feature, but it improves the experiment system.
Good CRO work depends on repeatable standards. When defaults are hidden inside each experiment setup, small inconsistencies creep in. One person uses one threshold, another person uses another, and later the team tries to compare results as if the experiment conditions were the same.
PostHog’s default MDE setting reduces that friction. It turns a repeated manual decision into an organization-level standard, while keeping enough flexibility for individual experiments.
That is exactly the kind of update that makes experimentation easier to operationalize.
Frequently asked questions
Where do I set the default MDE in PostHog?
Go to Experiments > Settings > Default minimum detectable effect and set the percentage value there.
Does the default MDE apply to existing experiments?
Based on the update wording, the default applies to new experiments. Existing experiments should be checked individually before assuming their MDE has changed.
Can I override the default MDE for one experiment?
Yes. The update states that new experiments inherit the organization-level default, but the value can still be overridden per experiment.
Should I always use the lowest possible MDE?
No. A lower MDE usually requires more data and longer runtime. Use an MDE that matches the smallest effect you would actually act on.
Why does MDE matter for CRO?
MDE affects how sensitive your experiment is. It influences whether your team can detect smaller lifts and how long the test may need to run before reaching a useful conclusion.
What happens if my MDE is too high?
You may miss smaller improvements that still matter to the business. A high MDE can make testing faster, but less sensitive.
What happens if my MDE is too low?
Your experiment may need much more traffic and time. If your funnel volume is limited, the test may become impractical.
Is the default MDE set at the project or organization level?
The update describes it as an organization-level default. Check the relevant PostHog organization and environment before relying on the setting.
Who should decide the default MDE?
The default should usually be agreed by whoever owns experimentation quality: CRO, product analytics, data, or growth. It should reflect both statistical discipline and business decision thresholds.


