Managing Metrics

You create a metric once and reuse it across as many experiments as you need. Each metric lives in one of two places: scoped to a single project, or shared org-wide across every project in your organization. This page covers how to create a metric, choose where it lives, edit and archive it, delete it, and reuse it across experiments and projects.

1. Click New metric to create a metric from scratch.
2. Each row shows a metric's type, its definition, and how many experiments and flag rules use it.
3. The kind chips narrow the list. They add up, so you can show clicks and purchases together. Pick All kinds to clear them and see everything again.

Creating a metric

Choosing how a metric is analysed (the measure). Click, Pageview, and Custom describe what is being tracked. How it's analysed, as a conversion rate, a per-visitor value, a percentile, a rate, or a composite, is picked separately, in the experiment builder's Metrics step. The same metric can be analysed with a different measure in each experiment, with no re-instrumenting needed.

Editing an existing metric

To edit a metric, find it in the Metrics list and click on it, or click the edit icon. The same panel opens with the current values filled in. Make your changes and click Save.

Renaming a metric renames it everywhere, including in experiments that already use it, so one metric reads as one name across the whole app. The new name reaches your site with the next datafile publish, which happens automatically as part of the save.

Attaching the same metric and measure to an experiment again reuses the tracking you already have, even if you give it a different name at the time, so the same event is never counted twice under two names.

Direction: which way is a win

Some metrics are better when they go down. If A vs B says "bounce rate: -20%", is that good news or bad? Direction is how you tell it.

You set direction in two places, and they work together:

• On the metric itself (Metrics page → the metric → Direction). This is the metric's default: the way it's normally read. Bounce rate is lower-is-better wherever it's used, so set it once here and every experiment inherits it.
• On an experiment (experiment builder → Metrics step → configure a measure → Direction for this experiment). This overrides the default for that one experiment. It starts from the metric's own setting, so you only touch it when this particular test reads the metric differently from usual.

Once direction is set, results always read the same way: a positive number is always good. A bounce rate falling 20% shows as a +20% improvement, coloured green, on the results page and in the experiments list. It never shows as a red "-20%" that looks like a loss.

Changing scope: promote and demote

The same edit panel is where you change a metric's scope.

• Promote to org-wide: switch the scope from This project to Org-wide. The metric becomes usable in every project in the organization.
• Demote to a project: switch an org-wide metric back to a single project. This is blocked while experiments or flag rules in other projects still use the metric. A vs B lists exactly which ones so you can detach them first, then demote.

Archiving and deleting a metric

Four references block an archive or delete outright, and there is no override:

• An active primary. An experiment that is running, paused, or scheduled and uses this metric as its primary metric. Give it a different primary metric first, or stop it. The dialog shows the block before you confirm when it can, and the error names the experiments when it cannot.
• A sealed analysis plan. If any experiment's sealed plan references the metric (as primary, secondary, guardrail, or through a ratio or composite), the action is refused and the error names the blocking experiments. Amend each plan first through its experiment's plan card. This block exists because unarchiving would not re-attach the detached usage, so the pre-registered plan would be silently gutted.
• A bandit reward metric. If the metric is the reward metric for one or more bandits, the action is refused and the error names the bandit keys. Point those bandits at a different reward metric first.
• A composite parent (bindings only). A metric binding that is still a component of a composite metric cannot be deleted until the composite stops referencing it.

To archive or delete a metric, open it from the Metrics list, or use its ⋯ menu, and choose Archive or Delete. If the metric is in use, a confirmation dialog lists how many experiments and flag rules reference it, plus which other projects use it if it's org-wide. Read that list. Continuing detaches the metric from every experiment and flag rule named there.

When any of those experiments is running right now, the dialog asks you to type the metric's name before it lets you continue. That applies to archiving as well as deleting, because unarchiving does not re-attach what the archive detached.

Archiving is the safer choice when a metric is retired. The metric record itself is kept, so you can find it again and unarchive it later. Its detached experiments are not automatically re-attached when you do: you'd need to re-add the metric to any experiment that should keep using it.

Deleting removes the metric record entirely, and cannot be undone. Because deleting also detaches the metric from every experiment first, a completed experiment's results page stops showing that metric too: the attachment that displayed it there is gone along with the metric.

If you want a metric to stop being used going forward, but keep every past experiment's results exactly as they are today, don't delete or archive it. Just stop attaching it to new experiments.

For an org-wide metric, the confirmation dialog counts references across every project and names the other projects that use it, so you see the full effect before you confirm, not just the usage in the project you happen to be looking at.

Reusing metrics across experiments and projects

Reuse is the whole point. You create a "Purchase Completed" metric once, and every experiment can use it, with the same CSS selector, the same URL pattern, the same custom event key, everywhere. A project-scoped metric is reused across experiments in its home project. An org-wide metric is reused across experiments in every project.

When you create or edit an experiment in the experiment builder, the Metrics step shows a searchable list of every metric usable in that project: both metrics homed there and any org-wide metrics. Org-wide entries carry a small Org-wide badge so you can tell them apart.

Attach a metric to an experiment with one of three roles:

• Primary: the one metric the experiment is actually judged on. Every experiment has exactly one.
• Secondary: tracked for context alongside the primary metric, but never the deciding factor.
• Guardrail: a safety check that must not get meaningfully worse. A guardrail breach blocks a Ship verdict, even when the primary metric looks good.

Keeping metrics organized

As your project grows, the metrics list can become long. A few conventions that help keep things tidy:

• Use descriptive names: include the element type and context: Pricing Page CTA Click, Signup Form Submit, Checkout Confirmation Pageview.
• Avoid duplicates: before creating a new metric, search the list to see if one already exists for the same action. Two metrics tracking the same button with slightly different selectors leads to inconsistent data across experiments.
• Delete stale metrics: metrics that are no longer attached to any experiment and have not been used in months can be safely deleted to keep the list clean.