Ratio metrics

A ratio metric is a metric built by dividing one number by another, rather than counting a single event. A vs B measures it across every visitor in a variation (one specific version being tested: the control, or a challenger). The classic example is average order value: total revenue earned by the variation, divided by the number of orders placed in it.

Ratio metrics measure outcomes a simple yes/no conversion can't capture: dollar amounts, item counts, retention rates, and any other "one thing over another" quantity. In the experiment builder, this is the Rate measure. Pick it on a metric binding to compare two existing project metrics as a ratio.

What is it

You pick the Rate measure inside the experiment builder's Metrics step, not when you first create a metric. On a binding, you pick two things:

• The numerator: an existing project metric, typically a Custom event carrying a value, or a click/pageview metric.
• The denominator: another existing project metric, typically a count of unique visitors.

Both metrics must already exist on the project. A vs B computes each variation's ratio at result time as sum(numerator) / count(denominator). It reports the lift between variations with a delta-method confidence interval. That's the statistically correct way to estimate variance when both the numerator and the denominator are random variables.

When to use

Use a ratio metric whenever the quantity you care about is naturally one thing divided by another, rather than a yes/no conversion:

• Average order value: total revenue ÷ orders placed. The classic ratio metric.

• 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 (one you're not trying to improve, just don't want to get worse) for product changes.

• Refund rate: refunds issued ÷ orders placed. A guardrail metric when testing checkout or payment changes.

Revenue and order count both vary per visitor, so the delta method gives a correct interval on any of these.

Example

Say you're testing a cross-sell module on the product page. You want to know whether it deepens carts: do the visitors who buy end up spending more per order?

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 an Orders count metric that fires once per completed order.
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 Orders. Then mark the binding as the experiment's primary metric (the one number the test is ultimately judged on).

After the experiment has data, the results page shows:

Control:   $42.10 / order  (n = 4,180 orders)Variant:   $45.80 / order  (n = 4,265 orders)Lift:      +8.8%  (95% CI: +3.2% to +14.6%)Badge:     Ratio (delta method)

How A vs B computes it

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

Var(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). A vs B's Bayesian engines build their result from this same delta-method variance. Technically, that result is a normal-approximation posterior (the engine's updated belief after seeing your data).

The sequential engine (built so you can check results anytime without inflating false positives) uses the same variance too. Its confidence interval is wider than a fixed-horizon one, on purpose. That's the cost of staying valid no matter when you look.

Visitors with a zero denominator (for example, an average-order-value ratio for a visitor who placed no orders) are dropped from the variation. The drop count is surfaced in the results diagnostic, so you can sanity-check the exclusion.

Sharpening a result without more traffic

Ratio metrics support two techniques for this:

• CUPED (a technique that uses a visitor's pre-experiment behaviour to reduce noise in the result) shows a real effect with less traffic.

• Winsorization (capping the most extreme numerator values at a chosen percentile) stops one outlier order from swinging the result.

If both are turned on, winsorization runs first, then CUPED. A vs B then computes the delta-method variance on the result. This order is the industry default. It matches how Eppo and Statsig apply the same transforms.

Sample experiment

A realistic worked example: a product-page cross-sell experiment with about 18,000 visitors per arm, and a conversion rate steady at 3.4%. The ratio metric "Average order value" moves from $42.10 to $45.80, an 8.8% lift with a 95% delta-method CI of +3.2% to +14.6%. That's statistically significant (unlikely to be due to chance alone) at the standard 0.05 threshold.

Because conversion stayed flat, the AOV row tells you the win came from deeper carts, not from more buyers. The same experiment's Revenue per visitor renders separately, in the Revenue panel. It's a continuous money metric with its own mean-per-visitor CI: see Reading your results.

FAQ

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

Total value sums a metric's value field across the variation. Value per visitor divides that sum by the variation's unique visitor count for the same metric.

Rate is more general. Its numerator and denominator are two independent project metrics. So it can express ratios like items per order or refunds per checkout, where neither side is simply one metric's value field and visitor count.

Use Total value when you want a sum. Use Value per visitor for a per-visitor average of a single metric. Use Rate when the numerator and denominator come from different metrics.

Note that Value per visitor is analysed as a continuous per-visitor test: a mean and confidence interval over every exposed visitor, zeros included. It doesn't use the delta method. See Statistical Methodology.

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 would extend 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, or custom events with revenue. The aggregation happens server-side, at result time.

Related