A measurable signal that tracks an outcome or product behaviour.
A metric is a defined, repeatable measure of progress, health, or behaviour. It names what you count, how you count it, and over what window, so the same definition yields the same number every time. The test of a good one is behavioural: if the number moves and nobody changes what they do, the metric was decoration.
Measurement long predates software, but product practice inherited a sharp distinction from the lean movement. Eric Ries, in The Lean Startup (2011), separated actionable metrics from vanity metrics: a vanity metric (total registered users, cumulative downloads) only ever rises and flatters the team, while an actionable metric ties a cause to an effect a team can influence. He tied this to cohortCohortGrowthA group of users sharing a common characteristicView reference → analysis, which tracks how each weekly batch of new users behaves over time rather than blurring everyone into one ever-growing total.
Dave McClure made the categories concrete with Startup Metrics for Pirates (2007), the AARRR framework: acquisition, activation, retention, referral, revenue. It mapped the five behaviours that decide whether a business works and gave teams a vocabulary for which number belongs to which stage of the customer lifecycle.
Alistair Croll and Benjamin Yoskovitz pushed the thinking furthest in Lean Analytics (2013). They argued a good metric is comparative, a ratio or rate, easy to understand, and above all changes how you behave, and they introduced the One Metric That Matters: the single number to obsess over at your current stage, switching as the business moves through empathy, stickiness, virality, revenue, and scale. Sean Ellis's North Star Metric, coined around 2010 and later codified into a framework by Amplitude, made the durable companion idea: one metric capturing the core value the product delivers, holding steady across stages.
A subscriptionSubscriptionSales & RevenueA recurring subscriptionView reference → team reports 1.2 million registered users in the board deck, and the number always grows. It is a vanity metric: it never falls, and it hides the fact that most of those accounts logged in once and vanished. They replace the headline with a ratio defined precisely as a metric: week-4 retention, the share of each weekly sign-up cohort still active four weeks later, where "active" means at least one project edited.
The new number is comparative (this week's cohort versus last month's), it can move in both directions, and it changes behaviour. When the March cohorts retain at 22% against January's 31%, the team has a real problem to chase, traceable to a specific releaseReleaseProduct SpecificationA shipped version of the productView reference →. The vanity number would have kept climbing the whole time, reassuring everyone while the product quietly leaked users.
In the Unified Product Graph, MetricStrategyA unified metric that measures progress, health, or behaviour across the product is a leaf shared between the Strategy & OutcomesOutcomeStrategyA desired business or user outcomeView reference → and Analytics regions, which is why a number can be both a board-level target and an operational measure. Its richest structure is self-referential: metricMetricdecomposes intoMetrichierarchy builds the input tree beneath a North Star, metric_decomposes_into_metricMetricdrivesMetriccausal captures the causal links between leading and lagging numbers, and metric_drives_metricMetricguardsMetricsemantic models the guardrail relationship directly. Upward, it quantifies strategy through metric_guards_metricKey Resultquantified byMetrichierarchy and key_result_quantified_by_metricOutcomemeasured byMetrichierarchy; sideways, outcome_measured_by_metricMetricsegmented byPersonacross-domain splits a number by who it describes. Because guarding, driving, and decomposing are distinct edges, the graph encodes not just what you measure but how your measures relate, which is the difference between a dashboardDashboardData & AnalyticsAn analytics dashboardView reference → and a model.metric_segmented_by_persona
Type-specific fields on BaseNode
designationstringRole this metric plays in the measurement system
actionstringThe action or behaviour this metric measures (e.g. "users who activated within 7 days")
unit_of_analysisstringThe unit being counted or measured (e.g. "users", "sessions", "£")
statistical_functionstringAggregation function applied to raw data
formulastringCalculation formula or expression
impact_levelstringWhere this metric sits in the impact hierarchy
indicator_directionstringWhether this metric leads or lags the behaviour it measures
metric_categorystringAARRR or HEART category this metric belongs to
current_valuenumberMost recent observed value
target_valuenumberValue we are aiming to reach
unitstringDisplay unit for the metric value (e.g. "%", "ms", "£")
range_minnumberMinimum expected or baseline value
range_maxnumberMaximum expected or ceiling value
cadencestringMeasurement cadence. Canonical `Cadence` since v0.4.0. `'realtime'` migrates to `'continuous'`; all other values 1:1.
data_sourcestringData source or tool that feeds this metric (e.g. "PostHog", "Stripe")
ownerstringPerson or team responsible for tracking this metric
metric_healthstringUniversal health rollup. Orthogonal to lifecycle and `guardrail_status`. Applies to every metric regardless of `designation`. `healthy` = trending well against target / inside safe range. `at_risk` = drifting, approaching breach or target shortfall. `unhealthy` = missed target or breached; action needed. `unknown` = no current reading or not yet measured. For guardrails specifically, `guardrail_status` remains the breach-specific signal (`safe`/`warning`/`breached`).
guardrail_threshold_minnumberLower bound for guardrail safety (below this = breach)
guardrail_threshold_maxnumberUpper bound for guardrail safety (above this = breach)
guardrail_statusstringCurrent guardrail health state
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
49 edge types connected to this entity.
product_measures_with_metricoutcome_measured_by_metricsolution_measured_by_metricexperiment_run_measures_metricobjective_measured_by_metrickey_result_quantified_by_metricdata_source_defines_metricmetric_decomposes_into_metriceval_benchmark_defines_metricmetric_decomposes_into_metricmetric_drives_outcomemetric_validated_by_data_quality_rulemetric_assessed_by_metric_quality_assessmentexperiment_plan_targets_metricnps_campaign_tracks_metricoutcome_tracked_by_metrickey_result_tracked_by_metricmetric_guards_metricmetric_guards_metricmetric_segmented_by_personaservice_level_objective_tracks_metricproduct_guided_by_metricmetric_decomposed_into_metricmetric_decomposed_into_metricmetric_drives_metricmetric_drives_metricmetric_measures_key_resultgrowth_loop_drives_metricrevenue_stream_measured_by_metriccost_structure_measured_by_metricrevenue_stream_drives_metricrevenue_stream_measured_by_metric_cross_domainforecast_projects_metricmetric_measures_metricmetric_measures_metricmetric_measures_metric_cross_domainmetric_measures_metric_cross_domaindashboard_tracks_metricconstraint_constrains_metricexperiment_run_guards_metricexperiment_run_measured_by_metriccustomer_health_score_composed_of_metricservice_level_agreement_measures_metriclearning_observed_on_metriceval_run_produces_metriccohort_measured_by_metricbehavioral_segment_measured_by_metricfeedback_program_measured_by_metricmetric_segmented_by_behavioral_segmentIn a portfolio document, Metric entities can participate in cross-product edges, the typed relationships that link entities across different products. These edges are declared in UPGPortfolioDocument.cross_edges.
shares_metric{product_id}/{node_id}. They are declared in the cross_edges array of a UPGPortfolioDocument, not inside individual product graphs. See Portfolio for the full model.8 frameworks use this entity type.