hello@newnorth.nl+31 (0) 85 401 31 62
/Journal

De datamart: de laag waar je dashboard op hoort te staan

NaslagData2023.04.02
Freek Kampen
Freek KampenMede-oprichter, New North Digital

Wat een datamart is, waarom je niet rechtstreeks op ruwe data dashboardt, en hoe een marketingmart er in dbt en BigQuery uitziet.

Wat een datamart is

Een datamart is een afgebakend stuk van je datawarehouse, gemaakt voor één onderwerp of één afdeling. Een marketingmart, een financemart, een voorraadmart.

In de praktijk is het een handvol tabellen of views die klaarstaan om bevraagd te worden. De kolommen heten zoals de afdeling ze noemt, de berekeningen zijn al gedaan, en er zit geen ruis meer in die alleen de bron begrijpt.

Waar het warehouse alles bevat, bevat de mart precies dat wat één groep mensen nodig heeft om een vraag te beantwoorden.

De lagen eronder

Een modern warehouse heeft meestal drie lagen, en de mart is de bovenste.

  • Ruw. Data zoals hij binnenkwam. De GA4-export in BigQuery, je Shopify- of WooCommerce-tabellen, je advertentiekosten via een connector. Je verandert hier niets aan, zodat je altijd terug kunt naar de bron.
  • Schoongemaakt. Per bron één model dat kolommen hernoemt, types vastzet, tijdzones gelijktrekt en duidelijk onzinnige rijen eruit filtert. In dbt is dit de stagingslaag, met modellen als stg_ga4__events. Eén stagingmodel per brontabel, verder niets.
  • Marts. Hier voeg je bronnen samen tot iets waar een mens een vraag aan stelt. Sessies met orders, orders met advertentiekosten, per dag en per kanaal.

Waarom je niet op ruwe data dashboardt

Twee dingen gaan mis als je je dashboard rechtstreeks op de bron zet.

Het eerste is breekbaarheid. Hernoemt iemand een eventparameter in GTM, of verandert je webshop een kolomnaam bij een update, dan valt je grafiek om. Met een stagingmodel ertussen pas je één bestand aan en werkt alles erboven weer.

Het tweede is dat iedereen zijn eigen berekening maakt. De ene analist filtert testorders eruit op e-mailadres, de andere op ordertotaal, de derde vergeet het. Drie rapporten, drie omzetcijfers, en een vergadering die over de cijfers gaat in plaats van over het werk.

Een mart lost dat op door de keuze één keer te maken, op een plek waar je hem terug kunt lezen.

Hoe je dit bouwt: dbt

In de praktijk bouw je deze lagen met dbt. Je schrijft SELECT-statements, dbt maakt er tabellen of views van, en met ref() verwijs je van het ene model naar het andere. Daaruit leidt dbt de bouwvolgorde af.

Een marketingmart is meestal al geaggregeerd. Niet elke gebeurtenis, maar één rij per dag per kanaal. Dat scheelt twee dingen: je dashboard laadt snel, en je scant in BigQuery megabytes in plaats van gigabytes, want je betaalt per gescande byte.

-- models/marts/marketing/mart_channel_performance.sql
{{ config(materialized='table', partition_by={'field': 'date_day', 'data_type': 'date'}) }}

with sessions as (
    select date_day, channel, count(distinct session_id) as sessions
    from {{ ref('int_ga4_sessions') }}
    group by 1, 2
),

orders as (
    select date_day, channel, count(*) as orders, sum(revenue_ex_vat) as revenue
    from {{ ref('int_orders_attributed') }}
    where is_test_order = false
    group by 1, 2
),

spend as (
    select date_day, channel, sum(cost) as cost
    from {{ ref('stg_ads__daily_cost') }}
    group by 1, 2
)

select
    sessions.date_day,
    sessions.channel,
    sessions.sessions,
    coalesce(orders.orders, 0) as orders,
    coalesce(orders.revenue, 0) as revenue,
    coalesce(spend.cost, 0) as cost
from sessions
left join orders using (date_day, channel)
left join spend using (date_day, channel)

Let op wat hier al beslist is: testorders zijn eruit, omzet is exclusief btw, en de toerekening aan een kanaal gebeurt in het model eronder. Wie dit dashboard opent, kan die keuzes niet per ongeluk anders maken.

Wat je hiermee doet

  • Laat je ruwe data met rust. Elke schoonmaakactie hoort in een model, niet in de bron.
  • Maak per brontabel één stagingmodel en houd dat saai: hernoemen, casten, filteren.
  • Bouw een mart per onderwerp, met kolomnamen die de afdeling zelf gebruikt.
  • Aggregeer in de mart tot het niveau waarop je rapporteert, meestal dag maal kanaal maal land. Detail bewaar je in de laag eronder.
  • Partitioneer je marttabellen in BigQuery op datum, zodat een filter op de laatste 28 dagen niet je hele historie scant.
  • Sluit je BI-tool alleen op de marts aan. Wie rechtstreeks op ruw wil, schrijft een model, geen dashboard.

Wil je hierover doorpraten?

Praten over jouw data?

Vertel ons over je stack, je doelen en de data die je nu mist.

Duurt 1 minuut