How to Define Your Metrics Once (and End the "Whose Number Is Right?" Fight)

Here's a meeting you've probably sat in. Sales says ARR is $4.2M. Finance says it's $3.8M. Customer Success has a slide that says $3.5M "at-risk-adjusted." Nobody's lying. They just have three different definitions of the same word, and now the board meeting is a debate about arithmetic instead of the business.

That's not a data-quality problem. It's a definition problem. And the fix isn't a new dashboard — it's writing your metrics down, once, in a way humans and machines can both use.

This is a practical guide to doing that. It's tool-agnostic: the same steps work whether your "single source of truth" ends up in dbt, LookML, a Cube model, a set of Markdown files, or Fastero. The format matters more than the vendor.

Why "everyone just knows what revenue means" fails

Two forces guarantee metric definitions diverge:

1. Tribal knowledge doesn't survive contact with growth. The definition lives in one senior analyst's head. She leaves, or the team triples, and now there are five interpretations and no referee.
2. AI made ambiguity expensive. It used to be that a fuzzy definition just meant a slightly-wrong slide. Now you've pointed an AI agent at your warehouse, and every time someone asks "what's our retention rate?" it guesses — logo retention? net revenue retention? cohort-based? — and returns confident, plausible, wrong SQL. As one analyst who's lived through three of these tool waves put it: the model "just makes the SQL prettier on the way to the wrong answer."

A single, written definition is the referee. Here's how to build one.

Step 1: Inventory the metrics that actually cause fights

Don't try to define all 300 metrics. You'll never finish, and most don't matter. Start with the ones that (a) show up in leadership decisions and (b) people argue about.

Practically: pull the top 10–15 questions stakeholders ask repeatedly. Revenue, ARR/MRR, active users, churn, conversion rate, pipeline, CAC. If two people would compute it differently, it's on the list. That's usually 15–25 metrics — a weekend, not a quarter.

Step 2: Write each definition in a format both humans and agents can read

This is the core skill. A good metric definition has five parts:

• Name — the canonical term (and its common aliases, so "MRR" and "monthly recurring revenue" resolve to the same thing).
• Plain-English meaning — one sentence a new hire understands.
• Exact logic — the calculation, unambiguously. Which table, which filter, which time grain, which currency, what's excluded.
• Edge cases — refunds, trials, discounts, currency conversion, timezone. This is where definitions actually diverge; be explicit.
• Owner — a human who arbitrates when it changes.

A concrete example in a format an agent can consume:

metric: net_revenue_retention
aliases: [nrr, net dollar retention, ndr]
meaning: >
  Revenue retained and expanded from a cohort of customers over 12 months,
  excluding new customers acquired in the period.
logic: >
  (starting_mrr + expansion_mrr - contraction_mrr - churned_mrr)
  / starting_mrr, measured on the customer cohort active 12 months ago.
grain: monthly cohort, trailing 12 months
currency: USD, converted at month-end FX
excludes: [trials, one-time charges, customers < 1 month old]
owner: head-of-finance
source_of_truth: warehouse.finance.mrr_movements
last_reviewed: 2026-07-01

Notice this isn't code — it's a specification. Your dbt model, your BI tool's measure, and your AI agent's context all implement it, but the definition is the contract they answer to. Write the contract first.

A useful test for each definition: could a new analyst, given only this, produce the exact number the CFO expects? If not, it's underspecified.

Step 3: Put it where both people and tools can reach it

A definition nobody can find is a definition nobody uses. You have three broad options, in increasing order of enforcement:

• Documentation (Markdown / a wiki). Cheapest. A /metrics folder of Markdown files in Git, or a Notion database. Surprisingly effective — plenty of teams now keep metric definitions in Markdown specifically so their AI agents can read them before answering. Weakness: nothing enforces it; dashboards can still drift from the doc.
• A semantic layer. dbt Semantic Layer, Cube, LookML, Power BI's model. Now the definition is executable — tools query the metric, not a hand-rolled SQL copy. Stronger enforcement, more setup. (We compared the options in the best semantic layer tools of 2026.)
• A governed platform. Looker/AtScale-grade, with certified metrics and row-level security. Strongest enforcement, real cost and staffing.

Match the enforcement to your stakes. A 20-person company does not need certified-metric governance; it needs the fifteen definitions written down somewhere the AI and the analyst both read. A regulated 500-person org needs the governed platform. Most teams over-buy here — see self-serve analytics without the enterprise price tag for the lightweight path.

Step 4: Connect the definitions to how people actually ask questions

The definition is only useful at the moment of the question. Two patterns work:

• Pre-built, governed surfaces — dashboards and saved queries built from the definitions, so the common questions are answered consistently without anyone re-deriving anything.
• Natural-language querying against the definitions — the stakeholder asks "what was NRR last quarter?" and the system answers using the defined logic, not an improvised join. This is where a good NL→SQL layer earns its keep: the value isn't translating English to SQL (that's easy now), it's translating English to your SQL — the definition you agreed on. Show the generated SQL so humans can verify; flag uncertainty for high-stakes calls.

The honest tradeoff: a hand-built governed model always returns the exact right answer because the logic is fixed; an AI interpreting a question can misread ambiguity. That's exactly why the written definition matters — it shrinks the ambiguity the AI has to guess at.

Step 5: Fight drift, because your definitions will rot

This is the step everyone skips and everyone regrets. The moment you ship your definitions, they start going stale:

• Someone renames a column in Salesforce. Your logic now points at a field that doesn't exist.
• Finance changes how they recognize revenue. Your definition is now confidently wrong — the worst kind, because it still runs.
• A new pricing tier appears and no definition accounts for it.

An enterprise CIO said it cleanly: "Static ontologies are dead on arrival. The model updates once a quarter and it's stale before it ships." Even the big platforms admit their curated context doesn't auto-update when the business changes — a human still has to.

So build a maintenance loop, not a one-time document:

1. Assign every metric an owner (you did this in Step 2). No owner, no trust.
2. Review on a cadence — a monthly 30-minute "definitions review" beats an annual rewrite.
3. Detect upstream changes automatically. This is the highest-leverage move: watch the schemas and pipelines your definitions depend on, and get alerted when something changes underneath them. Schema-drift detection and event-driven triggers turn "we found out the number was wrong in the board meeting" into "we got a Slack alert the morning the field changed." (Note: that's column/type drift on the data side — distinct from definition drift, but the two travel together. We go deeper in how to monitor schema drift in BigQuery.)

A definition that tells you when it's going stale is worth ten definitions that silently rot.

The 5-step checklist

1. Inventory the 15–25 metrics people actually fight about.
2. Write each as a spec: name + aliases, meaning, exact logic, edge cases, owner.
3. Store it where humans and agents both read it — matched to your enforcement needs.
4. Connect definitions to how people ask (governed surfaces + NL querying against the defined logic).
5. Defend against drift — owners, a review cadence, and automated alerts on upstream changes.

Do this and the board meeting goes back to being about the business.

Where Fastero fits

We built Fastero for step 3-through-5 without the six-month project: define your key metrics on a connected warehouse, let your team ask questions in plain English against those definitions, and get event-driven alerts when the data underneath a definition drifts. It's the lightweight version that keeps definitions honest — and most teams under 50 people never need anything heavier. The full breakdown is on the metrics & semantic layer capability page, and the tool shortlist is in the best semantic layer tools of 2026.

Ready to define your metrics once and get alerted when they drift?

👉 Start your free 30-day trial (no credit card required)

Or read the cautionary tale first: the metric definition that nearly made us celebrate a fake 100% activation rate.

Last updated: July 2026.