Product metric system

The metric system links user value, business output, and team-driven actions. Don’t start with the available graphs: formulate a causal model of the product, identify lagging and advancing signals, and for each metric, fix the formula, source, and boundaries of interpretation.

Why do we need a metric system at all?

Metrics: Why build them, not just collect them

Product metrics show the real picture: what happens to users, where growth points and where failures occur. Conventional data collection does not work. It works with a systematic approach: clear structure, clear goals and regular work with numbers.

In practice, metrics help:

• know what to improve;
• Prove hypotheses by numbers, not by opinion.
• Do not give in to illusions like “it seems all right.”

Example: Launching a new feature

The new chat feature in the product. Without the metric system, you only see the number of discoveries and errors. With the system, you analyze how retention, engagement, real growth of new users affects.

Main types of product metrics and structure

Leading and lagging metrics

Divide metrics into leading and lagging, leading metrics to quickly understand whether future improvement is possible, and lagging metrics to show the result of change.

Example:

• Lead: frequency of repeated visits (if it increases, most likely LTV increases).
• Lagging: One-user revenue (LTV), weekly retention.

Classical model: AARRR and its analogues

AARRR: Acquisition, Activation, Retention, Referral, Revenue. Suitable for almost any IT product (for more details see GrowthHackers AARRR Model).

Example for a mobile application:

• Acquisition: How many new installations
• Activation: How many users have reached the first useful action
• Retention: how many returned for 2-7 days
• Referral: How many friends have called from the app
• Revenue: How much money did you pay?

If you need your own framework, look at the options: HEART (Google), Pirate Metrics, GameLoft Model.

How to build a metric system: 4 steps

1. Define the objectives of the product

What is the product supposed to change? Example: increase the frequency of purchases, keep newcomers longer than a week, bring them to repayment. Without a goal, metrics turn into chaos.

2. Formulate key metrics

I’ve highlighted the numbers that teams can actually influence, like the conversion rate, the average user check, the percentage of users who returned by day 3.

3. Build a chain of links

Link metrics to system: How does changing one affect others? If you increase activation, what happens to retention? If you improve retention, how does that affect revenue?

4. Set up experiments

Identify which metrics should change from experimentation (success metrics) to protectionrail metrics, such as a recommendation that you see if engagement increases, but make sure that complaints don’t grow.

Metrics for Experimentation and Decision Making

Hypothesis Metrics: What Can and Cannot Be Measured

Make it clear what number the experiment should change, the mistake is to run the feature and wait for the “growth of everything” to work with specific, variable and measurable metrics.

Example: Testing a new onboarding feature

• The goal is to increase the conversion of the first session to registration by 8%.
• Measured: conversion, speed of passage, the share of fallen off
• Guardrail: Number of complaints not growing

Evaluation of results and decision-making

Check your system map of metrics regularly, make decisions based on reliable, sustainable change, and random jumps without change are a reason to dig deeper.

Frequent errors and anti-patterns

Too many operational and vanity metrics

It is common: complicate the system, pull the team behind the “beautiful numbers”, which do not give an increase in business results.

Example: following likes/shares in B2B to revenue is pointless without a connection to sales.

Do not follow the basic metrics in experiments

Classic: one metric rises by another metric falls, like push notifications increase DAUs, but increase churn, don’t add new experiments until you’ve analyzed the risks on guardrail metrics.

Not updating the system after changes

Business changes, metrics stay the same, you lose control so quickly, and investing in analytics stops paying off, and check the relevance of key metrics at least once a quarter.

Where to study and look for benchmarks

For in-depth study:

• Amplitude Guide: Product Metrics
• Google HEART Framework Explained

Open dashboards with benchmarks are easier to find for mobile apps and e-commerce. There are no universal numbers: look at comparable companies, use benchmark collections in Amplitude.

FAQ

**1 What to do if the metric is too much? Keep only those that are really influenced by the team and that affect business goals, and keep the rest of them in archives or as references.

How quickly do you know that experiments improve key metrics? Watch the system link of metrics. First, look for changes in the leading metrics, then look at the final metrics.

When to change the structure or set of metrics? When you change your strategy, your core product cycle, you get new user segments, and at least once a quarter, you have to check the relevance.

How do you distinguish vanity metrics from real metrics? Vanity is a beautiful picture, but it’s not related to business growth: sign-up conversions, re-purchase rates, LTVs are real metrics; chers, likes, total time on the app are often just background.

5. Where do you find good examples and best practices? Useful primary and practitioner sources include Amplitude, Mixpanel, Google, Atlassian, Product School, Mind the Product, and the NNGroup library.

6 How to introduce a metric system for a complex product with multiple audiences? Identify key segments. For each, define your goals and set of metrics, link them with a common business impact map.