Experiments
Contents
Experiments let you test a change against a control and find out whether it actually worked. You define variants, pick the metrics you care about, and PostHog randomizes your users, tracks their exposures, and runs the statistics – Bayesian or frequentist – so you get a real answer instead of a hunch.
Because experiments run on the same events and feature flags you already have in PostHog, you don't need new instrumentation to measure a result. Any event, data warehouse table, or funnel you've already built can become an experiment metric, and every variant is linked to the session replays of the people who saw it.
Where you can use it
You design, launch, and analyze experiments in the PostHog web app. The other surfaces let you create and manage them from your editor or your own systems, and review the validity problems Self-driving finds in the ones you're running.
PostHog Web
Create experiments, launch them, and read results with significance, replays, and exposures in view.
Run an experiment →PostHog MCP
Create experiments, check results, and manage their lifecycle from any MCP client or AI editor.
Drive experiments →API
Manage experiments, holdouts, and shared metrics programmatically from your own systems.
Use the API →PostHog Desktop Beta
Review the validity problems a Self-driving scout finds in your running experiments.
Review findings →Where its data comes from
Experiments don't collect anything new. They read the feature flag that assigns each user to a variant, the events those users go on to send, and – if you want – tables you've already loaded into the data warehouse.
Feature flags
Every experiment is backed by a flag that randomizes users into variants and records their exposure.
Understand exposures →Events
Any event you already capture can become a funnel, mean, or ratio metric for an experiment.
Define metrics →Data warehouse
Measure revenue, subscriptions, or anything else living in a warehouse table you've synced.
Use warehouse tables →How experiments works with Self-driving
Your experiments are a signal source for Self-driving. A scout audits the measurement rather than the result: it reads the exposure stream of every running experiment against the split, status, and flag state you configured, and files each confirmed contradiction as a report in your inbox.
This loop stops at your review on purpose. A validity threat is an investigation rather than a one-line change, so the scout files the evidence and a suggested reviewer instead of drafting a pull request. Once you've confirmed what's wrong and the fix is a code change, you can promote the report into the usual implementation path, where an agent drafts the PR and you review and merge it.
Which variant is winning stays your call – the scout never comments on results. See PostHog Desktop for everything it watches, and the Self-driving docs for the full picture.