A North Star Metric is the one number that best captures the value a product delivers to its customers, chosen so every team can see how its work moves it. Amplitude and Sean Ellis popularised the idea, and it helps most at a company with dozens of dashboards and no number everyone agrees on. Its strength and its risk are the same thing: when the whole company steers by one number, an error in that number steers the whole company.
How it works
A good North Star counts customers getting value, not the company getting paid: teams active on at least three days in the week that also shared a report, say, rather than revenue. It sits above a few input metrics that teams own directly, such as activation rate or reports created per team, and the inputs are where day-to-day work happens.
Almost no North Star is a single event. It is a filter for who counts, a qualifying action for what counts as value, and a time window, stitched together in an analytics tool. Each part is a place where a renamed event, a dropped property or a changed definition can move the number while every customer behaves exactly as before.
What it assumes your events already do
| Event | What the framework uses it for | What it reports when the event breaks |
|---|---|---|
Core value actionreport_viewed | The qualifying value action. | If it is renamed, the North Star drops on release day and teams start explaining a decline that never happened. |
User-to-account joinaccount_id on every event | Counts teams rather than individual users. | Events missing the account property drop users out of their team, so the newest setups are undercounted. |
Return visitsession_started | Decides which teams meet the active-days filter. | If the return event changes, teams fall in or out of the active-days filter, and the North Star moves a few percent with no change in sharing. |
Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.
The North Star that moved with the mobile release
Illustrative example. The company and the figures are invented to show the mechanism.
A company's North Star is teams active on at least three days in the week that shared a report. The mobile app ships a new share sheet that fires report_exported rather than report_shared. Mobile is a fifth of usage, so the North Star falls 9% in a week.
A product squad spends a sprint on an experiment to win the users back. The users never left. One event changed its name on one platform, and the company's single most watched number followed it.
Checks before you trust it
- Write the North Star as a definition with named events, properties and a window, not as a sentence.
- Name one owner who signs off any change to an event the definition uses.
- Break a move down by platform and app version before reacting; a drop confined to one release is usually tracking.
- Keep the input metrics next to the North Star, so a move in the total traces to the input behind it.
Heard in The Question
Interviews in The Question that bear on this framework:
- Maria Petrova: data tells you what happened, never why. Data establishes what happened and never why, and tracking is infrastructure to build before the first real user, not something to add later.
- Dino Repo: one metric, five numbers, and a ten-minute fix. Untrustworthy data is an ownership problem before it is a tooling problem, and the cheapest fix is a product-data check that runs every time the build loop turns.
- Niko van Eeghen: one metric, three meanings at Evondos. The number is rarely the hard part: one metric means different things to different people, and in parts of the economy you cannot or may not collect it.
- John Adib: when agents read your analytics, event names break first. Once an agent rather than an analyst queries the analytics, ambiguous event names stop being hygiene and start producing wrong numbers in the business review.
Check the events under it
Before North Star Metric goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.