It starts innocently. Your CEO pulls a revenue number from Stripe. Your head of sales calculates revenue from the CRM. Your finance lead uses the accounting system. Three numbers, three answers, one uncomfortable meeting.

“Which number is right?”

This question is asked in startups every single day. And the answer is almost always: they’re all “right” by their own definition, but nobody agreed on what the definition should be.

This is the metric definition problem, and it’s one of the most common — and most damaging — data issues startups face.

How Metrics Diverge

Metric definitions drift apart naturally. It’s rarely anyone’s fault. Here’s how it happens:

Different Data Sources

Stripe reports gross revenue including tax. Your database records net revenue after discounts. Your accounting tool uses accrual-based revenue recognition. Each is a valid number, but they measure different things.

Implicit Assumptions

One person filters out refunds when calculating revenue. Another doesn’t. One person excludes trial accounts from “active users.” Another includes them. These assumptions are rarely written down — they live in someone’s head or buried in a SQL query.

Context Drift

A metric that made sense six months ago may not make sense today. Your definition of “monthly active user” was set when you had one product. Now you have three. Does a user who’s active in one product count? What about users who only use the free tier?

Tool-Specific Quirks

Google Analytics calculates “sessions” differently from your product analytics tool. Stripe’s MRR calculation may differ from how your investors define MRR. Each tool has its own methodology, and nobody notices until the numbers don’t match.

Why This Matters

Eroded Trust

When different people present different numbers in the same meeting, trust in data evaporates. Stakeholders stop relying on data for decisions and fall back on intuition. You’ve lost one of the biggest advantages a data-rich startup has.

Wasted Time

Hours are spent every week reconciling numbers, debugging discrepancies, and arguing about whose query is correct. This is pure overhead that produces no insight.

Bad Decisions

If “customer churn” means something different to the CEO and the product team, they might make opposite decisions based on the same underlying reality. One sees a problem, the other doesn’t — because they’re not measuring the same thing.

Scaling Problems

When you’re five people, you can resolve metric disagreements with a conversation. When you’re fifty, you can’t. The confusion compounds as the company grows.

How to Fix It

1. Write Down Every Definition

This is the most important step and the one most startups skip. For every metric your company tracks, write down:

The name — “Monthly Recurring Revenue (MRR)”
The exact calculation — “Sum of all active subscription amounts, excluding annual contracts prorated monthly, excluding free trials, after discounts but before tax”
What to exclude — “Exclude refunded subscriptions, internal test accounts, and partner accounts”
The data source — “Calculated from the subscriptions table, using amount_after_discount column”
Who owns it — The person responsible for this definition being correct

2. Store Definitions in One Place

A Google Doc works for a seed-stage startup. But as you grow, you need these definitions encoded somewhere they’re actually enforced — not just documented.

This is what a semantic layer does. It stores your metric definitions in a structured format that your querying tools can use. When someone asks “What’s our MRR?”, the definition is applied automatically, not re-interpreted by whoever writes the query.

3. Make It the Only Path

Definitions only work if they’re actually used. If people can still write ad-hoc queries that bypass your definitions, they will — not out of malice, but out of convenience.

The goal is to make the defined metrics the easiest path to answers. If your analytics tool automatically applies your definitions, people will naturally use them instead of writing one-off queries.

4. Review and Update Regularly

Business logic changes. New products launch, pricing models shift, customer segments evolve. Schedule a quarterly review of your metric definitions to make sure they still reflect reality.

The Semantic Layer Connection

A semantic layer is, at its core, a system for encoding and enforcing metric definitions. When properly configured, it ensures that:

“Revenue” always means the same thing, no matter who’s asking
Business rules (exclude test accounts, apply currency conversion) are applied automatically
Table relationships and join conditions are pre-defined and consistent
New questions get the same level of accuracy as your most carefully crafted query

For startups, the challenge is that building and maintaining a semantic layer requires data engineering expertise. Traditional tools like Looker’s LookML or dbt’s metrics layer are powerful but require dedicated technical resources.

Sovarium takes a different approach: our data experts configure your semantic layer during onboarding. We work with your team to understand your business definitions, then encode them so the AI applies them automatically to every query.

The result is that every person on your team, regardless of technical ability, gets the same consistent answer to the same question. No more “which number is right?” meetings.

Start Small

You don’t need to define every possible metric on day one. Start with the metrics that cause the most confusion — usually revenue, active users, and churn. Get agreement on those definitions, encode them somewhere enforceable, and expand from there.

The cost of getting this right is small. The cost of getting it wrong — eroded trust, wasted time, bad decisions — compounds every day.

Want to see how Sovarium encodes your metric definitions into a working semantic layer? Get in touch to learn more.

Why Every Metric Needs a Single Definition