Analytics engineering

Models and metrics that agree with each other.

When two reports disagree, the problem is almost never the BI tool. It is that the same metric was defined three times, in three places, by three people.

When this is the right call

These are the sentences that usually precede the enquiry:

  • Revenue means something different in finance and in the product dashboard.
  • SQL is copied between dashboards, so a fix has to be applied everywhere.
  • Nobody can explain what a table contains without asking the person who made it.
  • A schema change upstream breaks reports silently, days later.

What is different afterwards

  • One definition per metric, in code, with the business logic visible.
  • Tests that fail loudly in the pipeline instead of quietly in a board pack.
  • Lineage from a dashboard number back to the source column.
  • A modelling layer new analysts can read without a tour guide.

What you receive

  • Layered dbt project: staging, intermediate and mart models with a documented convention.
  • Metric definitions consolidated into a single semantic layer.
  • Data tests for uniqueness, referential integrity, freshness and business rules.
  • Generated documentation and lineage your team can browse.
  • CI that runs build and tests on every pull request.

How it runs

  1. Inventory the definitionsCollect every existing version of the contested metrics and put the differences in front of the people who own them.
  2. Agree the canonical logicOne definition per metric, signed off by the business, written down before it is coded.
  3. Model in layersStaging for cleaning, intermediate for logic, marts for consumption. Each layer with one job, so changes stay local.
  4. Test and documentAssertions on the things that would actually hurt, and documentation written at the point of definition rather than afterwards.
  5. Migrate consumptionPoint reports at the modelled layer and retire the duplicated SQL behind them.

Who this suits

  • Teams with a warehouse already in place but no trusted modelling layer.
  • Companies where reporting disagreements have become a recurring meeting.
  • Analysts who need to move faster than raw-table SQL allows.

Questions

Before you get in touch

Does this require dbt specifically?

No, but the practices it encodes — version control, layered models, tests, generated docs and CI — are the point. dbt is the most common way to get them, so it is the default unless you already have a working alternative.

How do you resolve two teams disagreeing about a definition?

By making the disagreement explicit and costed rather than arbitrating it. Both versions get written down with their numbers side by side, and the business owner picks. The job is to make sure the decision is made once and recorded, not to make it for them.

Will this slow down ad hoc analysis?

For the first weeks, slightly. After that it is faster, because the common joins and definitions already exist and analysts stop rebuilding them per question.

What about the reports nobody uses?

They get identified from usage data and proposed for deletion. Migrating dead reports is the most common way a modelling project doubles in size for no benefit.

Enquire about analytics engineering

Describe the situation in a few lines. You will get a straight answer about fit, timing and rough shape of the work.

The current situation and what "solved" looks like is enough. Detail can wait for the call.

Tell me what is broken.

A short call is usually enough to tell whether this is a two-week fix or a two-month one — and whether I am the right person for it.