How to Choose a North Star Metric

A north star metric is the one number a company agrees to steer by. It exists to settle arguments between teams that each have a local metric they can move, and it works when it captures the value customers get rather than the activity the company generates.

Most north star metrics fail for a boring reason. They are chosen in a workshop, written on a wall, and never wired to anything that makes a decision. This article covers how to pick one that survives contact with a roadmap, how it differs from the metric an experiment is judged on, and what to instrument so the number is real.

What a north star metric is

It is a single, customer-facing measure of delivered value, reported on a slow cadence, that the whole company can influence but no single team owns.

Every clause in that sentence is load-bearing.

Single. Two north stars are zero north stars. The point is to force a trade-off to be made explicitly rather than resolved by whoever argues hardest.

Customer-facing. It measures something a customer would recognise as value received. Revenue is the company's outcome, not the customer's, which is why revenue makes a poor north star and a necessary guardrail.

Delivered value, not activity. Sessions, clicks and logins measure that the product was touched. A north star should measure that it worked: nights booked, messages delivered, invoices paid, minutes of content actually watched.

Slow cadence. Monthly or quarterly. A number reported daily gets managed daily, and a north star that moves with a marketing push is measuring the push.

Influenceable by all, owned by none. If one team can move it alone, it is that team's KPI. If nobody can move it, it is a vanity number.

The north star is not your OEC

This is the distinction that causes the most damage in practice, because the two are often the same words used for different jobs.

The north star is a strategic metric measured over months across the whole customer base. The Overall Evaluation Criterion is the decision rule for a single experiment, measured over days on the users in that experiment. Using a north star as an experiment's primary metric is one of the reliable ways to run tests that can never conclude.

The reason is statistical, not philosophical. A north star is deliberately downstream, so a change in the product moves it a little and everything else moves it a lot. That means a small effect on a noisy metric, which needs a sample most experiments will never have. The published guide to building a metric hierarchy and choosing an OEC covers how to pick a metric that is close enough to the change to be detectable, and the note on minimum detectable effect shows what the arithmetic demands.

The relationship between them should be explicit and written down: the OEC is the short-run proxy you believe moves the north star. When that belief turns out to be wrong — a proxy improves for a year while the north star flattens — the proxy is what gets replaced.

Four tests a candidate has to pass

A candidate metric is worth adopting only if it survives all four. Most workshop favourites fail the second or the third.

One: would a customer call it value? Read the metric out loud as a sentence about a customer. "Our customers completed 40,000 more workouts" passes. "Our customers generated 40,000 more sessions" does not.

Two: can it be gamed by shipping something worse? Every metric has a cheap path. If the cheapest way to move the number is to make the product more annoying — more emails, more interstitials, more forced steps — the metric will eventually be moved that way, whatever anyone intends. Choose a metric whose cheap path is still good for the customer, and pair it with counter-metrics for the rest.

Three: does it move on a horizon anyone will wait for? A metric that responds over eighteen months cannot steer a quarterly roadmap. If the true value measure is that slow, adopt a leading indicator as the north star and keep the slow one as the annual check.

Four: can it be measured the same way twice? If the definition needs a footnote about which events count, the footnote will change silently, and a year of trend data will turn out to be a series of definitions rather than a series of measurements.

A worked example

Take a subscription product for team collaboration. The obvious candidates, and what happens to each:

The last one is narrower and less flattering than the others, which is the usual sign of a good north star. It names the unit that gets value — a team, not a login — and it sets a threshold that distinguishes a working team from a dormant one. Its cheap path, getting more people to contribute, is the product working.

Notice that this candidate is still not an experiment metric. Almost no single test can move the count of active teams enough to detect. The experiment metrics are the proxies underneath it: invitations accepted, first shared document created, second contributor active within a week.

Instrumenting it in Optimizely

The north star is measured in the warehouse or the analytics tool, not inside a single experiment. What belongs in Optimizely is the proxy chain, instrumented so that a test result can be joined to the north star later.

Two things make that join possible. Every conversion carries the identifiers the north star is grouped by, and the event names are stable enough to survive a redesign.

// The proxy event an experiment is judged on, tagged with the unit the north
// star counts. Tagging at fire time is what lets a later analysis roll these
// up to teams without re-deriving membership from a mutable profile.
window['optimizely'] = window['optimizely'] || []
window['optimizely'].push({
  type: 'event',
  eventName: 'second_contributor_active',
  tags: {
    team_id: workspace.teamId,
    contributor_count: workspace.activeContributors,
    plan: workspace.plan,
  },
})

The definition itself belongs in version control next to the code, not in a dashboard someone can edit.

{
  "northStar": {
    "name": "Weekly active collaborating teams",
    "unit": "team",
    "window": "trailing 7 days",
    "qualifies": "three or more distinct contributors with at least one edit",
    "excludes": ["internal accounts", "trial teams under 7 days old"],
    "reviewedAt": "2026-08-15"
  },
  "counterMetrics": ["notification opt-outs", "support tickets per active team"],
  "proxyEvents": ["invitation_accepted", "first_shared_doc", "second_contributor_active"]
}

Counter-metrics keep it honest

A north star adopted alone will be optimised alone, and the damage shows up somewhere it is not being measured. Every north star needs a small set of metrics that must not get worse, checked on every experiment that claims to move a proxy.

flowchart LR
  A[North star<br/>weekly collaborating teams] --> B[Proxy metrics<br/>tested in experiments]
  B --> C[Experiment OEC<br/>one per test]
  A --> D[Counter-metrics<br/>must not degrade]
  D --> E[Notification opt-outs]
  D --> F[Support tickets<br/>per active team]
  D --> G[Page load time]

Counter-metrics do not need to be powered to detect small effects; they need to be powered to catch disasters. Treating them as guardrails rather than as secondary outcomes is what keeps them from adding to the multiple-comparison problem. The published guide to guardrail metrics covers how to set the thresholds, and the note on false discovery rate control covers what happens when they are treated as findings instead.

Review the north star on a fixed schedule — annually is usually right — and change it deliberately or not at all. A north star that quietly changes definition is worse than none, because the trend line it leaves behind still looks continuous.

Frequently asked questions

How is a north star metric different from an OEC?

The north star is strategic, measured over months across everyone. The OEC is the decision rule for one experiment, measured over days on that experiment's users. The OEC should be a proxy you believe moves the north star, and it is what gets replaced when that belief fails.

Can a company have more than one north star metric?

Not usefully. The metric exists to force trade-offs to be made in the open; a second one restores the ambiguity it was adopted to remove. Multiple business lines with genuinely different customers may each need their own, but then they are line-level metrics, not a company north star.

Should revenue be the north star?

No. Revenue is the company's outcome, and steering by it rewards extraction as readily as value. Keep it as a guardrail that must not degrade, and choose a customer-value measure to steer by.

How often should the north star be reviewed?

Annually, on a fixed date, as a deliberate decision with the reasoning written down. Reviewing it whenever it stops flattering the roadmap is how a north star becomes a rotating set of metrics that happen to be going up.

What if no single metric captures the product's value?

That is common and it is a signal about the portfolio, not a licence for two north stars. Pick the metric that covers the largest share of customers, name explicitly what it leaves out, and measure the remainder separately rather than folding it into a composite nobody can interpret.