metrics-design

Define success metrics by passing five tests: observable in production data, leading within days or weeks, tied to user outcomes rather than feature usage, anchored to a known baseline, and targeted with defensible rationale. Record them in a Metric/Current/Target/Window/Source table.

Leading metrics move within days or weeks of shipping and validate a specific bet, while lagging metrics like revenue or 90-day retention confirm long-term outcomes over months. An initiative should carry both: a leading metric to steer the team and a lagging metric the business judges.

You should not set a target without a baseline. Write the current value as unknown with a note that baseline measurement is needed, and treat establishing it as a precursor work item before the spec can promote to committed.

DAU, pageviews, clicks, and impressions are activity counts without quality dimensions, and almost no single feature moves them enough to attribute impact. They are useful for trend monitoring but rarely valid as the success metric for one bet.

Use a proxy metric when the real outcome is hard to measure directly, but always name it as a proxy in the spec and note what would invalidate it. For example, search abandonment rate as a proxy for search quality breaks if users stop searching entirely.