Book a consultation

Service line 03 of 06

Data Analytics & BI

Shared metric definitions, a semantic layer and the dashboards built on them, so the same question gets the same answer in every report.

Discuss your reporting What we deliver

What a metric definition looks like

Before we build a dashboard, we agree definitions like this one with the person who owns each number. Every report then reads the metric from the same model.

An illustrative example, not client data.

Tests on the model: no nulls, one row per invoice line, and the monthly total matches the ledger.

models/marts/finance/revenue.ymlExample
semantic_models:
- name: invoices
model: ref('fct_invoices')
defaults:
agg_time_dimension: invoice_date
entities:
- name: invoice_line
type: primary
measures:
- name: invoiced_amount
agg: sum
expr: amount_excl_tax
- name: credited_amount
agg: sum
expr: credit_excl_tax
metrics:
- name: net_revenue
label: Net revenue
type: derived
type_params:
expr: invoiced_amount - credited_amount
metrics: [invoiced_amount, credited_amount]
meta:
owner: finance_lead # signs off the month
grain: day
used_in: [board_pack, sales_dashboard]

When two dashboards disagree

Each of these goes back to a metric nobody wrote down.

  • Two dashboards show two revenue figures, and the meeting starts with an argument about which is right.

    We write each core metric down once, with its owner, grain and filters, and every report reads it from the same model.

  • Analysts spend most of the week rebuilding the same spreadsheet.

    Recurring extracts become dbt models that refresh on schedule, so analysts spend their time on the questions instead of the export.

  • There are hundreds of dashboards, and nobody knows which ones still matter.

    We check usage, archive what nobody opens, and rebuild the reports people do use on the shared models.

  • Every new report waits in the data team’s queue.

    A semantic layer with documented measures lets business users build their own views without SQL, inside rules the data team controls.

  • Dashboards are slow, so people export to Excel and work there.

    We move heavy logic out of the BI tool into the warehouse and tune the models behind the slowest pages.

From definitions to dashboards

Most reporting work needs the first two lines in place before dashboards are worth building.

  1. dbt models and metrics

    Staging, intermediate and mart models in dbt, with tests on keys, relationships and accepted values, and metrics defined in code.

    You receive

    • dbt project in your repository
    • Generated docs and lineage

  2. Semantic layer

    Measures, dimensions and joins defined once, in the dbt semantic layer, a Power BI semantic model or LookML, to suit your BI tool.

    You receive

    • Metric catalogue with owners
    • Row security rules per role

  3. Dashboards and reports

    Dashboards built around the decision each one supports, with definitions on the page and the last refresh time visible.

    You receive

    • Dashboards in your BI tool
    • Naming and layout guide

  4. Adoption and ownership

    Training for analysts and report owners, and a simple way to request a new report or retire an old one.

    You receive

    • Recorded training sessions
    • Report ownership register

BI tools and the models under them

We build in the BI tool you already license where it fits. Moving to another tool is a question for the assessment, not a default.

Listing a technology does not imply a vendor partnership or certification.

Models & quality

  • dbt
  • Great Expectations
  • Monte Carlo

BI & reporting

  • Power BI
  • Looker
  • Tableau

Warehouse

  • Snowflake
  • BigQuery
  • Databricks
  • Microsoft Fabric

Governance

  • Microsoft Purview
  • Unity Catalog

Questions about analytics and BI

Not answered here? Ask in the request form.

Do we have to change BI tools?

No. Most of the work sits below the BI tool, in models and definitions. That is also why moving between tools later costs less.

Power BI, Looker or Tableau?

If you already run one and it works, keep it. For a first choice we weigh your cloud, your existing licences and who will build the reports, and write the reasons down.

Who decides what a metric means?

Your business owners do. We run the sessions, draft the definitions and point out conflicts, and the owner of each number signs it off.

Can business users build their own reports?

Yes, on the semantic layer. They pick measures and filters that are already defined, so their reports still match the official ones.

What happens to the old dashboards?

We check which ones people open. Those in use are rebuilt or repointed to the new models, and the rest are archived once their owners agree.

Discuss your reporting

Bring two or three reports people disagree about and a list of the tools you use. That is usually enough for a useful first call.

How it runs: a call (30 minutes with a senior engineer), an assessment and written plan, the build with weekly demos, then handover or run. Our delivery standard

Book a consultation Send a request