North Star metrics and metric trees

A North Star metric is a durable measure of customer value delivered by the product. A metric tree explains the product inputs that can move that outcome and the guardrails that prevent a team from optimizing it destructively.

This is not a contest to find one impressive number. It is a model of how the product creates value, expressed as testable relationships.

GraphJSON does not provide a dedicated metric-tree editor. Keep the model, owners, assumptions, and definition versions in a reviewed catalog or source control. Use GraphJSON saved queries and dashboards as the operational view. Start with metric governance, which defines the contract for every node in the tree.

Choose a value outcome#

A useful North Star metric:

• describes value received, not activity performed by the company
• is specific to a durable entity such as an account or user
• occurs frequently enough to guide decisions
• is difficult to inflate without delivering the intended outcome
• can be measured consistently from trustworthy facts
• tends to precede retention or commercial success

“Reports exported by active accounts” may work for an analytics product if an export reliably represents a completed customer job. “Page views” usually does not: it may increase because users are confused.

Write the candidate as a sentence:

Weekly accounts that completed at least one decision-ready report

Then define decision-ready, account, week, exclusions, event time, deduplication, maturity, and version.

Separate outcome, inputs, and guardrails#

Use three layers:

An input should be close enough to a team’s work to change, but not so local that it loses the customer outcome. Shipping more onboarding emails is an output; more eligible accounts connecting valid data may be a useful input.

Draw the tree as hypotheses#

weekly accounts receiving report value
├── eligible active accounts
│   ├── new accounts activated
│   └── established accounts retained
├── opportunity per active account
│   ├── connected data sources
│   └── teammates participating
└── completion rate per opportunity
    ├── successful query execution
    └── report saved or exported

guardrails
├── p95 time to first value
├── query failure rate
├── support contact rate
└── paid logo retention

Every edge means “we believe this child helps explain or cause movement in its parent.” It is not automatically true because the diagram looks plausible. Record the assumption, evidence, owner, and expected direction.

Make decomposition mathematically honest#

Prefer exact identities where possible:

value-producing accounts
  = eligible accounts × value-production rate

For averages:

completed reports
  = active accounts
  × opportunities per active account
  × completion rate per opportunity

Do not add overlapping cohorts and call the result a decomposition. New, resurrected, and retained accounts must be mutually exclusive if they sum to all active accounts.

When a relationship is not an identity, label it as a driver hypothesis rather than disguising it as arithmetic.

Balance leading and lagging measures#

The North Star is often a leading indicator of retention or revenue, but that relationship must be validated. Keep:

• a near-term product outcome
• earlier controllable inputs
• later business outcomes
• quality and harm guardrails

A fast-moving activation metric helps diagnose this week. Retention confirms whether the value was durable. Revenue may lag further and includes pricing, sales, and billing effects beyond product behavior.

Avoid selecting a North Star only because it correlates with revenue in the same period. Large customers can mechanically raise both.

Query one governed outcome#

Suppose report_completed is emitted at the authoritative server boundary:

{
  "event": "report_completed",
  "account_id": "acct_7",
  "report_id": "rpt_91",
  "result": "success",
  "decision_ready": true,
  "environment": "production",
  "schema_version": 2
}

The weekly North Star can be:

SELECT
  toStartOfWeek(toDateTime(timestamp), 1, 'UTC') AS week,
  uniqExact(JSONExtractString(json, 'account_id')) AS value_accounts
FROM product_events
WHERE
  JSONExtractString(json, 'event') = 'report_completed'
  AND JSONExtractString(json, 'result') = 'success'
  AND JSONExtractBool(json, 'decision_ready') = 1
  AND JSONExtractString(json, 'environment') = 'production'
  AND JSONExtractString(json, 'account_id') != ''
GROUP BY week
ORDER BY week

If decision_ready is a business interpretation rather than a stable fact, derive it from documented properties in the query instead of embedding a changing policy in the event.

Validate the model#

Test the tree in four ways:

1. Definition: manually reproduce a settled period from source records.
2. Mechanical: confirm exact decompositions add or multiply correctly.
3. Predictive: check whether earlier inputs predict later outcome changes after controlling for account size, tenure, plan, and acquisition mix.
4. Experimental: when feasible, use controlled changes to test a driver.

Correlation does not establish causality. Teams that already succeed may use more features; the feature may not be what made them successful.

Use holdouts, maturity windows, and comparable acquisition cohorts. Inspect both the average and the distribution: a growing total can conceal declining value for small accounts.

Assign ownership without fragmenting definitions#

Give each node:

• one definition owner
• one operational owner
• a review cadence
• a freshness expectation
• a definition version
• named dashboards and consumers

The product team may own activation work while analytics owns the metric contract. Finance remains authoritative for accounting measures. Reliability owns service-level guardrails. Shared visibility does not mean shared ambiguity.

Build the dashboard in reading order#

A decision-oriented dashboard should show:

1. North Star level, change, target context, and freshness
2. cohort or segment distribution
3. input decomposition
4. guardrails
5. later retention or commercial outcomes
6. definition version and last material change

Do not place twenty equally prominent metrics on one screen. The hierarchy in the dashboard should match the hierarchy in the model.

Annotate releases, instrumentation changes, outages, and definition changes. GraphJSON does not currently provide a dedicated annotation system, so use deployment events, a companion chart, or the dashboard description.

Revisit rather than rotate#

A North Star should survive ordinary roadmap changes. Review it when:

• the product’s value proposition changes
• the served entity changes
• the event no longer represents completed value
• validation stops showing a relationship with durable outcomes
• teams learn that the metric can be gamed

Version a material definition change and overlap old and new series. Do not replace the metric each quarter to match the current initiative.

Review checklist#

• The North Star describes customer value, not company activity.
• Entity, event, time, exclusions, and maturity are explicit.
• Inputs are controllable and connected by documented hypotheses.
• Exact decompositions are mathematically valid.
• Guardrails cover quality, harm, and durable outcomes.
• Relationships are validated across cohorts and account sizes.
• Every node has an owner, version, and canonical implementation.
• The dashboard communicates hierarchy and freshness.
• Material changes preserve an auditable transition.

For ready-to-adapt implementations of activation, adoption, retention, and stickiness, continue with the Product metrics cookbook.