What Are Metrics?

A metric is the rule A vs B uses to decide which variation of your experiment won. Without one, you just have two versions of a page and a feeling about which is better. With one, you get a real number for each.

Why you need one

Say you test two checkout button colours. 4,000 visitors see blue, and 612 of them buy something. 4,000 visitors see green, and 580 buy something. Which button won?

You can't answer that from the raw counts alone. A metric turns "612 out of 4,000 bought something" into a conversion rate (15.3%), turns "580 out of 4,000" into another (14.5%), and then tells you whether that 0.8-point gap is a real difference or just noise. That's the job a metric does: it's the analysis layer that says how to count, and A vs B does the maths on top of it to call a winner.

Events come first

Every metric points at an event. If the event you want to analyse doesn't exist yet, create it on the Tracking events page first, then come back here to build the metric on top of it.

Primary vs secondary metrics

Every experiment has exactly one primary metric. This is the single measurement that decides which variation wins. When A vs B calculates a winning probability and declares a winner, it only looks at the primary metric.

You can also add secondary metrics to an experiment. These give you extra context, but they never decide the winner. Say your primary metric is "purchases." Your secondary metrics might be "add to cart clicks" and "product page views." They show you what else changed, without affecting who wins.

When a metric can mislead you

Picking the wrong metric, or the wrong type of metric, gets you a confident-looking answer to the wrong question. Watch for two traps:

  • A metric that's easy to measure isn't always the one that matters. If you're testing a checkout button, clicks on the button are easy to count, but they don't prove anyone bought anything. Someone can click and still abandon at the payment step. Pick the metric that matches your actual goal (a completed purchase), even if it's harder to track than the easy proxy (a click).
  • A brand-new metric isn't always the right move. Before you create one, check whether your organization already has one that does the job. A metric's name and event key must be unique across your whole organization, not just one project, so a duplicate often already exists somewhere else.

The three metric types

A vs B offers three types of metric, each suited to a different kind of conversion.

Click metrics

Click metrics fire when a visitor clicks a specific element on your page. You identify the element with a CSS selector: the same syntax you use in stylesheets. This is the simplest way to measure button clicks, link clicks, or any other interactive element.

Example use cases: clicking a "Sign up" button, clicking an "Add to cart" link, clicking a navigation item.

Pageview metrics

Pageview metrics fire when a visitor reaches a URL that matches a pattern you define. You choose the match style: starts with a given address, an exact match, path-only, contains a substring anywhere, a wildcard pattern, or a regular expression. This is useful when a conversion means reaching a specific page, like a thank-you page after checkout or a confirmation page after signing up.

Example use cases: visiting /thank-you, reaching /order-confirmation, landing on any page under /account/.

Custom events

Custom events fire when you call avsb.track.event() from your own JavaScript code. You decide exactly when a conversion happens by placing this call at the right moment: inside a form's submit handler, after an API response succeeds, or when a visitor reaches a certain scroll depth. Custom events can also carry a revenue amount, which unlocks Revenue Impact calculations in your results.

Example use cases: form submissions, purchases, video completions, subscription upgrades.

Where metrics live: your organization

A metric is an organization-level definition. It isn't tied to one experiment, and it isn't locked inside one project. You create it once and reuse it, so you never rebuild the same "Purchase completed" metric project by project.

Every metric has a scope that controls where you can use it:

  • This project: the default. The metric has a home project, and you can only attach it to experiments in that project. Anyone who can create experiments can make one.
  • Org-wide: the metric has no home project, and you can attach it to experiments in any project across your organization. Only an organization admin can create, edit, archive, or delete an org-wide metric.

You can change the scope at any time by editing the metric. Making a project metric org-wide ("promote") shares it with every project. Pulling an org-wide metric back down to one project ("demote") is blocked while experiments or flag rules in other projects still use it: detach those first, then demote.

Names and event keys are unique across the whole org

A metric's name, and its event key for a custom event, must be unique across your entire organization, not just one project. So a "name already in use" message can point at a metric that lives in a different project you may not be looking at. Search before you create.

Edit a metric, for example changing its CSS selector, and that change takes effect immediately across every experiment using it: be careful editing a metric attached to a running experiment. Archiving a metric stops it firing in every project at once. And if you delete a project, any of its metrics that other projects were still using survive as org-wide metrics rather than being lost.

One conversion per visitor

Each metric records at most one conversion per visitor. If a visitor clicks a button three times, A vs B counts that as one conversion, not three. This stops power users from skewing your results, and keeps the conversion rate calculation meaningful.

Live 30-day preview in the picker

When you pick a measure inside the experiment builder, the picker shows a small Last 30 days card next to the per-measure configuration. It calls the project's historical event store, and waits 300ms after you stop tweaking inputs. Then it shows what the metric would have been across the rolling 30-day window: a percentage for conversion rates, a count for total events, or a per-visitor value or percentile snapshot otherwise. If nothing fired in the last 30 days, the card says so directly, so a zero result is never mistaken for a broken read. Composite and rate measures don't get a single-measure preview: the picker shows a short explainer instead.

Explore the metric types

Was this helpful?