Experiments in PostHog Web

The PostHog web app is where experiments are designed, launched, and read. Open Experiments to see every draft, running, and completed test in your project, then open one to configure its variants and metrics, watch exposures accumulate, and see whether the result is significant.

Because the experiment sits next to the rest of your PostHog data, the results view isn't just a number. You can jump from a variant to the session replays of the people who saw it, or break a metric down by any property you already capture.

Before you start

1. Set up Experiments – install a PostHog SDK so your app can serve variants.
2. Open the web app – no install needed, just sign in to PostHog.

What you can do here

• Create an experiment – define your hypothesis, variants, and metrics, and let PostHog create the backing feature flag.
• Test and launch – verify your implementation with variant overrides before you expose real users.
• Analyze results – read significance, credible or confidence intervals, and per-variant metric breakdowns.
• Manage the lifecycle – pause, resume, end, ship a winning variant, or archive a finished test.
• Run no-code web experiments – change copy, styles, or images on your site from the toolbar, with no deploy.
• Analyze with PostHog AI – create experiments, summarize results, and compare behavior across variants in natural language. It's an interaction mode inside the web app, not a separate surface.

Self-driving reports

A scout audits your running experiments for problems with the measurement itself – a skewed split, a stalled exposure stream, a flag edited mid-run – and files each confirmed problem as a report in the Self-driving inbox. To get these reports, set up Self-driving.

What the experiments scout watches

The scout audits the measurement machinery, not the outcome. Which variant is winning is your decision, and it never comments on that. What it checks is whether a running experiment is still measuring what its configuration promised:

• Sample ratio mismatch – variants aren't receiving the traffic split you configured. PostHog runs a chi-squared test over exposures, and the scout only calls it at healthy volume, so a wobble across a few hundred exposures won't be reported as one.
• Multiple-variant contamination – users who saw more than one variant, usually from identity fragmentation, a session reset, cross-device use, or a mid-run rebucket. These users are typically dropped from results, and on an uneven split dropping them biases the answer.
• Exposure stalls – a running experiment that stops accruing exposures after a healthy baseline, or one that never recorded a single exposure. Common causes are the flag call being removed from code, an SDK method that doesn't record exposure, or a custom exposure event that isn't firing.
• Mid-run flag edits – changes to the backing flag after the experiment started, like a redistributed split, a tightened release condition, or a renamed variant. All of them rebucket users and mix pre-edit and post-edit data.
• Broken metric machinery – a primary metric whose query fails or returns nothing in any arm, so the experiment is burning calendar time measuring nothing.
• Lifecycle drift – zombie experiments running long past their useful life, experiments with a clear sustained answer still collecting data, and ended experiments whose flags still serve random variants.

Reports here are yours to confirm

The experiments scout only writes reports. It doesn't open pull requests.

That's deliberate. A validity threat is an investigation rather than a one-line change – the right fix might be a flag correction, an instrumentation change, a decision to relaunch, or nothing at all – so the scout files the evidence and routes it to a suggested reviewer instead of drafting code.

What you can do with a report

• Read the report – the experiment, its feature flag key, and the numbers behind the finding: observed versus expected split, exposure counts, days dormant, and when the problem started.
• Confirm what's actually wrong – decide the fix, whether that's a flag change, an SDK correction, or relaunching the test on clean data.
• Hand it to an agent – when the fix does turn out to be a code change, start an implementation task from the report, then review the pull request it drafts.

Related

• Learn how users are assigned and counted in exposures and traffic allocation.
• Understand how the numbers are produced in Bayesian and frequentist statistics.
• Do the same work from your editor over MCP.