Data lineage: terugvinden waar een getal in je dashboard vandaan komt

Data lineage is de route die een getal heeft afgelegd: uit welke bron het komt, door welke bewerkingen het is gegaan en in welke rapporten het terechtkomt.

Je gebruikt het in twee richtingen. Vooruit, om te zien wat er stukgaat als je een bron aanpast. Achteruit, om een cijfer in een dashboard terug te volgen tot het punt waar het ontstond.

Voor een marketingstack is dat punt bijna altijd een tag op je website of app.

Een developer hernoemt in Google Tag Manager een parameter in het purchase-event, van value naar order_value, omdat dat duidelijker leek. De tag vuurt, GTM geeft groen, de preview ziet er goed uit.

GA4 negeert de onbekende parameter en vult zijn eigen omzetveld niet meer. Twee weken later valt op dat de omzetgrafiek in het dashboard is ingezakt, terwijl de webshop gewoon draait.

Dan begint het zoeken. Is het de tag? Het GA4-model? De export naar BigQuery? Het dbt-model? Het dashboard? Zonder lineage doe je dat door alle vijf de lagen handmatig open te klappen, en is de wijziging in GTM inmiddels niet meer de eerste plek waar iemand kijkt. Bij ecommerce zit de fout vaak in de items-array, waar we apart over schreven.

Met lineage draai je het om: je begint bij de grafiek, loopt de keten terug en komt binnen enkele minuten uit bij de tag die veranderde.

dbt, voor alles binnen je warehouse. Omdat je modellen naar elkaar verwijzen met ref(), kent dbt de afhankelijkheden zonder dat je ze opschrijft. dbt docs generate gevolgd door dbt docs serve geeft je een klikbare grafiek van bron tot mart. Met dbt ls --select stg_ga4__events+ krijg je op de commandline alles wat achter dat model hangt, wat handig is voordat je iets sloopt.

BigQuery, voor wat er buiten dbt gebeurt. De querygeschiedenis in INFORMATION_SCHEMA.JOBS laat zien welke tabellen door welke queries zijn gelezen, inclusief de queries die je BI-tool stuurt. De historie gaat een beperkte periode terug, dus gebruik het om te onderzoeken, niet om te archiveren.

SELECT
  user_email,
  COUNT(*) AS jobs,
  MAX(creation_time) AS last_seen
FROM `region-eu`.INFORMATION_SCHEMA.JOBS,
UNNEST(referenced_tables) AS t
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND t.dataset_id = 'marts_marketing'
  AND t.table_id = 'mart_channel_performance'
GROUP BY user_email
ORDER BY jobs DESC

In Google Cloud kun je daarnaast lineage voor BigQuery aanzetten via Dataplex, dat de relaties tussen tabellen automatisch vastlegt.

De laatste stap naar de site of app: je meetplan. Geen enkele tool kent het verband tussen de knop op je checkoutpagina en het event dat daaruit volgt. Dat staat in je tagging-documentatie, of het staat nergens.

Bij een stack met tien tot vijftien modellen en één dashboard is een goed bijgehouden meetplan genoeg. Een spreadsheet met per event de parameters, de tag die hem stuurt en het rapport waar hij landt, doet het werk.

Lineagesoftware wordt interessant zodra je tientallen modellen hebt, meerdere bronnen die door elkaar lopen, en mensen die elkaars modellen gebruiken zonder dat te overleggen. Vanaf dat punt kun je de keten niet meer in je hoofd houden.

Koop je zo'n tool voordat je daar bent, dan onderhoud je documentatie over een stack die je ook gewoon kon overzien.

• Houd één meetplan bij met per event de parameters, waar de tag afvuurt en waar het event uiteindelijk wordt gebruikt.
• Bouw je transformaties met ref() in dbt, nooit met hardgecodeerde tabelnamen. Dan krijg je je afhankelijkheidsgraaf gratis.
• Draai dbt ls --select <model>+ voordat je een kolom hernoemt of weghaalt, zodat je weet wat eronder hangt.
• Zet je BI-rapporten op de marts. Elk rapport dat rechtstreeks op ruwe data staat, valt buiten je lineage.
• Bewaar wijzigingen aan tags in de versiegeschiedenis van GTM met een beschrijving die de reden noemt, zodat een breuk terug te leiden is naar een datum.
• Groeit het aantal modellen richting enkele tientallen, kijk dan naar een lineagetool. Daarvoor is een meetplan goedkoper en sneller.