Metrics Locked Inside BI Tools
George Xing, co-founder and CEO of Supergrain, on the future of business intelligence
Keeping metric definitions inside one BI product turns the BI layer into the company’s hidden control plane. Revenue, conversion, and retention look like simple numbers on a dashboard, but in practice they are SQL rules embedded in Looker models, Tableau workbooks, or even individual charts. Once teams start reading data in spreadsheets, planning tools, notebooks, and product apps, those rules split apart and the same business can end up with several incompatible versions of the same number.
-
This happens because BI tools usually compute metrics at query time. A dashboard does not just read a fixed revenue table, it often runs logic that joins raw tables, filters edge cases, and aggregates results. If another team rebuilds that logic in a second tool, drift starts immediately.
-
The warehouse alone does not fully solve it. Precomputing one revenue table locks in one grain, like daily by product or weekly by city. As soon as finance wants monthly views and product wants cohort views, teams make new tables or ad hoc SQL and the duplication returns.
-
That is why the modern data stack has pushed business logic down toward a shared semantic layer near transformation tools like dbt. The goal is to define a metric once, then let BI dashboards, notebooks, catalogs, and operational apps all call the same definition instead of rewriting it in each interface.
The next phase of BI is less about prettier dashboards and more about moving metric logic out of any single front end. As analytics spreads into planning software, reverse ETL, AI copilots, and customer facing apps, the winning stack will be the one that makes the same metric definition portable across every surface where a decision gets made.