Ratio metrics

A ratio metric is one quantity divided by another, computed across all visitors in a variation. The canonical example is revenue-per-visitor— total revenue earned by the variation divided by the number of unique visitors who saw it. Ratio metrics let you measure outcomes that can't be modelled as a simple yes/no conversion: dollar amounts, item counts, retention rates, and any other "numerator over denominator" quantity. In the experiment builder this is surfaced as the Rate measure — pick it on a metric binding to analyse two existing project metrics as a ratio.

What is it

In A vs B, the Rate measure is picked inside the experiment builder's Metrics step — not at metric creation time. On a binding, you pick the numerator (an existing project metric — typically a Custom event carrying a value, or a click/pageview metric) and the denominator (another existing project metric, typically a count of unique visitors). Both metrics must already exist on the project. Each variation's ratio is computed at result time as sum(numerator) / count(denominator), and the lift between variations is reported with a delta-method confidence interval — the statistically-correct way to estimate variance when the numerator and denominator are both random variables.

When to use

Use a ratio metric whenever the quantity you care about is naturally expressed as a per-visitor average rather than a yes/no conversion:

• Revenue per visitor — total revenue ÷ unique visitors. The most common ratio metric and the one CRO and growth teams cite most often.
• Items per order — total items purchased ÷ orders placed. Measures cart depth, useful for upsell tests.
• Support tickets per active user — tickets opened ÷ active users. A guardrail metric for product changes.
• Refund rate — refunds issued ÷ orders placed. A guardrail when testing checkout or payment changes.

Example

Say you're testing a new pricing page that promotes a higher-tier plan. You want to know whether the new page increases revenue per visitor, not just signups.

1. Create a Revenue custom metric that fires on the purchase event and includes the purchase amount via avsb.track.event('purchase', { revenue }).
2. Create a Visitors count metric that fires once per unique visitor on the pricing page.
3. In the experiment builder's Metrics step, attach a new metric and pick the Rate measure. Set the numerator to Revenue and the denominator to Visitors, then mark the binding as the primary metric for the experiment.

After the experiment has data, the results page will show:

1Control:   $1.42 / visitor  (n = 18,420)
2Variant:   $1.58 / visitor  (n = 18,512)
3Lift:      +11.3%  (95% CI: +4.1% to +18.9%)
4Badge:     Ratio (delta method)

How A vs B computes it

A ratio of two random variables doesn't have a closed-form normal distribution, so the standard t-test gives wrong confidence intervals. A vs B uses the delta method — a first-order Taylor expansion that approximates the variance of X/Y from the variances and covariance of X and Y:

1Var(X/Y) ≈ (μ_X / μ_Y)² · [ Var(X)/μ_X² − 2·Cov(X,Y)/(μ_X·μ_Y) + Var(Y)/μ_Y² ]

This is the variance estimator every serious experimentation platform uses (Eppo, Statsig, GrowthBook, LaunchDarkly). For Bayesian engines, A vs B uses a normal-approximation posterior built from the same delta-method variance. For the sequential engine, the same variance feeds an always-valid bound that is wider than the fixed-horizon CI by design — that's the cost of peeking-safe inference.

Visitors with a zero denominator (e.g., a revenue-per-visitor ratio where the visitor saw the page but had no qualifying event) are dropped from the variant and the drop count is surfaced in the results diagnostic so you can sanity-check the exclusion.

CUPED and winsorization

Ratio metrics support both CUPED variance reduction and winsorization. Winsorization, if enabled, runs first (capping the most extreme numerator values at the chosen percentile), then CUPED applies, then the delta-method variance is computed on the resulting values. This ordering is the industry default and matches how Eppo and Statsig apply the same transforms.

Sample experiment

A realistic worked example: a pricing-page redesign experiment with ~18k visitors per arm, control AOV $42, variant AOV $48, conversion rate steady at 3.4%. The ratio metric "Revenue per visitor" moves from $1.42 to $1.58 — an 11.3% lift with a 95% delta-method CI of +4.1% to +18.9%, statistically significant at α=0.05. The Decomposition section of the results page shows that the lift was driven by AOV (visitors who converted spent more), not by conversion rate (which was flat).

FAQ

How is this different from the Total value and Value per visitor measures?

The Total valuemeasure sums a metric's value field across the variation; Value per visitor divides that sum by the unique visitor count for the same metric. The Rate measure is more general — the numerator and denominator are two independent project metrics, so you can express ratios like items per order or refunds per checkoutwhere the two sides aren't the value field and visitor count of a single metric. Use Total value when you want a sum, Value per visitor for a per-visitor average of a single metric, and Rate when the numerator and denominator come from different metrics.

Can a ratio metric reference another ratio?

No. Nested derived metrics (ratios of ratios, ratios of composites, composites of composites) are blocked at save time. The math extends to nested cases but the statistical interpretability drops sharply.

Do I need to change my snippet integration?

No, as long as both the numerator and denominator reference event types the snippet already tracks (clicks, pageviews, custom events with revenue). The aggregation is server-side at result time.

Related