Every metric is a proxy. Revenue is a proxy for value delivered. Churn is a proxy for dissatisfaction. Page load time is a proxy for user experience. The quality of a measurement system depends on how well its proxies track the underlying reality they are supposed to represent.
The problem is not that metrics are proxies. It is that teams forget they are proxies and optimise the proxy directly instead of optimising the underlying thing the proxy represents.
Daily Active Users is the canonical example. It was a useful metric for social products until teams discovered they could inflate it with push notifications that users found annoying and eventually deleted the app to escape. The metric went up. Retention went down. The proxy had failed. The team had a healthy-looking dashboard and a dying product.
Leading vs Lagging Indicators
Metrics fall into two categories based on when they measure relative to the outcomes they predict.
Lagging indicators measure what has already happened. Revenue, churn, and customer lifetime value are lagging. By the time a lagging metric changes, the cause is weeks or months in the past. Lagging metrics are accurate but slow. They confirm outcomes; they do not help steer toward them.
Leading indicators measure current activity that predicts future outcomes. Activation rate — the proportion of new users who complete a meaningful first action — predicts retention. Feature engagement predicts long-term value. These metrics are faster but noisier; they can be misleading if the team misunderstands what they are actually measuring.
Technical decisions primarily affect leading indicators. A deployment that improves time-to-first-meaningful-interaction by 20% will show up in activation rate within days. It may show up in revenue six months later, buried in many other causal factors. Measuring technical investments against lagging indicators creates an attribution gap that makes technical work invisible to business decision-makers.
Goodhart's Law and Why DAU Broke
Goodhart's Law (L9): when a measure becomes a target, it ceases to be a good measure.
A team measured on bugs closed will close bugs without fixing the underlying problems, or reclassify open bugs to reduce counts, or write code that produces easily-closable small bugs rather than addressing root causes. A team measured on features shipped will ship small, low-complexity features to maximise count. The metric rewards shipping over impact. A single feature that triples retention counts as one feature. Thirty minor UI tweaks that produce no measurable change also count as thirty features.
The design principle that resists Goodhart corruption: choose metrics where the only viable path to improvement is to improve the actual outcome.
Retention is difficult to game because the only way to retain users is to deliver continuing value. Users who find no value leave. No amount of notification-spam or dark-pattern friction holds them indefinitely.
A Goodhart-resistant metric for a search product: query reformulation rate — the percentage of searches where the user modifies their query and searches again within the same session. The only way to reduce reformulation is to return better results. The incentive gradient points toward genuine improvement.
A Goodhart-resistant metric for a payments product: successful-transaction-to-dispute ratio. A team measured on transaction volume alone will approve marginal transactions that generate disputes. A team measured on dispute rate alone will reject legitimate transactions. The ratio forces both sides to improve together. Good: above 500:1 for consumer payments. Bad: below 100:1.
A Goodhart-resistant alternative to DAU for a SaaS product: weekly core-action users — users who performed at least one action central to the product's value proposition (creating a document, sending an invoice, deploying a build) within the last seven days. The metric cannot be inflated by notification-driven opens because opens without core actions do not count.
The HEART Framework
Google's HEART framework provides a structured approach across five dimensions. Each measures a different aspect of user value.
Happiness — user satisfaction, typically through surveys or sentiment. Instrument with in-app NPS or CSAT prompts triggered after task completion, not on page load. Good: NPS above 50 for B2B, CSAT above 4.2/5 for consumer. Common trap: high NPS driven entirely by power users while casual users never see the survey.
Engagement — depth of interaction. Emit named events for each core feature interaction (not page views). Track L7/L30 ratio (users active 7 of the last 30 days divided by users active at least once). Good: L7/L30 above 0.25 for a consumer app, above 0.6 for a daily-use tool. Common trap: high session count driven by users repeatedly failing to complete a task — each failure is an "engagement" event.
Adoption — proportion of users reaching a defined milestone, for a new feature or first activation. Instrument with funnels: exposure → activation → repeated use. Good: 30%+ activation for a UI-promoted feature. Bad: below 5%. Common trap: measuring as "users who clicked the button" instead of "users who completed the action." A 60% click rate with a 4% completion rate means the feature is broken, not adopted.
Retention — proportion of users returning after a defined interval. The strongest leading indicator of long-term value. Instrument with cohort tables grouped by signup week, measured at day 1, day 7, day 30, day 90. Good: day-30 above 20% (consumer), above 40% (B2B). Common trap: counting "any activity" when the product has notification-driven opens.
Task success — whether users who attempt a specific action complete it. Define start and end events for each critical flow. Good: above 90% for checkout, above 80% for multi-step forms. Common trap: a 95% rate that excludes users who abandoned before reaching step one. The funnel starts at intent, not at step one.
Instrumentation Is Architecture, Not Telemetry
A system that does not emit events at the right granularity cannot produce HEART metrics. The observability of user behaviour must be designed in from the start.
The event schema is the foundation. Every user action emits a structured event with: user_id (string), event_type (enum: page_view, feature_activation, task_start, task_complete, task_abandon, survey_response), timestamp (ISO 8601), properties (JSON map). Intentionally flat — nested structures complicate querying downstream.
The pipeline is four stages: client emits events to a lightweight ingestion endpoint (validates schema, drops malformed) → publishes to an event bus (Kafka or managed equivalent) → stream processor enriches with user metadata (cohort, plan tier, geography) → writes to analytical warehouse (BigQuery, Snowflake, ClickHouse). A nightly job computes HEART dimensions and writes results to a dashboard table.
Engineering cost: roughly two engineer-weeks for initial build plus one engineer-week per quarter for maintenance. The cost of not building it is operating blind — making product decisions based on anecdote, support tickets, and lagging revenue numbers that arrive too late to steer.
How Facebook Found the "7 Friends in 10 Days" Activation Threshold
Facebook's early growth team used a specific activation metric: did a new user add seven friends within ten days? Users who crossed this threshold retained at dramatically higher rates. The number was not arbitrary. It was discovered.
The method generalises:
- Pick a retention window (30 days is standard).
- Pick a candidate behaviour (friend adds, documents created, messages sent).
- Plot retention against behaviour count at a fixed early window (day 7 or day 10).
- Look for the inflection point. That is the activation threshold.
If there is no inflection — if retention rises linearly with the behaviour — the behaviour is correlated but not causal. The inflection test separates behaviours that predict retention from behaviours that merely accompany it.
Facebook validated causation by experiment: they changed the onboarding flow to make friend-adding easier and measured whether nudged users retained at the same rate as organic crossers. They did. The threshold was causal, not just correlational. Without that experiment, the team would have built a product feature on a correlation that happened to point the right way.
The Two Recurring Failures
Metric misalignment. The team optimises for a metric that was a good proxy when chosen and has since drifted. DAU was the example above: a useful metric until teams found they could inflate it without delivering value.
Metric isolation. Teams measure their subsystem's metric without measuring its impact downstream. Infrastructure teams optimise for deployment frequency without asking whether deployments change user outcomes. Product teams optimise for feature adoption without asking whether adopted features retain users. Each team's metric looks good. The product stagnates. This is FM11 (Observability Blindness) at the organisational level.
This article extracts the core of Book 7, Chapter 3 — Product Metrics and What They Measure. The chapter covers the full HEART instrumentation pipeline for a B2B SaaS at 100K MAU, the dashboard target/alert thresholds for each dimension, the Facebook 7-friends discovery method with the experimental validation step, the Amazon 100ms latency study, and the reflection exercises for auditing your current metric stack against Goodhart corruption.