Grounded in: r/BusinessIntelligence, "The biggest data problem I keep running into isn't dirty data. It's teams defining the same metric differently." (212 upvotes, 102 comments), with direct quotes from OP sdhilip and commenter AyrielTheNorse
A data consultant named sdhilip got called in to fix a client's data model. Snowflake, clean pipelines, no pipeline issues anywhere. Then he put two dashboards side by side and revenue didn't match. Not close. Turns out two analysts had written two different calculations for "Revenue." One counted gross revenue, the total order amount. The other counted net revenue, order amount minus returns. Both named the metric "Revenue." Both were right. Neither had ever agreed with the other on what the word meant.
He'd seen the same thing everywhere he consulted, not as an edge case but as the default state: "Active Customers" meaning logged-in-in-30-days on one team and purchased-in-90-days on another, same metric name, completely different numbers. "Churn Rate" calculated monthly by finance off cancellations and calculated by product off 60-day inactivity, so the CEO gets two different churn numbers in the same board meeting. "MRR" that includes day-one trial conversions in one report and only counts them after the trial ends in another, argued over by finance and sales every quarter.
The thread's top reply, from someone who introduces new hires to this problem on day one, put the real question underneath all of it plainly: "How many customers do we have?" sounds like the simplest question in the world, until you ask what counts as a customer, and the room goes quiet. Signed up? Paid? Active subscription? Free trial? Churned-and-came-back? Nobody's being difficult. They just never had a reason to find out everyone didn't already agree, until someone asked.
That reply also named the actual fix, and it isn't a tooling upgrade: "the hard part isn't the tech, it's getting people in a room to agree on what their own business terms mean." A second highly-upvoted comment made the ownership model explicit with a public-sector example: one agency owns how a metric is counted, other departments that use it don't get to silently redefine it, and if someone wants to change the counting rule, they have to go back to the owning agency and get agreement first. "It's fine to calculate and store them centrally, but if someone wants to change how it's counted, they need to shake hands with the owner."
That's the missing layer at most companies with a perfectly good BI stack. The tools are fine. Snowflake, dbt, Looker, Power BI, none of them are the problem in that thread, and none of them fix it either, because a dashboard tool has no opinion on whether "Active Customer" means logged-in or purchased. It will happily chart either one, correctly, forever, with no warning that a second "Active Customer" exists three tabs over defined the opposite way.
What has to exist instead is somewhere a metric gets defined exactly once, the filters, the joins, the as-of logic, the owner who's allowed to change it, and everywhere else that references "Active Customers" points back to that single definition instead of quietly reimplementing it. That's not a new dashboard. It's closer to what the OP was circling with "classic semantic layer problem," except the missing piece usually isn't the layer itself. Usually nobody assigned an owner to each metric the way the tax-agency example did, so a second, equally reasonable definition has nowhere to collide with the first one before it ships to a board deck.
The tell that this is happening at your company isn't a broken chart. It's the meeting where two correct-looking numbers show up for the same metric name and everyone quietly assumes someone else made an error. Nobody did. The fix isn't a debugging session. It's a five-minute lookup, whose definition is this, and does the other team's number use it, and that lookup only exists if a metric has exactly one owner and one place it's defined, not two teams who each built their own "Revenue" and never had a reason to compare notes.