Only 100 Metrics Matter
We track everything.
Every click, scroll, impression, and event. Every field in every table.
That’s fine. Logging is cheap. We also need them when we need to understand rare phenomena.
But attention isn’t.
Most of what we track never helps us make better decisions.
The truth is simple:
Only about 100 metrics really matter.
These 100 metrics explain 90% of what’s happening in your business and product.
And the same principle holds elsewhere too:
Only 50 events truly matter for understanding user and system behavior.
Only 150 entity characteristics — the key attributes of your users, products, or content — explain most outcomes.
Everything else lives in the long tail: useful for special cases, but not essential for running the business on a daily basis.
1. The System Beneath the Surface
Every business can be represented as a system.
And these systems can be written as a set of equations.
When you express your business as equations, you expose its levers. These levers are potentially actionable and can actually move results.
Take Facebook’s revenue model. It can be simplified into four components:
That’s it — four levers at the highest level.
To grow revenue, you can:
Increase users (growth)
Increase engagement (more impressions per user)
Raise ad load (more ads per impression)
Improve monetization (revenue per ad)
Each of these can be broken down further. Lets go deeper into understanding growth.
2. The Power of Decomposition
Let’s choose Monthly Active Users (MAU) as a proxy for growth. You can decompose MAU by an equation.
You can also grow your active users by getting new users, resurrecting churned users and keeping the existing users from churning. Now, let’s go one layer deeper.
If we define a new user as someone who registers and then takes an action, growth comes from improving each step of that journey. We can bring in more visitors at the top of the funnel, get more of them to download the app, increase the share who open it, raise the percentage who register, and finally help more of them take their first action.
Each step is measurable.
Each can be improved.
Each has a story behind it.
And if you want, you can keep peeling — looking at funnel drop-offs, activation, or engagement drivers.
This is the beauty of decomposition.
When you break the system into equations, you can see what drives what.
3. Why Only 100 Metrics Matter
As you go deeper into your metric stack, a pattern starts to emerge.
Each additional layer gives you smaller returns. The audience gets narrower, the lift from changes shrinks, and the noise in your data rises. At some point, you don’t have the time, tools, or people to act on what you find. The marginal value of going deeper wears off fast.
That’s why you don’t need thousands of metrics to understand your business.
You need a small, well-defined core.
What Determines How Many Metrics You Need
The right number isn’t fixed — it depends on the structure and maturity of your business.
Complexity of the system
Multi-sided marketplaces like Uber or Instacart need more metrics because the underlying equations are more complex. Each side of the market has its own levers and interactions.
Number of teams
The more product and business teams you have, the larger and deeper your metric graph becomes. Every new team introduces its own slice of the model.
Margin sensitivity
The thinner the margins, the more precise you need to be. In payments, logistics, or fraud detection, even a 0.01% shift can be material. Low-margin businesses tend to maintain a deeper and more granular metric set.
Stage of the company
Early-stage companies can rely on intuition and simple metrics. The problems are broad, and the “low-hanging fruit” is obvious. As a company matures, it builds more products and dives deeper into each layer of understanding and the metric set naturally expands.
For most small or early-stage companies, fewer than 100 metrics are enough to grasp most of the value.
As the company grows, that number might climb but rarely beyond a few hundred.
At Meta, for example:
About 50 canonical metrics explained most of user growth.
Another 50 covered the ads business.
Another 50–100 captured core products like News Feed, Groups, Pages, and Games.
That’s it. Roughly 500 canonical metrics across one of the world’s most complex and diverse platforms.
For most companies, the right number will be closer to 100 or fewer.
And that small, stable set was enough to answer about 90% of the company’s questions.
The rest lived in the long tail: useful for specific sporadic use cases.
5. Lessons from Meta
Before defining canonical metrics, every team at Meta had their own dashboards and definitions.
We had three versions of “monthly active users,” five definitions of “session,” and endless arguments about which one was right.
When we standardized around a canonical set of a few hundred metrics — linked through governing equations — everything changed.
Everyone spoke the same metric language.
All product people could compare apples to apples.
Analysts could diagnose issues faster.
That shared foundation made the company more consistent, faster to act, and easier to reason about.
We stopped asking, “Which number is right?”
and started asking, “Why did this number change?” and “What should we do?”
6. The Long Tail Still Matters — But Differently
You’ll always need a long tail of metrics, events, and attributes for experiments, edge cases, or investigations.
That’s fine.
But treat them as ad-hoc analysis tools, not part of your canonical store.
Keep your core clean.
Let the rest live in notebooks, scratch dashboards, or temporary pipelines.
Your canonical layer should stay small, stable, and trusted.
That’s what makes it powerful.
7. How to Build Your Canonical Core
Here’s a practical way to start:
Write your equations.
For revenue, growth, retention, engagement, cost, etc.
These are your governing truths.
Identify the drivers.
Each top-level equation should decompose into 3-4 drivers.
Recursively drill down
Enough to cover your major governing equations that matter.
Identify frequency, depth and breadth characteristic for entities
The attributes that most explain user and product behavior.
Document them.
One definition, one owner, one source of truth per metric.
Encode relationships.
Build your metric tree and semantic links.
Keep the core stable.
Changes should be relatively rare, reviewed, and versioned.
8. A Real Example
A Consumer company I worked with had over 2000 metrics and tens of thousands of event types.
They assumed that all metrics mattered and all events mattered.
They built no hierarchy. No canonical metrics. No metric trees.
No one trusted the numbers. Every dashboard said something different.
We cleaned it up.
They ended up with:
50 canonical events that matter
200 canonical metrics that moved the needle
200 key user and product attributes that help understand user behaviors
Three months later, they could explain why churn was rising and which features actually drove retention.
They didn’t collect new data — they clarified what mattered.
Focus beat volume.
Truth replaced noise.
9. The Future: Semantic Systems and AI
The next step in this evolution is semantic understanding — not just logging and measuring, but connecting meaning.
When you encode metric trees, relationships, and governing equations into a semantic layer, your data stops being flat.
It becomes a structured knowledge graph that an AI system can actually reason about.
That’s when the magic happens.
An AI system that knows:
how metrics relate to each other,
which events feed into which outcomes, and
which user attributes shape behavior,
can start to think about your business — not just report on it.
It can trace causality, surface patterns humans might miss, and even suggest hypotheses.
It can answer not just “what happened?” but “why?” and “what might happen next?”
That’s the future:
businesses built on semantic understanding, where data, metrics, and AI share a common mental model.
Once you have that foundation — 50 core events, 100 core metrics, and 150 core characteristics — AI stops being a toy dashboard layer.
It becomes a true partner in reasoning about your system.
