Quick definition: Probability of superiority is the probability, under a stated model, that one defined treatment effect exceeds a comparator or threshold. In Bayesian A/B testing it commonly means P(θtreatment − θcontrol > 0 | data).
What is Probability of superiority?
Probability of superiority is the probability, under a stated model, that one defined treatment effect exceeds a comparator or threshold. In Bayesian A/B testing it commonly means P(θtreatment − θcontrol > 0 | data). In experimentation, its value comes from matching the method to a predeclared estimand: the population, randomization unit, outcome, comparison, and time window that the product decision actually concerns. A named test cannot substitute for that design work.
Reliable analysis begins before the statistic is calculated. Define eligible users, stabilize treatment assignment, log exposure, preserve a consistent denominator, and wait for outcomes to mature. Check allocation and data quality; a sample ratio mismatch can undermine a randomized comparison even when a calculation is numerically correct.
How Probability of superiority works
Draw values from the joint posterior of the treatment and control parameters, calculate the difference for every draw, and count the share greater than zero. To evaluate commercial relevance, calculate P(Δ > δ), where δ is a predeclared minimum practical effect. The complement can quantify risk of harm, such as P(Δ < −δh). For a two-arm beta-binomial model, simulation is simple; regression or hierarchical models produce draws that also adjust for the modeled structure.
The calculation should be reproducible from a frozen analysis dataset. Retain assignment, eligibility, exposure, outcome timestamps, exclusions, and aggregation rules. Do not change the analysis population after a result appears attractive. For a clear discussion of planned outcomes and decisions, see how to write an A/B-test hypothesis.
Assumptions and boundaries
The probability is only meaningful for a clearly defined estimand, population, outcome window, prior, and likelihood. It assumes valid treatment assignment and appropriate handling of repeated users, clusters, missing outcomes, and skewed values. A high probability of a positive effect can arise from a minuscule effect in a very large sample, so superiority over zero is not enough for a product decision.
Assumptions should be examined against the experiment architecture rather than treated as a ceremonial checklist. Inspect group sizes, missingness, outcome distributions, dependence, and implementation changes. If the needed assumptions fail, revise the design or use a method that represents the data-generating process; do not simply choose the test that produces the smallest p-value.
Probability of superiority in A/B testing
Teams can use it in a planned rule such as: launch when P(Δ > 0.2 percentage points) is at least 95%, P(Δ < −0.1 points) is below 2%, and latency and refund guardrails pass. This frames evidence in action-relevant units. The rule needs to be fixed before monitoring, simulated under benefit and harm, and applied to mature data; moving the threshold after a favorable dashboard is not disciplined Bayesian decision-making.
Keep one primary outcome and distinguish secondary outcomes, diagnostics, and guardrails. A favorable result on one metric does not erase increased latency, refunds, or support burden. The discipline behind that separation is explained in primary and guardrail metrics. When several variants, metrics, or segments are compared, plan the comparison family and control the resulting false-positive risk as described in multiple comparisons in A/B testing.
Worked example and workflow
A signup test observes 400 conversions from 8,000 control users and 432 from 8,000 treatment users. Posterior simulation with Beta(1,1) priors may estimate P(Δ > 0) at 96%, but P(Δ > 0.25 percentage points) at 75%. The first number supports a belief that a positive effect is likely; the second shows evidence is weaker for the team’s commercially useful threshold. A measured rollout or more data may be preferable to declaring a winner.
A practical workflow is: write the estimand and decision threshold; select the analysis unit and method; calculate sample size and a fixed or sequential monitoring plan; validate assignment and tracking; freeze the dataset after the outcome window; estimate effect size and uncertainty; review guardrails; and document the action and limits. Planning duration from baseline rate, variability, minimum detectable effect, power, and traffic prevents a test from being treated as an open-ended search; see how to calculate sample size.
Interpreting the result
State the exact comparison: “Under the documented model, the posterior probability that treatment improves seven-day conversion by more than 0.25 percentage points is 75%.” Do not translate it into a guarantee that treatment is better for each user or at full scale. Pair it with a credible interval and expected cost of an erroneous action.
Use interval estimates to communicate what remains plausible. A confidence interval that crosses zero does not prove no effect, and a narrow interval around a tiny gain may not pay for rollout. Frequentist interval interpretation is often misunderstood; confidence intervals in A/B testing explains the distinction between procedure coverage and a probability statement about one fixed parameter.
Common pitfalls
- Using superiority over zero as a proxy for practical significance.
- Omitting the comparator, direction, or outcome window.
- Ignoring simultaneous variants and selected segments.
- Treating posterior monitoring as permission for arbitrary stopping.
- Overlooking asymmetric downside in the launch decision.
Also avoid peeking and stopping because a transient result is favorable. Fixed-horizon thresholds assume the stopping rule that was planned. If continuous monitoring is needed, use a validated sequential procedure with predeclared looks and boundaries. Otherwise, wait for the planned horizon and present the full analysis rather than a selected dashboard snapshot.
Decision workflow and reporting checklist
Start with the decision that the analysis will inform. State whether the team is choosing a default experience, deciding whether to invest in another iteration, or determining that the expected benefit is too uncertain to justify further traffic. Translate that action into a minimum useful effect and a maximum tolerable loss in original business units. A threshold is not a statistical convention: it should reflect expected reach, user impact, engineering cost, reversibility, and the availability of safer alternatives.
Before analysis, version the metric definition and preserve the raw ingredients needed to reproduce it. Confirm that each included unit was eligible before treatment, assigned only once according to the intended allocation, exposed as defined, and observed for the complete outcome window. Compare arm sizes and key pre-treatment diagnostics. If implementation, logging, or allocation differs by arm, report the issue and resolve it before interpreting an estimated effect. Excluding problematic records only from one arm can create a more serious bias than ordinary random noise.
After estimating the primary result, make the uncertainty visible. Present arm-level values, the absolute difference, a compatible interval or posterior distribution, and the exact decision rule. Explain how missing values, outliers, repeated measurements, clustering, and concurrent experiments were handled. Review prespecified guardrails on the same mature population, while keeping exploratory slices clearly labeled. If important conclusions depend on modeling choices, show sensitivity analyses rather than one preferred output.
Finally, separate evidence from action. A result may support a full rollout, a gradual reversible release, additional data, a redesign, or no action. Record the chosen action, assumptions, and follow-up monitoring so later teams can learn whether the experimental estimate generalized. This closes the experimentation loop without overstating what a single analysis can establish.
Frequently asked questions about Probability of superiority
Is probability of superiority a p-value?
No. A p-value is a frequentist tail probability under a null model; this is a posterior probability conditional on a Bayesian model.
Can I compare against a practical threshold?
Yes. That is often more useful than comparing only against zero.
What is a good cutoff?
It depends on expected value, reversibility, harm, and the decision policy; 95% is not universally correct.
Can it be used for revenue?
Yes, with a model or estimator suited to zeros, skew, and the user-level estimand.
Does 99% probability require a launch?
No. Guardrails, implementation costs, external validity, and absolute magnitude still matter.
Summary
Probability of superiority is useful when its estimand, mechanics, assumptions, and decision rule match the experiment. Treat the reported statistic as one part of an evidence package: absolute effect, uncertainty, data-quality checks, guardrails, practical value, and a transparent rollout policy. Sound randomization and measurement are more important than a sophisticated formula.
Sources
- NIST/SEMATECH e-Handbook of Statistical Methods
- OpenIntro Statistics
- Gelman et al., Bayesian Data Analysis