Self-service BI and governed metrics: why are your users calculating different revenue figures?

You've deployed a modern BI tool. Trained your teams. Opened access to data. Six months later, three departments present three different revenue figures at the board meeting. Nobody knows which one is correct. The problem isn't the tool, nor the quality of your source data. It's the absence of governed metrics and structured BI governance.

Self-service BI promised autonomy and responsiveness. It often delivers chaos and distrust. In 2025, we're seeing a turning point: organizations that successfully transform their data don't just open access to data anymore. They architect how that data is understood, calculated, and used through governed metrics.

The self-service BI paradox without governance

The self-service BI idea is appealing. Rather than centralizing all report production within an overwhelmed analytics team, you empower business units to build their own analyses. You gain agility, reduce turnaround times, and free up time for your data team.

In practice, this autonomy quickly reveals its limits. A controller calculates margins one way, the sales director another. Marketing measures conversion rates by including qualified prospects, while sales only counts created opportunities. Each business unit rebuilds its own definition of key indicators, generating exactly the cosmetic reporting syndrome.

The result is predictable: meetings where more time is spent debating calculation methodology than analyzing results. Progressive loss of trust in the numbers. Strategic decisions made on shaky ground because nobody really knows which version of the truth to rely on.

This fragmentation isn't a technical problem. It's an organizational problem that requires a structural solution. You can't hand over the car keys without first establishing the rules of the road.

The semantic layer: a layer of meaning between data and visualization

The semantic layer isn't a new concept, but it's experiencing marked renewed interest in 2025. The idea is simple: rather than letting each user interpret and calculate metrics their own way, you define once and for all how they should be constructed according to a metric as code logic.

Concretely, this is an intermediate layer that abstracts the technical complexity of data and exposes standardized business concepts. When a user wants to display revenue, they no longer compose the query themselves by juggling with order tables, invoice line items, and discounts. They select the "Revenue" metric, which already embeds all validated calculation logic.

This approach fundamentally transforms the relationship between users and data. We move from a model where everyone must understand the database schema and business rules, to one where business concepts are first-class objects, documented, maintained, and governed. This is precisely what the semantic layer enables: preventing analytical interpretation divergences.

Modern tools like dbt with its metrics, Cube, LookML, or semantic layers built into cloud platforms make this vision concrete. But the tool is just the implementation. The real work lies in collectively defining what "an active customer" means, what constitutes "a qualified lead," or what defines "a transaction." This exercise often reveals unsuspected comprehension gaps between teams.

Context engineering: beyond definition

Defining a metric isn't enough. You must also document its usage context, limitations, and evolution. This is what we call context engineering—an emerging discipline that considers a data point's value to reside as much in its intrinsic quality as in the richness of the context surrounding it.

Take a concrete example. Your "Customer Retention Rate" metric can be calculated over different periods, with or without inactive customers, including or excluding certain segments. Without explicit context, two analysts will use this metric with different parameters and reach opposite conclusions.

Context engineering addresses this by associating each metric with living documentation that specifies recommended use cases, pitfalls to avoid, historical definition changes, and dependencies with other metrics. This approach transforms your metric catalog into a genuine organizational knowledge base.

The 2026 analytics engineer becomes an architect of meaning

This evolution in practices fundamentally redefines the analytics engineer role. Historically focused on data transformation and dimensional model building, this profession is gradually shifting toward architecture and BI governance.

The 2026 analytics engineer no longer merely produces aggregated tables. They design coherent governed metric systems, define semantic modeling standards, and facilitate workshops with business units to align definitions. They become the guarantor of the organization's analytical consistency.

This shift in approach requires different skills. Less focus on optimizing complex SQL queries, more capacity to facilitate stakeholder consensus. Less time debugging data pipelines, more time invested in documentation and training. The analytics engineer becomes a translator between the technical world and business needs, avoiding the classic mistakes analytics leaders make.

This transition isn't straightforward. It requires stepping out of your technical comfort zone to develop communication, pedagogy, and facilitation skills. But that's precisely where the added value lies: not in the ability to write efficient code, but in structuring an organization's collective knowledge.

The most mature organizations are beginning to create dedicated roles, sometimes called "metric owners" or "semantic architects," specifically tasked with maintaining and evolving the metrics reference framework. It's no longer a side task for the data team—it's a standalone function.

Implementation: where to start with governed metrics?

Setting up metric governance doesn't happen overnight. You need to accept a gradual transition, starting with the most critical indicators and those most prone to interpretation divergence.

The first step is identifying these fundamental metrics. What are the ten indicators that come up in every strategic meeting? Which ones feed regular reporting? Which ones drive investment decisions? Start with those, not with exhaustiveness.

Next, organize workshops with stakeholders to align definitions. This is often a revealing exercise. What seemed obvious to each person in their silo turns out to be subject to interpretation once you confront perspectives. The goal isn't to impose a definition by decree, but to collectively build documented consensus.

Once definitions are stable, implement them in your semantic layer. Test with a pilot group of users before rolling out broadly. Measure adoption, gather feedback, adjust. Metrics governance isn't a project with an end date—it's a continuous process that evolves with your organization.

Document systematically. Each metric must have an owner, a business definition, technical calculation logic, and recommended use cases. This documentation must be accessible, searchable, and maintained. A poorly documented metric catalog is worse than no catalog at all—it creates the illusion of governance without delivering its benefits.

Toward truly autonomous BI through governed metrics

Metrics governance doesn't oppose self-service BI. It makes it possible. Without it, self-service creates anarchy. With it, it genuinely unlocks business teams' autonomy potential.

Organizations investing in this semantic infrastructure observe concrete gains. Drastic reduction in time spent reconciling numbers. Accelerated decision-making through restored data trust. Faster onboarding of new hires who have a clear reference framework.

In 2025, the difference between data-driven enterprises and others won't come down to the volume of data collected or the sophistication of visualization tools. It will hinge on the quality of the semantic architecture that structures the relationship between humans and data. Those who invest in this layer of meaning, in this patient work of alignment and documentation, will create lasting competitive advantage. The others will continue debating the right way to calculate revenue.