Skip to content
Rosera Rosera Technologies, home
Service

Analytics and BI

We give each metric one definition. It is enforced in the layer that every report queries through, and the scope runs from the semantic layer through Power BI and Tableau delivery to embedded and multi-tenant reporting.

The problem

Every team has its own definition of revenue, so every meeting starts by arguing about whose number is right instead of what to do about it.

Metric divergence is a structural problem. When each dashboard carries its own copy of the calculation, the definitions drift as soon as one team's requirement changes, and nothing in the tooling records that it has happened. Writing a policy over the top leaves the definitions in the same editable places, and they carry on drifting.

Our approach

We move metric definitions into a layer that every consumer reads through, then rebuild the reporting against it. A definition then changes in one place. Every report that reads through the layer picks the change up without being edited.

  1. 01

    Metric inventory

    We collect the definitions currently in use, including the contradictory ones, and get a named owner to agree on a single version of each. Most of this is negotiation between teams. It normally takes longer than building the model that follows.

  2. 02

    Semantic model

    Conformed dimensions and facts are built at a stated grain, with each metric defined once. The grain is written down for every fact table, because ambiguity there is the most common cause of a metric that cannot be reconciled.

  3. 03

    Report rebuild

    We rebuild reports against the semantic model. Repointing an existing report at it is not enough, because the report keeps its own copy of the logic and the divergence comes back within a quarter or two.

  4. 04

    Access and distribution

    Row-level security is carried through from the platform to the reporting tool, so a user sees the same slice of data whichever route they take to it. For embedded and multi-tenant work, the tenant boundary is part of the design from the start.

How it fits together

Metric definitions before and after a semantic layerOn the left, three reporting tools each query the warehouse directly and each carries its own copy of the revenue calculation, so the three definitions drift apart. On the right, the same three tools resolve through a single semantic layer that defines the metric once over conformed dimensions and facts, so every tool returns the same number.Power BITableauNotebooksWarehousePower BITableauNotebooksSemantic layerWarehouseWITHOUTWITHthree definitions of revenuedefined onceone definition, one owner
The same three tools, before and after. On the right the metric is defined once and every tool resolves through it.

What you get

  • Agreed metric definitions with a named owner for each
  • Semantic model with documented grain for every fact and conformed dimensions
  • Rebuilt reports and dashboards in your BI platform
  • Row-level security implementation, with a test matrix showing each role sees only its own data
  • Report performance review with the query patterns that were costing the most
  • Training session and documentation for report authors

Technology

BI platforms

  • Power BI
  • Tableau
  • Looker
  • Sigma
  • Streamlit

Semantic layer

  • dbt Semantic Layer
  • Power BI semantic models
  • Cube
  • AtScale

Platform

  • Snowflake
  • Databricks SQL
  • Microsoft Fabric

Engagement

Duration
Eight to eighteen weeks, driven mostly by how many reports are in scope and how contested the definitions are
Team
An analytics engineer, a BI developer and a lead who runs the definition workshops
Starts with
We begin with a reconciliation exercise on a small number of contested measures. It puts a figure on the divergence, and that figure usually settles the argument about scope.

The first stage is short, and you can stop after it if the findings do not justify going further.

Start a conversation

Next service

05

AI and Machine Learning

Read more
All services