Business technology
A beautiful dashboard still fails when metric definitions disagree
Define metric contracts, data models, time dimensions and change governance before building management charts.
Two dashboards can show different Revenue from the same database because one uses invoice value before returns while another subtracts credit notes or groups by a different date. Without a metric contract, teams debate the number instead of deciding from it.
This article presents Linda management-information design guidance using Metabase documentation as an example of semantic models and reusable metrics. It does not require every customer to use Metabase.
Write a metric contract before building the card
For each important number, record the business name, definition, formula, source, date field, exclusions, unit and accountable owner. “Net Sales”, for example, should state treatment of returns, discounts, tax, channels and whether grouping uses order, invoice or payment date.
Metabase describes Metrics as the official way to calculate important numbers, with reusable formulas intended to avoid multiple competing Revenue calculations. That directly illustrates the value of a metric contract.
References: [1]
Separate the data model from the visualisation
If every chart repeats joins between customers, invoices, channels and branches, move the business logic into a curated data layer and let charts read from that layer. Definition changes then have a controlled location instead of being copied across cards.
Metabase Models curate data from tables or queries, add metadata and derived columns, and provide a reusable starting point for exploration. The same principle can reduce duplicated dashboard logic while still requiring governance over which model is authoritative.
References: [2]
The same month can mean several different dates
September sales can be grouped by order date, invoice date, delivery date or payment date. Each answers a different question. If the dashboard hides the time dimension, users may compare unlike metrics and conclude that the system is wrong.
Define the default time dimension in the metric contract and expose filters that change meaning. When several timelines are useful, name the metrics clearly instead of reusing one generic Revenue label for every timeline.
Important totals should drill back to transactions
Management needs summary, but unusual values should have a path back to source transactions or exceptions. A chart without lineage sends people into several systems merely to prove the number.
Preserve stable IDs and references from operational source through the analytics layer. When data is aggregated, retain enough join or snapshot logic to trace it to the level the business requires.
Changing a metric formula changes the meaning of reports
Record the reason, effective date, approver and affected dashboards when a definition changes. Do not silently change a central formula and allow history to shift without communication. If history is restated, explain which periods were recalculated.
Metabase notes that editing a metric definition causes questions using that metric to immediately use the new definition. This is why metric management is a governance issue, not merely chart configuration.
References: [1]
A practical starting checklist
- Define formula, source, time dimension and owner for important metrics.
- Put shared business logic in a curated analytics/model layer.
- Use distinct names when timelines or scope differ.
- Provide drill-through to transactions or exceptions.
- Maintain change history and impact review for metric definitions.
Apply it to your business
A useful dashboard is not the one with the most charts. It is the one where people understand the numbers consistently, know their sources and can trace unexpected results.
References
- Metabase. (n.d.). Metrics. Retrieved October 1, 2026.
- Metabase. (n.d.). Models. Retrieved October 1, 2026.
Numbered references support the attributed statements. Scenarios and recommendations are Linda’s examples, not verified client outcomes.
This article provides process-design guidance and illustrative examples, not an accounting, tax or legal determination or certification of every software module. Apply it with regard to your business, permissions and actual system scope.