Analytics foundations metrics: facts, examples and context

A metric is an argument about what matters, compressed into arithmetic. Most of the difficulty is not in computing it: it is in choosing a shape that behaves honestly when the business changes underneath it.

This page is about that choice: which form a measure should take, which arithmetic traps each form carries, and what a definition needs to contain before anyone builds it.

What to take away

• Choose the simplest shape that answers the question.
• Most business quantities (order values, response times, session lengths, revenue per account), are skewed.
• A snapshot measures a population as it exists in a period: how many accounts were active in March.
• Any metric you push on will be optimized, including in ways you did not intend.

Pick the shape before the formula

Shape	Answers	Breaks when
Count	How much of a thing happened	The population is growing, so everything rises regardless of performance
Rate	How often, per unit of exposure	The denominator moves for reasons unrelated to the numerator
Ratio of two counts	How the two relate	Both move at once and the ratio hides it
Average	The typical value	The distribution is skewed, which for business data it usually is
Percentile	The value at a position in the distribution	The sample in a period is too small to place the percentile reliably
Cohort measure	How a group behaves over time since a shared start	Recent cohorts have not had time to mature and get compared to old ones
Share of total	Composition	The total changes, so a rising share can mean a shrinking segment

Choose the simplest shape that answers the question. Counts are underrated: for a stable population, a count is easier to interpret and harder to manipulate than a rate. Rates earn their complexity only when exposure genuinely varies.

Four traps that survive correct arithmetic

Averaging averages. The mean of per-day conversion rates is not the overall conversion rate unless every day had identical traffic. Aggregate the numerator and the denominator separately, then divide. This error is common, easy to make in a spreadsheet, and produces numbers that are wrong by a little, which is worse than wrong by a lot, because nobody notices.

Denominators with their own story. A rate improves when the numerator grows or when the denominator shrinks. If your denominator is something like "active users," a drop in activity flatters the rate. Always publish the numerator and denominator alongside the ratio, so a reader can see which one moved.

Percentages of small bases. A segment with a handful of members will produce the largest percentage change on the page every single period. Set a minimum base below which you show the raw counts instead of a rate, and hold the line on it.

Mixed grains. Combining a per-session measure with a per-user measure, or a weekly rate with a monthly one, produces something with no clear meaning. Every metric should state its grain, and any comparison should be at a single grain.

Averages and the distributions that defeat them

Most business quantities (order values, response times, session lengths, revenue per account), are skewed. A few very large values pull the mean away from anything typical. The average order value can rise while nearly every customer spends less, because one large order arrived.

Practical handling:

• Report a median alongside the mean whenever the distribution might be skewed. The gap between them tells the reader how skewed it is.
• For anything where the tail is the problem (latency, wait times, resolution times), report a high percentile. Averages actively hide the experience of the people having the worst time.
• Before publishing any average, look at the top handful of contributing rows. If removing one of them moves the number visibly, the average is describing that row, not the population.

Snapshot or cohort: they answer different questions

A snapshot measures a population as it exists in a period: how many accounts were active in March. A cohort measure borrows its logic from a cohort study and follows a group forward from a shared starting point: how the accounts that started in January behaved in each subsequent month.

Snapshots are easy and mix everything together. Cohorts isolate the effect of when someone started, which is what you need to answer "is the product getting better?", but they carry a specific hazard: recent cohorts have had less time to accumulate, so comparing an immature cohort to a mature one always makes the recent one look worse. Compare cohorts only at equal age, and mark the cells that are not yet complete.

Pair every driver metric with a guardrail

Any metric you push on will be optimized, including in ways you did not intend. Response time improves when tickets are closed without resolving them. Signups rise when the form gets easier and the leads get worse. Utilization rises when quality falls.

For each metric that a team is measured on, name the thing that could plausibly be sacrificed to move it, and report the two together. Never report the driver alone. The guardrail does not need a target: it needs visibility, so that a gain bought at a cost is visible as such.

The same logic applies to leading and lagging pairs. Leading indicators move early and can be acted on but are noisy proxies. Lagging indicators are what you actually care about but arrive too late to steer with. Publish both, and be explicit about which is which, so nobody mistakes an early signal for a result.

The six lines a definition needs

Before a metric is built, it should be written out in a form two people could implement identically:

1. Name, in plain language, distinct from every other metric in use.
2. Formula, with numerator and denominator stated as specific fields or conditions.
3. Population, including exclusions: internal accounts, test data, canceled records, bots.
4. Grain and window, including the timezone that sets the day boundary, and whether the window rolls or follows the calendar.
5. Source, the specific model or table it must be computed from.
6. Owner, one name, plus the date the definition was last reviewed.

Store this next to the code that computes it. A definition in a separate document drifts from the implementation, and when they disagree, the implementation is what people see.

Review metrics on purpose, and retire them

Metrics accumulate. Once or twice a year, take the list you publish and ask three questions per metric:

• Has anyone acted on this? Not looked at it: acted. If no, it is a candidate for removal.
• Does the definition still match the business? A new product line, a pricing change, or a migration can quietly make a definition wrong without breaking anything.
• Is it being gamed? If a number improves while the outcome it proxies for does not, the metric has become a target rather than a measure.

Removing a metric is a real improvement. Every one you publish competes for attention with the ones that matter, and a shorter list is read more carefully.

Related reading on this site

For where the definition layer sits relative to everything else, see analytics foundations framework. For the setup errors that definitions prevent, see analytics foundations mistakes. The pillar overview is analytics foundations. For the sequence in which a defined measure gets used on a real question, see how to work through a question.

Common questions

How many metrics should a team have?

Few enough that everyone on the team can recite them. A team with a dozen priorities has none, and the same applies to measures.

Should the metric change if the business changes?

Yes, but deliberately and with a decision about history: either restate the past under the new definition or apply it from a cutoff date forward. Announce the change before it lands and annotate the charts on the date it took effect.

What about metrics we cannot measure well yet?

Use an explicit proxy and label it as one. A named proxy with a known weakness is workable; a proxy that everyone has forgotten is a proxy is how organizations end up optimizing the wrong thing for years.