Your metrics layer is not the problem. Your data model is.
by Raphael Steinman
Every year a new tool promises to finally solve the metrics problem. Looker. dbt metrics. Cube. Whoever is next. They are all good. None of them fix the actual issue.
Here is a test. Hire a brilliant analyst tomorrow. Give them access to the same data your metrics layer sits on. No onboarding. No Slack access. No “ask Sarah, she knows how that field works.”
Can they define “recognized revenue” by end of day?
In most companies, the answer is no. Not because the analyst lacks skill. Because the CRM says one thing about the customer, the ERP says another, and the billing system tells a third story. The process logic that reconciles them lives in someone’s head. The entity relationships are unresolved. The temporal ordering is ambiguous.
A metrics layer standardizes how you read data. It cannot fix what the data says. It is a translation guide stapled on top of unresolved raw material.
This is why the Slack fights never end. Teams think they are arguing about metric definitions. They are actually arguing about what happened; which version of the customer is real, which transaction sequence is authoritative, which business rule applies.
The metric disagreement is a symptom. The modeling gap is the disease.
When the underlying activities are resolved; harmonized entities, explicit process context, clear temporal order; definitions become surprisingly uncontroversial. People stop fighting about what “revenue” means when the evidence underneath is unambiguous.
The industry keeps building better lenses to look at the data. Nobody is fixing what the lenses are pointed at.
That is the problem. And no amount of governance workflows, approval chains, or organizational redesign will solve a structural gap in the foundation.
If your analyst cannot reason from the data alone, neither can your metrics layer.
Neither can your LLM.
Neither can your agents.
The tool is never the constraint.
The model underneath is.
