Platform

Why Warehouse-Native Metric Definitions Still Drift

Databricks Genie answers net revenue retention at 112% every time, and the CFO's Power BI board report says 108%. Why do metric definitions keep drifting after a team moves them into the warehouse, and what fixes them across every platform?

Mike Hetrick

Director, Product Marketing

The data team spent the third quarter moving its core metrics into Databricks Metric Views. Genie went live on top of them in September, and for the first time the AI answers held still: ask for net revenue retention five ways and you get 112% five times.

Then the CFO opened the Power BI board report. It says 108%.

Power BI didn’t read the Metric View. Its semantic model carries its own net revenue retention measure, written in DAX in 2023, and that measure counts downgrades a different way.

Defining metrics in the warehouse is the right first move

The team did what practitioners now recommend to each other. In an r/analytics thread about agent-written SQL, replies point to defining the metric, its joins, and its filters inside the warehouse in Databricks Metric Views, and r/snowflake practitioners are weighing the same move with Snowflake Semantic Views. Either way, the agent reads a governed definition in place of raw tables.

It works for the agent. The poster of an r/databricks thread on Genie put the problem it solves in one line: "if the same business term means different things to different teams, how do you make sure Genie understands what you actually mean". A Metric View gives Genie one answer to that question.

Version control and deployment pipelines for these definitions are arriving inside the warehouse too. Inside one platform, the metric now has an owner, a history, and a test.

Every platform that computes the metric keeps its own copy

The trouble starts at the platform boundary.

A Power BI semantic model computes its measures in DAX. A Tableau workbook computes its calculated fields in its own logical model. Neither one inherits a definition from the warehouse just because it queries the same tables.

So the Metric View becomes one more copy of net revenue retention. The finance team's copy lives in Power BI, the field teams' copy lives in Tableau, and a third team may already be building Snowflake Semantic Views for a Cortex Analyst pilot. Each copy gets its own owner and its own release schedule, and someone keeps them in step by hand.

In practice, the week before each board meeting goes to that work. Someone pulls the Power BI number, the Tableau number, and the Genie answer, finds the gap, and writes a footnote explaining it. The footnote ends up as the only place the difference is written down.

Each copy carries assumptions no one wrote down

The copies drift because the logic was never the only thing being copied. Net revenue retention depends on choices that rarely appear in any definition: whether downgrades count against the cohort, when the fiscal year starts, whether test accounts and internal tenants are excluded, which exchange rate converts the international book.

Whoever rewrites the metric for a new platform makes those choices again. The 2023 DAX measure treats a downgrade as partial churn; the Metric View, written this summer by a different engineer, nets it against expansion. Both definitions are reasonable, both are documented somewhere, and they produce numbers four points apart.

A definition also stops short of where its rows came from. An r/dataengineering thread on text-to-SQL raised that limit: a definition settles what a metric means, and the soundness of the rows behind it is a separate question. Lineage answers that one, by tracing the inputs back to the tables finance reconciles at close.

Before Genie, Cortex Analyst, or any other assistant goes into production, someone should be able to answer a short set of questions for every metric it will touch. Which definition is authoritative? How many copies of it exist, and in which platforms?

Can you trace each copy to its source columns? And do the platforms that report the metric actually compute that authoritative definition, or a local rewrite of it?

Documentation describes what should be true. Compilation makes it true. If the answers come from a spreadsheet someone maintains by hand, the agent and the board report will keep disagreeing.

One governed definition, compiled into every platform that reports it

Warehouse-native definitions fix the metric for one platform. The estate needs one definition that every platform computes, with the assumptions written into it once.

MetaKarta starts with the copies you already have. Parser-based lineage traces each version of a metric column by column, from the source tables to the DAX measure and the Tableau calculation, so you can see exactly where the definitions split. A definition you can't trace is a definition you can't trust.

The catalog puts that lineage beside the definition wherever an analyst or an agent looks it up, with the owner and description attached, so whoever asks which net revenue retention to use gets an answer and its source together.

Governance versions the one definition your teams agree on and records who changed it and when. The audit answer is a query.

Semantic Hub then imports the semantic models you already run in Power BI and Tableau and compiles the governed definition natively into Databricks Metric Views, Snowflake Semantic Views, Power BI semantic models, and Tableau logical models. Genie, Cortex Analyst, and the board pack all read the same compiled definition.

When the next platform arrives, the definition compiles into it from the same source. For the broader case on why fragmented metadata stalls AI projects, read Your AI Initiative Has a Metadata Problem.

Get in touch to learn more about how MetaKarta compiles one governed metric definition into Databricks Metric Views, Snowflake Semantic Views, Power BI, and Tableau at the same time.

‍