Services Data Engineering Analytics Engineering Business Intelligence & Power BI AI & Analytics Training
Approach About Contact
Book a discovery call

Trust

Agree what a number means. Once.

"Revenue" means one thing to finance, another to sales and a third to the board deck. Analytics engineering is the discipline of settling that argument in the data itself — so every report, every team and every meeting works from the same definition.


01 What changes

The meeting stops being about whose figure is right.

This is the layer almost everybody skips. A business buys Power BI, connects it straight to source systems, and builds reports — each one carrying its own quiet interpretation of what counts as an active customer, when revenue is recognized, or which orders belong to which month.

Six months later there are fourteen reports, no two of which agree, and a growing suspicion that none of them can be trusted. The reports aren't the problem. The absence of a shared definition underneath them is.

Analytics engineering puts business logic in one place — versioned, documented and reused by everything downstream. Define a metric once and every report inherits it. Change it once and everything updates together. It is the least visible work we do and the single largest driver of whether people end up trusting the output.

02 What we build

From raw tables to business meaning

  • 01
    A dimensional model that matches your business
    Facts and dimensions built around how you actually operate — your hierarchies, your calendar, your definitions of a customer, product and site. Not a generic template bent to fit.
  • 02
    A KPI framework, written down
    Every metric with an owner, a plain-English definition, a formula and a grain. The conversation that surfaces this is often more valuable than the artefact itself.
  • 03
    A semantic model as the single source of truth
    One governed model that Power BI, Excel and anything else you connect all read from — so self-service can't quietly invent a fifth version of gross margin.
  • 04
    Business logic in code, not in reports
    Transformation rules that live in version control with tests around them, rather than being buried in a report filter that nobody remembers setting.
  • 05
    Governance proportionate to your size
    Access, certification, naming and change control that a team of three can genuinely maintain. Governance that gets ignored is worse than none at all.

03 For the technical reader

Modeling decisions and why we make them

The choices in this layer are the ones you live with longest. Here's how we think about them.

  • Star schema
  • Kimball
  • Semantic models
  • DAX
  • Tabular
  • T-SQL
  • Views & procs
  • Slowly changing dimensions
  • Fabric
  • Direct Lake
  • Row-level security
  • Data dictionary

Star schema, nearly always

Power BI's engine is built for star schemas, and modeling against the grain of it is a decision you pay for permanently — in refresh times, in DAX that becomes progressively harder to reason about, and in measures that silently produce the wrong answer when filtered in an unexpected direction.

We conform dimensions across sources, resolve the grain explicitly for every fact table, and keep relationships single-direction unless there's a specific, documented reason not to. Bi-directional filtering is a tool of last resort, not a default.

Handle history deliberately

A customer moves region. A product changes category. Do last year's figures move with them or stay where they were reported? There is no universally correct answer — but there is a correct answer for your business, and it needs deciding consciously rather than being an accident of how the source system happens to overwrite records.

Where history matters we implement slowly changing dimensions properly. Where it doesn't, we don't add the complexity.

Measures over calculated columns

Business logic belongs in measures, expressed once and evaluated in context. Calculated columns bloat the model, break under filtering and tempt people into materializing things that should stay dynamic. We keep the model narrow, push transformation as far upstream as is sensible, and write DAX intended to be read by whoever inherits it.

Definitions are a business decision, not a technical one

Getting three stakeholders to agree what "active customer" means is a harder problem than implementing it, and it is not a problem you can solve by writing better SQL. We run that conversation, document what's agreed, and put the agreed version somewhere everyone can see it. In practice, this is where most of the durable value in an engagement comes from.

Security modelled in, not bolted on

If a regional manager should see only their region, that belongs in the model as row-level security — driven by a maintained security dimension, not by publishing five copies of the same report to five different workspaces and hoping nobody shares a link.

Next step

Which of your numbers don't agree?

Tell us where the discrepancies show up. That conversation usually points straight at the modeling decision behind them.