Quick answer
Guardrail metrics are measures a team commits to protect while it optimises a primary metric. A change that lifts the primary metric but pushes a guardrail past an agreed limit, such as slower pages or more refunds, is not shipped until the guardrail is fixed.
What are guardrail metrics?
Guardrail metrics are the numbers you agree not to make worse while you work on your main goal. If a new checkout lifts conversion but makes pages slower or drives up refunds, a guardrail catches it.
They come from online experimentation, where every test has one primary metric and a few guardrails decided in advance. The idea applies to any change: a redesign, a pricing update, a new onboarding flow.
Primary, guardrail and diagnostic metrics
| Type | Purpose | Example |
|---|---|---|
| Primary (success) | What the change is meant to improve | Checkout conversion rate |
| Guardrail | What must not get worse | Page load time, error rate, refund rate |
| Diagnostic | Explains why the primary moved | Step-by-step funnel drop-off |
The primary metric often ties back to your north star metric. Guardrails protect the business and the user experience around it.
Common guardrail metrics
- Performance: page load time, Core Web Vitals, app crash rate.
- Reliability: JavaScript error rate, failed payments.
- Revenue quality: refund rate, average order value, cancellations.
- User trust: unsubscribe rate, complaints, support tickets per order.
- Engagement health: rage clicks, bounce rate on key pages.
A sample experiment readout
A team tests a new checkout page. Limits were agreed before the test (sample numbers):
| Metric | Role | Control | Variant | Change | Limit | Result |
|---|---|---|---|---|---|---|
| Checkout conversion | Primary | 3.00% | 3.12% | +4.0% | — | Improved |
| p75 page load | Guardrail | 2.1 s | 2.6 s | +23.8% | ≤ +10% | Fail |
| JS error rate | Guardrail | 0.40% | 0.42% | +5.0% | ≤ +20% | Pass |
| Refund rate (30 days) | Guardrail | 2.0% | 2.1% | +5.0% | ≤ +10% | Pass |
Conversion went up, but page load broke its limit. The decision is to fix the performance problem and retest, not to ship and hope.
How to choose guardrails
- Ask what could go wrong. List the harms the change could cause: slower pages, more errors, lower order value, angry users.
- Keep it to three to five. With many guardrails, some will cross a limit by chance in almost every test.
- Set limits before you start. Write down how much worse each guardrail may get. Deciding after seeing results invites bias.
- Prefer metrics that react quickly. Error rate shows harm in hours; churn may take months.
- Reuse them. The same guardrails across tests make results comparable.
Watching guardrails after a release in TapCub
TapCub does not run A/B tests, but you can watch guardrails after any release. Open All-platform analytics › Operations › Monitors and create a monitor for each guardrail. Built-in measures include error rate, errors, bounce rate and average duration; you can also pick a saved metric. Use a fixed threshold for a hard limit, period change to catch a jump against the previous period, frustration for rage clicks per 1,000 pageviews, or anomaly detection once you have about 30 days of history. A dry run shows how often the rule would have fired over the last 30 days. Mark the release date with an annotation so the change is visible on charts.
See also: What is canary testing? Canary releases explained with an example.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Product Analyst
Focuses on event analysis, conversion funnels, and retention, using clear metric definitions and structured analysis to explain product performance.