Glossary
What is a metric definition?
A metric definition is a documented, executable specification of a business metric. It establishes how the metric is calculated, which records qualify, what the time boundaries are, and who owns it. The same definition is read by every report, integration, and AI tool that uses the metric.
Take "active customer." A useful metric definition for this term names the qualifying conditions explicitly: account status equals active, a purchase has occurred in the last twelve months, no termination notice is on file. It names the time window. It names an owner. Without that specification, Sales counts active customers one way, Marketing another, and Finance a third.
Why metric definitions matter
When teams calculate the same metric differently, Sales, Marketing, and Finance each report different numbers to leadership for what is supposedly the same question. The argument that follows is rarely about the data. The data is fine. The argument is about whose definition counts.
The cost shows up in three places. Decisions stall because nobody agrees which number is the right one. AI assistants give conflicting answers when asked the same question in different parts of the business. Audit conversations get stuck on which calculation applied at which point in time.
A captured metric definition removes the argument. The number is the number because the definition is the definition, written down, owned, versioned.
What a good metric definition includes
Three properties make a definition something every consumer can rely on.
Name and scope
A clear name and a plain-language description of what the metric counts. The business meaning sits next to the calculation, so a reader does not need to reverse engineer the SQL to understand the intent.
Qualifying conditions and time window
The exact criteria a record must meet. The time window the metric applies to. Edge-case decisions named, not left to the reader: how renewals count, how cancellations within the window behave, how partial periods are handled.
Ownership and version history
A named owner who can answer questions and approve changes. A version history that records when the definition changed and why, so reports from different periods can be compared against the right rule set.
Where metric definitions live
Historically, metric definitions are scattered. The most rigorous ones live in individual Excel models built by a finance analyst who knows the rules by heart. Others live in BI report filters, where a Power BI developer encoded the qualifying conditions inside a measure. Others live in ad-hoc SQL on someone's laptop. Most live nowhere at all and get reinvented on every request.
Effective governance puts metric definitions in one shared layer that every consumer reads. The same definition feeds the Power BI dashboard, the AI assistant, the partner API, and the marketing segmentation tool. There is one place to change a definition, and the change reaches every consumer at the same time.
That shared layer is the semantic data layer for the organisation. Metric definitions are one of the most important things it captures.
How dhino captures metric definitions
In dhino, a metric definition is captured as part of a data access template. The template names the metric, encodes the qualifying conditions and time window, and binds them to the underlying tables. Every consumer that wants the metric calls the template by name and gets the same answer.
A business user pulling a segment through Fetch, a Copilot agent asking through Trust, and a partner system reading the same metric through an API all read the same definition. The cross-department consistency scenario walks through this end to end.
Stop arguing about whose number is right
Bring us the metric your teams disagree on. We will walk through capturing one definition that every consumer reads.