“Everyone wants a single source of truth - until it doesn’t tell the truth they need.”
I’ve built data teams for more than 40 companies - from nimble startups to sprawling multinationals - and I’ve always seen the same tension surface.
No matter the company size, the industry, or the level of maturity, the conversation eventually circles back to surprisingly basic questions:
What is a customer?
What exactly is revenue?
You’d expect alignment on such foundational metrics, but it’s rarely there. And that’s where things get messy.
This newsletter is here to open up the conversation about the single source of truth (SSOT) - not to settle the debate, but to reframe it. What if we stopped thinking in absolutes? What if there’s a way to support both consistency and flexibility?
Why This Matters
If you’ve been working in data long enough, you’ve likely been caught in this crossfire:
- Some people (often data folks and finance departments) strongly advocate for a single source of truth: a consistent, governed set of metrics everyone can trust.
- Other people (often marketing, product, and sales teams) push for flexibility: different metrics for different use cases, even if they look similar.
And here’s the challenge: both sides are right, in their context.
That’s why this discussion matters. Rigid governance without flexibility leads to shadow reporting and mistrust. But uncontrolled flexibility leads to chaos and misalignment.
So let’s unpack this. Not with dogma, but with nuance - and a practical framework you can actually use.
The Problem: Everyone Thinks Their Metric Is “The Real One”
Let’s start with the question: why do different teams end up with different definitions of the same metric?
The common answer is miscommunication, or siloed data sources. But the deeper answer is this: metrics depend on perspective.
Take the example of revenue. It's simple, right? But is it?
Let’s break it down.
What a Metric Really Is
A metric isn’t just a number. It’s a combination of:
- Measure: What are you adding up or counting?
- Filter: What are you including or excluding?
- Dimension: How are you breaking it down?
That’s where complexity starts.
Let’s look at a real-world example to make this concrete.
Real-World Example: Revenue in E-Commerce
Imagine you work for an e-commerce company that sells physical products. Different teams want to report on revenue:
- The measure is straightforward:
price x quantity = turnover.
- But then come the filters: → Should we exclude test orders? → Should we exclude items such as plastic bags?
- Now add the dimension: → Marketing wants revenue by order date. → Finance wants it by invoice date. → These dates might match, but often don’t.
And it gets trickier:
- What about returns? → Do you reduce revenue on the return date? → Or the date the refund was issued? → Or when the goods arrived back?
Now add forecasting:
- Marketing might want projected revenue after returns to plan campaign spend.
- But Finance only wants actualized figures, not estimates.
So now we have:
- Gross revenue (order date)
- Net revenue (after returns, return date)
- Projected net revenue (projected return rate)
- Invoiced revenue (invoice date)
All of these are technically “revenue”, but they serve very different purposes.
The Solution: A More Nuanced Truth
In my experience a too rigid governance approach to a single source of truth leads to uphill battles that are completely unnecessary.
Here’s the mindset shift:
You don’t need a single metric. You need a single foundation.
In other words:
- There should be one authoritative source of measures, filters, and dimensions.
- But from that, you can create multiple valid metrics, each clearly defined and use-case specific.
This is how you create alignment without rigidity.
Let’s explore the two helpful tools and frameworks to do this in practice.
Framework 1: The KPI Dimension Map
The KPI Dimension Map is a simple but powerful tool: a cross-table that shows which combinations of measures, dimensions, and filters make up which metrics.
Why it works:
- It makes differences explicit instead of hidden.
- It gives teams a shared language to talk about metrics.
- It prevents misinterpretation of dashboards and KPIs
Note: I should actually rename this to Measure / Dimension Map.
Framework 2: Layered Data Architecture
Your data model in your data warehouse should make the distinction between measures and metrics possible. I documented this here .
In short:
- Core Layer:
- Clean, validated data.
- Consistent measures, filters, dimensions.
- This is your single source of truth.
- Data Marts Layer:
- Team-specific, use-case-driven combinations of core elements.
- Marketing, finance, product each get their own curated views.
- All metrics trace back to the same core definitions.
This layered approach lets you:
- Maintain governance and data quality.
- Support the flexibility teams need to operate effectively.
- Prevent duplication of logic and inconsistencies.
Bonus tip: Keep naming conventions clear. If there are five “revenue” metrics, name them explicitly. Avoid ambiguity at all costs. And keep it as simple as possible.
Bottom Line: Govern the Building Blocks, Not the Views
The debate about a single source of truth isn’t about whether you should have one version of a metric. It’s about whether you can trust the foundations.
So here’s the approach that works for me:
- Build one consistent foundation of measures, filters, and dimensions.
- Allow multiple named, documented variations of metrics derived from that foundation.
- Make them discoverable, explainable, and traceable.
That’s how you bridge the gap between governance and flexibility.
Because in the end, alignment isn’t about forcing everyone to see things the same way. It’s about making sure everyone understands why they see things differently and agreeing on the language to describe it.
Take this back to your team:
- Build your KPI dimension map.
- Audit your data warehouse layers.
- Start labeling your metrics with clarity and intent.
Let your truth be structured but not singular.
Cheers,
Sebastian
