A metric is not just a calculation.

A metric is ontology with math attached.

Every metric says what exists, what counts, what does not count, how objects relate, which time period matters, which system is trusted, and who has authority to interpret the result.

This is why metric debates become so emotional. People are not only arguing about a number. They are arguing about the company’s model of reality.

Take ARR. It sounds simple until the business gets even mildly complex. Do you include signed contracts that have not started billing? Do you include usage-based commitments? Do you include discounts? Do you include one-time services? What happens when a contract has multiple products, currencies, subsidiaries, or ramp schedules? What is the treatment for suspensions, downgrades, credits, failed payments, and disputed invoices?

The formula depends on definitions. The definitions depend on operating choices.

Or take gross margin by product. You need a product definition, revenue allocation logic, cost allocation logic, time windows, currency handling, support cost treatment, hosting cost treatment, implementation cost treatment, and perhaps professional services attachment. If finance, product, and data do not share the same object relationships, the margin dashboard becomes an argument starter instead of a decision tool.

Metrics are where hidden ontology becomes visible.

The same is true for customer health. A health score may combine usage, support tickets, NPS, contract status, executive sponsor, payment status, implementation milestones, and CSM judgment. That sounds useful. But each input carries assumptions.

Which usage events represent value? Which tickets count as risk? Does an overdue invoice indicate dissatisfaction or procurement friction? Does NPS from one admin represent the whole account? Does CSM judgment override product signals? Which customer object is being scored: parent account, workspace, contract, or legal entity?

A health score is not neutral. It encodes a theory of the customer relationship.

If the theory is weak, the score creates fake precision.

This is the trap of modern BI. Dashboards can make weak definitions look professional. A clean chart can hide conflicting sources, stale fields, arbitrary filters, and undocumented transformations. People stop asking what the metric means because the visualization looks official.

Then the company makes decisions from a beautiful abstraction of a messy model.

Good metric design starts before the formula.

For each important metric, define:

  • decision supported;
  • business owner;
  • calculation owner;
  • objects involved;
  • source systems;
  • inclusion and exclusion rules;
  • time window;
  • refresh cadence;
  • known limitations;
  • acceptable use;
  • unacceptable use;
  • exception handling;
  • change control.

The “decision supported” line is the most important. If a metric does not support a real decision, automation, inspection rhythm, or accountability system, it is probably dashboard decoration.

Dashboard decoration is not harmless. It consumes trust.

When leaders see too many metrics with unclear definitions, they start treating all numbers as negotiable. The serious metrics get discounted along with the weak ones. Data teams become defensive. Operators build private spreadsheets. Finance becomes the only trusted source for anything involving money, even when finance does not have the operational context. Product teams ignore GTM metrics. GTM teams ignore product metrics. Everyone says they are data-driven while choosing the data they already believe.

A smaller set of trusted metrics beats a large gallery of ambiguous ones.

This is especially important when metrics drive compensation, routing, prioritization, customer commitments, or AI workflows.

If a sales compensation metric depends on opportunity stage definitions, those stage definitions are no longer a CRM hygiene issue. They are compensation infrastructure. If a product roadmap metric depends on active usage, active usage is no longer an analytics convenience. It is investment infrastructure. If an AI agent recommends renewal actions based on health score, health score is no longer a dashboard input. It is execution infrastructure.

Metrics become operating controls.

That means changes to metric definitions need governance. Not bureaucracy. Governance.

A metric owner should be able to explain what changed, why it changed, what historical comparisons are affected, which dashboards and workflows are downstream, and who was notified. Silent metric changes are a fast way to destroy trust.

One practical move is to attach a “metric contract” to every executive metric.

The contract does not need to be long. It should answer:

  1. What decision does this metric support?
  2. What is the plain-language definition?
  3. What are the source systems?
  4. What objects and relationships does it depend on?
  5. What are the known caveats?
  6. Who owns the definition?
  7. Who owns implementation?
  8. When was it last changed?

This turns metric governance from a theoretical data practice into an operating habit.

It also helps AI.

AI systems are increasingly asked to answer questions like “Why did churn increase?” or “Which customers are at risk?” or “What should we prioritize next quarter?” If the metric definitions are buried in SQL, tribal knowledge, or old Slack threads, AI will generate plausible explanations without understanding the metric’s limitations.

A metric contract gives AI and humans a shared context layer. It tells the system what the number means, where it comes from, and how not to misuse it.

The deeper point: metrics should not be treated as outputs of the operating system. They are part of the operating system.

They shape what teams notice. They shape what managers inspect. They shape what gets rewarded. They shape what gets automated. They shape what AI systems retrieve and optimize.

Measurement mistakes become management mistakes.

If the company measures activity instead of value, teams optimize activity. If it measures booked revenue without cash risk, leaders overcommit. If it measures usage without outcome, product teams chase engagement theater. If it measures support volume without severity or entitlement, staffing decisions get distorted. If it measures AI usage by token volume alone, adoption may rise while quality stays flat.

Every metric is a bet on what matters.

Make the bet explicit.

Before adding another dashboard, inspect the ontology underneath the metrics you already use. Ask what objects they assume, what relationships they depend on, what definitions they encode, and which decisions they drive.

If the answer is unclear, the company does not need more analytics.

It needs a better model of the business.