Guardrail metrics are the business or user experience metrics you protect during an A/B test. They are not the metric you are trying to improve. They are the ones you do not want to break. If a winning variant lifts conversions but drops a guardrail like page load time or revenue per session, the test is not safe to ship.
Most experiments focus on a single primary metric, like signups or revenue. The problem is that one metric never tells the full story. A change can boost the primary metric and quietly hurt something else: trial-to-paid rate, support tickets, refunds, or page speed.
Guardrail metrics catch those side effects before you roll out a change to all users. They keep your team from celebrating a win that costs the business more than it earns.
Primary metrics answer "did this change work?" Guardrail metrics answer "did it work without making something else worse?" A test is only a real win when the primary metric improves and every guardrail stays inside its safe range.
Both mean the same thing. "Guardrail metrics" is the more common spelling. Some teams write it as "guard rail metrics" with a space.
Two to four is usually right. Fewer misses real side effects. More creates false alarms, since at least one will wiggle by chance.
Revenue per visitor is a strong default. It catches both the conversion-rate side and the order-value side.
Most teams loosen the threshold for guardrails. The goal is to catch real harm, not wait for perfect certainty. A common pattern is to flag any movement of 1 to 2% with at least 80% confidence.
In Optibase you can track guardrail metrics alongside the primary metric for any test. Define them at experiment setup and they appear in the same results view as the primary.
