Metrics in the dashboard

The Metrics page is where you turn raw events or warehouse facts into measurable numbers — and where you read experiment results.

​

The list

Each metric:

• Name — human-readable
• Source — a Traffical-native event or a warehouse fact
• Aggregation — conversion_rate, sum, count
• Used by — policies attached as goal or health metrics
• Current value — the latest computed aggregate across all traffic

The same metric can be used in many policies. Defining revenue_per_user once and attaching it to every checkout-related experiment is the common pattern.

​

Creating a metric

Pick a source first: Then pick an aggregation: For sum, you also pick the value column (e.g. order_total). For count, no column is needed.

​

Filters and dimensions

A metric can be filtered (e.g. “only completed orders”) or grouped by a dimension (e.g. by country). For event-sourced metrics, the available filters and dimensions come from properties marked dimension: true on the event’s property schema. For fact-sourced metrics, available filters are columns returned by the fact SQL.

​

Metric detail

The detail page shows:

• Current value with trend over time
• Top breakdowns by configured dimensions
• All policies using this metric as a goal or health gate

Use the time-range selector to look at any window.

​

Attaching to policies

Open a policy → Metrics → Add metric. A policy can have:

• One goal metric. What the experiment is optimizing for (drives adaptive allocation shifts, surfaces as the primary result).
• Any number of guardrail metrics. Side effects you want to watch.
• Rollout health metrics. For policies with a rollout, metrics that gate ramp progression.

For adaptive policies, only the goal metric drives the engine. Guardrails are surfaced in the UI but don’t influence allocations.

​

Reading per-policy results

On a policy’s detail page, each metric shows per-allocation:

• The point estimate (e.g. conversion rate = 0.087)
• A confidence interval
• A significance indicator (when the experiment has enough data to make a confident call)

Significance is computed using cluster-robust standard errors when the metric is measured at a different level than the randomization (e.g. randomized by company, measured per user). The dashboard handles this automatically based on entity definitions.

​

Best practices

• Pick metrics carefully. A metric that’s noisy at your traffic level will say “no significant effect” forever. Use a more direct outcome where possible.
• Don’t add too many guardrails. Three is plenty. Twenty is paralyzing.
• Match metric to randomization level. If your project is keyed on companyId, prefer company-level metrics for goals. User-level metrics are still valid with cluster-robust analysis but slow to converge.

​

Next steps