Where Should Your Numbers Live? BI, Reverse ETL, and the Metrics Layer

Your numbers should live in one definition and travel everywhere else. Dashboards, operational tools, reverse ETL pipelines, Slack alerts, and AI agents all need the same metric, and the only durable way to stop each of them from computing it slightly differently is a shared metrics layer that every consumer reads from. The question is not BI versus reverse ETL. It is whether all of them inherit one definition or invent their own.

This is a post about where numbers live in 2026, why metrics now have to appear far beyond the dashboard, and what architecture keeps a single definition intact as it spreads across surfaces.

The same number, five places, five definitions

Pick any metric that matters to your business. Active accounts. Monthly recurring revenue. Net revenue retention. Now count where it shows up.

It is on an executive dashboard. It is in a churn-risk score that a reverse ETL job syncs back into your CRM so account managers see it. It is in a Slack message that posts every Monday morning. It is the number an AI assistant returns when someone asks "how are we doing on revenue this quarter." And it is embedded in a customer-facing usage report inside your own product.

That is one metric living in five places. The failure mode is not that any single surface is wrong. It is that each one was computed by a different person, in a different tool, against a slightly different slice of the data. The dashboard excludes trials. The CRM sync forgot to. The Slack bot uses last month's definition because nobody updated it. The AI agent wrote its own SQL on the fly. Five surfaces, five subtly different answers, and no way to tell which one the customer or the board is looking at.

This is the core problem of operational analytics in a mature data stack: metrics no longer stay inside the BI tool, and the more places they travel, the more chances there are for them to drift.

Reverse ETL and the rise of operational analytics

For most of BI's history, a metric's job ended at the dashboard. You computed it, you charted it, an executive looked at it. The number was a destination.

Reverse ETL changed that. Reverse ETL, sometimes called data activation, takes modeled data out of the warehouse and pushes it back into the operational tools where work actually happens: the CRM, the support desk, the marketing platform, the product itself. Suddenly a metric is not just something you look at on Monday. It is a field a salesperson sees on an account, a threshold that triggers an automated email, a number that drives a workflow.

Operational analytics is one of the defining shifts of the modern stack, and it raises the stakes for metric correctness dramatically. A wrong number on a dashboard is embarrassing. A wrong number activated into your CRM means account managers are calling the wrong customers, automations are firing on bad thresholds, and the error is now baked into operational decisions instead of sitting passively on a chart. When metrics drive action, drift stops being cosmetic and starts being expensive.

And reverse ETL is only one of the new destinations. The same forces send metrics into Slack notifications, into embedded customer dashboards, and, increasingly, into AI agents that answer questions in natural language. Every one of those is a consumer that needs the metric to mean exactly what it means everywhere else.

The metrics layer as the shared contract

If a metric now has to appear in five surfaces, the worst possible architecture is the one most teams drift into by accident: each surface computes the metric itself. The dashboard tool has its own definition. The reverse ETL job has a SQL query. The Slack bot has a script. The AI agent generates SQL ad hoc. There is no contract between them, so there is nothing keeping them aligned except discipline, and discipline does not survive contact with a growing team.

The alternative is a metrics layer that acts as a shared contract. You define the metric once, as a real, versioned object, and every consumer reads from that one definition instead of reimplementing it. This is the same headless principle we explored in headless BI explained: separate the definition of a metric from the surface that displays it, so the surface becomes interchangeable and the definition becomes canonical.

The contract framing matters. A contract is something multiple parties agree to and depend on. When MRR is defined in the metrics layer, the dashboard, the CRM sync, the Slack alert, and the AI agent are all parties to the same contract. None of them gets to quietly redefine MRR, because none of them owns the definition. They all consume it. That is the only thing that holds five surfaces to one number.

models:
  - name: subscriptions
    sql: SELECT * FROM analytics.subscriptions
    metrics:
      - name: mrr
        expression: "SUM(monthly_amount) FILTER (WHERE status = 'active' AND is_trial = false)"
        description: "Monthly recurring revenue, active paid subscriptions only"

That single definition is the contract. Everything downstream points at it.

Pushing governed metrics to where work happens

Defining the metric once is necessary but not sufficient. The metric also has to be reachable by every surface that needs it, including the operational ones. A definition that only the BI tool can read is not a shared contract; it is just the BI tool's private opinion.

The architecture that makes this work treats the metrics layer as a source, not a sink. The dashboard reads the metric. The reverse ETL pipeline reads the same metric when it decides what to sync into the CRM. The scheduled Slack alert reads the same metric. The AI agent, instead of inventing SQL, composes from the same governed metrics and dimensions. Each surface is a different rendering of one number, the way a code-defined semantic layer feeds Insights and dashboards without duplicating logic.

The practical payoff is that you change the definition in exactly one place. When finance decides MRR should exclude a particular discount, you edit the metric once, and the dashboard, the CRM field, the Monday Slack message, and the AI agent's answer all move together. There is no migration project to chase down every surface, because there is only one definition to change.

Avoiding a second source of truth

The trap to watch for is the well-intentioned shortcut that quietly creates a second source of truth. It usually looks reasonable in the moment. The reverse ETL tool has its own modeling feature, so someone defines MRR there "just for the sync." The Slack bot needs the number fast, so someone hardcodes a query. The AI agent is convenient, so it generates its own SQL because that is easier than wiring it to the metrics layer.

Each shortcut is locally sensible and globally corrosive. Every place a metric is independently defined is a place it can drift, silently, until two surfaces disagree in front of a customer. And the drift is invisible until it surfaces, because nothing alerts you that the Slack bot and the dashboard have diverged. You find out in a meeting.

The discipline is simple to state and hard to hold: no surface defines a metric it does not own. If a number needs to appear somewhere new, that surface consumes the existing definition. It does not get to write its own. A code-defined metrics layer makes the discipline enforceable because the definition lives in version control, gets reviewed in a pull request, and is the obvious thing to reference, the same way BI version control makes every other definition reviewable rather than ambient.

How Visivo keeps one definition

Visivo's answer is to make metrics, dimensions, and relations code-defined objects in your project, so there is exactly one place each number is defined and every consumer reads from it. Because the definitions are code, they live in version control, move through pull requests, and are reused across every Insight and dashboard rather than copied into each one.

That single definition is what travels. The same mrr metric that powers a dashboard is the same one composed into an Insight, the same one a colleague references when building a new view, and the same governed logic an AI workflow can compose from instead of guessing. You are not maintaining five definitions of one number across five tools. You are maintaining one, and pointing everything at it.

The shift in the modern stack is that numbers no longer live in one place. They live everywhere work happens. The architecture that survives that shift is the one where they are still defined in one place. If you want to see what a single, code-defined metrics layer looks like in practice, get started with a local project or browse the examples.

Previously in Visivo

This post extends a theme from the previous one. In give power users a SQL editor we argued that the curated layer and raw SQL should share one source of truth inside the tool. Here we pushed that further: the same metric should stay consistent not just across the SQL editor and the dashboard, but across every operational surface a number ever reaches.