Most teams buy a semantic layer the way they buy a data warehouse. Tool first, problem retrofitted.
Six months in, nobody’s onboarded their metrics, and the BI tool still ships the same conflicting dashboards.
Here’s the decision tree I actually use.
One BI tool, one analytics team, under 50 dashboard users? You probably don’t need one yet. Define metrics in dbt, document them in a markdown file, move on.
Multiple BI tools (Looker for ops, Tableau for finance, a notebook somewhere for the data scientist)? Now you need a semantic layer. The cost of three diverging metric definitions outweighs the implementation effort.
Two teams defining “revenue” differently and both technically correct (one excludes refunds, the other excludes deferred contracts)? That’s the trigger. Not tool count. Not dashboard count. Definition drift with stakes attached.
A semantic layer exposes metric chaos before it fixes it. If your finance and ops teams have never agreed on “active customer,” the tool forces that fight earlier. Plan for it.
Cheaper first step: write down your top 10 metrics, get the owners in a room, agree on definitions. If the conversation goes smoothly, you don’t need the tool. If it goes badly, you’ve found your business case.
Does your company have one definition of “revenue” - or three?