# Een model kan niets met een rommelige datalaag

Elke belofte over AI in analytics gaat over de bovenkant van de stack. Een model dat vier spellingen van hetzelfde event binnenkrijgt, ziet vier gedragingen.

- Bron: https://koenholman.nl/onderzoek/een-model-kan-niets-met-een-rommelige-datalaag/
- Auteur: Koen Holman
- Rubriek: Digital analytics
- Gepubliceerd: 15 september 2026

## In het kort

- Een AI-functie op analytics-data is zo goed als de slechtst gedefinieerde metriek die erin gaat; het model vergroot uit wat er al in de invoer zit, fouten inbegrepen.
- Inconsistente naamgeving is geen cosmetisch probleem: een model behandelt elke spelling van een event als een aparte gedraging, en vier kleine segmenten leren minder dan één groot.
- Van de 53 AI-praktijkmensen die Sambasivan et al. interviewden, rapporteerde 92 procent een data-cascade: een fout onderin die zich pas bovenin toonde.
- Een datacontract dat niet in de pijplijn draait, is een intentie; wat helpt is een poort die een afwijkend event weigert vóór het een rapport bereikt.

---

**Figuur.** Twee rijen. Boven: vier verschillende namen voor dezelfde handeling — add\_to\_cart, addToCart, Add To Cart en cart\_add — lopen elk apart een model in en komen eruit als vier gedragingen, elk te klein om iets van te leren. Onder: dezelfde vier namen gaan door een datacontract dat afwijkingen bij de bron weigert, en komen eruit als één gedraging met genoeg volume.

Vier spellingen van één handeling zijn voor een model vier gedragingen. Het contract voegt niets toe aan de data; het haalt er alleen de varianten uit vóór ze een rapport of een model bereiken.

Vrijwel elke belofte over AI in analytics gaat over de bovenkant van de stack: voorspellende metrieken, een chatvenster boven je rapporten, inzichten die vanzelf verschijnen. Wat die beloften gemeen hebben is een aanname die er zelden bij staat: dat wat er onderin binnenkomt — de events, de velden, de namen — consistent genoeg is om iets van te leren. Dit stuk gaat over die aanname, en over wat er gebeurt als hij niet klopt.

Het is bewust het eerste van een reeks over wat AI wel en niet toevoegt aan digital analytics. Niet omdat het het spannendste onderwerp is, maar omdat de drie die erna komen — bewaking, gemodelleerde cijfers, redenerende systemen — alle drie op dit fundament staan en er alle drie zonder omvallen.

Een model vergroot uit wat er al in je data zit. Zit er een fout in, dan is dat wat het uitvergroot.

## De belofte, en wat ze stilzwijgend aanneemt

Dit is geen nieuwe waarneming, en niet een uit de marketingwereld. In 2015 beschreven [Sculley en collega's](https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf) waarom systemen met machine learning erin duurder zijn in onderhoud dan gewone software, en één van hun vaststellingen is dat data-afhankelijkheden meer kosten dan code-afhankelijkheden. Een module die van een andere module afhangt, valt om met een foutmelding als die andere verandert. Een model dat van een invoerveld afhangt, valt niet om als de betekenis van dat veld verschuift — het gaat gewoon iets anders leren, stilletjes.

Zes jaar later gaven [Sambasivan en collega's](https://dl.acm.org/doi/10.1145/3411764.3445518) dat verschijnsel een naam. Ze interviewden 53 mensen die AI-systemen bouwden voor toepassingen met hoge inzet — het abstract noemt kankerdetectie, stroperij en kredietverlening — in India, Oost- en West-Afrika en de Verenigde Staten, en vroegen wat er misging. Het antwoord noemden ze een *data cascade*: een fout in de data die zich niet daar toont waar hij ontstaat, maar stroomafwaarts, opgeteld bij alles wat er daarna op is gebouwd. 92 procent van de geïnterviewden had er minstens één meegemaakt. De titel van het paper is een citaat van een van hen: iedereen wil het modelwerk doen, niemand het datawerk.

Dat onderzoek gaat over machine learning in het algemeen, niet over webanalytics. Maar de mechaniek is dezelfde, en in webanalytics is de invoer zeldzaam vaak rommelig: events komen uit meerdere teams, over meerdere jaren, via een tagmanager waarin iedereen met de juiste rechten er ‘even een event bij’ kan zetten.

## Eén handeling, vier spellingen

Neem een webshop die al een jaar of zes meet. **Illustratief voorbeeld, geen meting** — de vier namen hieronder zijn geconstrueerd, de mechaniek erachter niet. De handeling ‘iets in de winkelwagen leggen’ heet in die zes jaar achtereenvolgens:

- `add_to_cart` — de naam uit de [lijst met aanbevolen gebeurtenissen](https://support.google.com/analytics/answer/9267735) van het analyticsplatform (onder ‘voor online verkoop’: een gebruiker voegt artikelen toe aan het winkelwagentje), met voorgeschreven parameters op een aparte referentiepagina, gezet door het team dat de meting ooit inrichtte;
- `addToCart` — dezelfde handeling, maar in de schrijfwijze van de JavaScript-code die 'm afvuurt, toegevoegd door een ontwikkelaar die de aanbevolen lijst niet kende;
- `Add To Cart` — leesbaar, met spaties, ingetypt in de interface van de tagmanager door een marketeer die een campagnedoel nodig had;
- `cart_add` — uit een ouder systeem dat nooit is uitgezet, want niemand wist meer wat erop leunde.

Voor een mens zijn dit vier namen voor één ding. Voor een rapport zijn het vier rijen die iemand handmatig moet optellen, en die iemand doet dat de eerste keer wel en de zesde keer niet meer. Voor een model zijn het vier gedragingen. Een functie die ‘kans op aankoop’ voorspelt, ziet vier zwakke signalen waar er één sterk had kunnen zijn, en een functie die segmenten maakt, maakt er vier waar er één had gemoeten. Het model doet niets fout. Het leert precies wat het krijgt.

Dat is de tekening bovenaan dit stuk. Het contract in de onderste rij voegt niets toe — geen verrijking, geen slimmigheid. Het weigert alleen drie van de vier namen bij de bron, zodat er één overblijft die groot genoeg is om iets van te leren.

## Vier lagen onder de AI-laag

De naamgeving is het zichtbaarste voorbeeld, maar niet het enige. Onder een AI-functie op analytics-data liggen vier lagen, en op elk ervan ontstaat een eigen soort fout die zich naar boven voortplant.

**Figuur.** Een piramide van vijf lagen. Bovenaan, het smalst: AI-functies. Daaronder rapportage en dashboards, dan definities van metrieken, dan schema en naamgeving van events, en onderaan, het breedst: verzameling, identiteit en consent. Links van de piramide wijst een pijl omhoog: hier gaat de aandacht heen, met budget, demo's en roadmapslides. Rechts wijst een pijl omlaag: hier ontstaan de fouten, en die planten zich naar boven voort — één fout onderin maakt elke laag erboven fout.

Aandacht en budget bewegen naar boven, naar de laag met de demo's. Fouten ontstaan onderin en worden door elke laag erboven overgenomen — een AI-functie op de bovenste laag kan een fout uit de onderste niet zien, alleen versterken.

- **Verzameling, identiteit en consent.** Welk deel van de bezoekers is überhaupt gemeten, en zijn twee sessies van dezelfde persoon als één herkend? Een model dat leert op wie toestemming gaf, leert over wie toestemming gaf. Daar gaat het derde stuk in deze reeks over.
- **Schema en naamgeving.** Het voorbeeld hierboven. Opvallend genoeg is dit de laag die het langst een standaard heeft: de [W3C Customer Experience Digital Data Layer](https://www.w3.org/2013/12/ceddl-201312.pdf) uit december 2013 legde al één wortelobject vast, `digitalData`, met vaste deelobjecten voor pagina, product, winkelwagen, transactie, event en gebruiker. Geen van die deelobjecten is verplicht, zegt de specificatie, maar wie er een opneemt *moet* de vastgelegde naam en het vastgelegde type volgen. Dat er twaalf jaar later nog vier spellingen voor één event naast elkaar staan, is dus geen gebrek aan standaard maar een gebrek aan handhaving.
- **Definities van metrieken.** Wat telt als een conversie, wat als een sessie, wat als een terugkerende bezoeker? Twee dashboards met twee definities geven twee waarheden, en een model dat op het ene is getraind en tegen het andere wordt afgezet, klopt op geen van beide.
- **Rapportage.** De laag waar de fouten van de drie lagen eronder zichtbaar worden — en meestal verkeerd worden toegeschreven, aan een campagne of een seizoen, omdat dat de dingen zijn die in het rapport staan.

Dat is wat de piramide hierboven laat zien. De lagen worden naar beneden toe breder, omdat er meer werk in zit en meer kan misgaan; de aandacht beweegt de andere kant op, naar de smalle top waar de demo's staan. Een fout in de onderste laag — een veld dat leeg doorkomt, een sessie die als twee wordt geteld — wordt door elke laag erboven als waarheid overgenomen, en de AI-functie bovenop heeft geen enkele manier om te zien dat hij op een fout leert. Dat is de cascade van Sambasivan in het klein: de fout ontstaat waar niemand kijkt, en toont zich waar iedereen kijkt.

> **Vanaf hier: mijn interpretatie**
>
> Alles hierboven is terug te lezen in de vier bronnen onderaan, of is een geconstrueerd voorbeeld dat als zodanig is benoemd. Wat nu volgt staat daar niet in: wat ik zou doen voordat er een AI-functie op een datalaag wordt gezet.

## Het contract als poort, niet als document

Het woord *datacontract* is in data engineering al een paar jaar gangbaar, en het wordt vaak begrepen als een document: een pagina in een wiki met de afgesproken velden. Dat is het niet. Een contract dat niet automatisch getoetst wordt, is een intentie, en een intentie overleeft de eerste ontwikkelaar die de wiki niet leest niet. Wat ik bedoel is een poort in de pijplijn die een event weigert vóór het een rapport of een model bereikt. Zes regels, in volgorde van wat het meest oplevert:

1. **Eén naam per handeling**, vastgelegd in een schema dat leesbaar is voor mensen én machines. Geen synoniemen. De aanbevolen lijst van het platform is een prima startpunt, juist omdat niemand er eigenaar van hoeft te zijn.
2. **Verplichte velden zijn verplicht.** Een event zonder verplicht veld wordt geweigerd, niet stilzwijgend leeg doorgelaten. Leeg doorlaten is de manier waarop een veld ongemerkt van betekenis verandert.
3. **Types en waardebereiken.** Een bedrag is een getal met twee decimalen in één valuta, een status komt uit een vaste lijst. Een bedrag dat als tekst of in centen binnenkomt, valt nergens uit — het schuift alleen elke som die erop volgt een factor honderd op.
4. **Versie bij elke wijziging.** Een veld hernoemen is een nieuwe versie, met een datum waarop de oude vervalt. Zonder die datum is de oude naam de vijfde spelling.
5. **Eigenaar per event.** Eén naam die gebeld wordt als het event breekt. Geen team, een persoon; een team is de manier waarop een event van niemand wordt.
6. **Automatisch getoetst, vóór het rapport.** Dit is de regel die de andere vijf van een intentie een afspraak maakt. Deze site doet hetzelfde, in het klein: een stuk zonder bronnen of zonder prompt haalt de build niet, en dat wordt niet door een lezer opgemerkt maar door een functie die bij elke build de hele catalogus naloopt.

## Wat dit betekent voor een roadmap

Wie een roadmap schrijft voor ‘AI in analytics’, krijgt de vraag wanneer de voorspellende functies komen. Mijn antwoord zou zijn: nadat het contract draait, en niet eerder. Niet omdat het fundament belangrijker is dan de bovenkant, maar omdat de bovenkant zonder fundament een uitvergroting is van wat er onderin mis is — en die uitvergroting ziet er in een demo net zo overtuigend uit als een echte bevinding. Dat is de moeilijkste helft van het gesprek: een model dat op vier spellingen leert, geeft geen foutmelding. Het geeft een antwoord.

De volgorde die daaruit volgt is de omgekeerde van waar de aandacht naartoe gaat. Eerst de laag die niemand ziet: contract, versie, eigenaar. Dan de bewaking die vaststelt of het overeind blijft — het onderwerp van het volgende stuk. Pas daarna de functies die op de slides staan.

## Waar het ophoudt

**Vier voorbehouden bij dit stuk zelf**

**Het voorbeeld is geconstrueerd.** De vier spellingen zijn niet uit een bestaande datalaag geëxporteerd; ze zijn de vier vormen die in webanalytics naast elkaar voorkomen, bij elkaar gezet om het mechanisme te tonen. Er staat geen aantal bij, en dat is met opzet.

**Van Sambasivan et al. zijn de publicatiepagina en het abstract gelezen, niet het hele paper.** De 53 geïnterviewden, de definitie van een data cascade en de 92 procent staan alle drie letterlijk in het abstract. Hoe die 92 procent precies is geteld — per persoon, per project, per interview — staat in de vijftien pagina's daarachter, en die zijn voor dit stuk niet doorgenomen.

**De cascade-studie gaat over andere systemen.** Sambasivan et al. interviewden bouwers van modellen voor diagnostiek, krediet en natuurbehoud, niet van webanalytics. Dat de mechaniek overdraagbaar is, is mijn gevolgtrekking, geen bevinding uit het paper.

**Dit stuk meet niets.** Het zet twee papers, een specificatie en een leverancierslijst naast een geconstrueerd geval. Wat het niet doet, is een echte datalaag doorlichten en tellen hoeveel varianten er staan; dat is precies wat de prompt hieronder de lezer laat doen op de eigen data.

## Bronnen

1. [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf) — Sculley D et al. · NIPS · 2015
2. ["Everyone wants to do the model work, not the data work": Data Cascades in High-Stakes AI](https://dl.acm.org/doi/10.1145/3411764.3445518) — Sambasivan N, Kapania S, Highfill H, Akrong D, Paritosh P, Aroyo LM · CHI 2021 · 2021
3. [Customer Experience Digital Data Layer 1.0](https://www.w3.org/2013/12/ceddl-201312.pdf) — W3C Customer Experience Digital Data Community Group · W3C Community Group Final Report · 2013
4. [[GA4] Aanbevolen gebeurtenissen](https://support.google.com/analytics/answer/9267735) — Google · Google Analytics Help, geraadpleegd 15 september 2026 · 2026

## Toets het op je eigen systeem

Laat een AI-systeem de naamgeving van een datalaag toetsen vóór het er iets over concludeert.

```
Je gaat een export van eventnamen beoordelen voordat je er een inzicht uit haalt. Je krijgt een tabel met per eventnaam het aantal keren dat het event in de afgelopen twaalf maanden is geregistreerd.

Stap 1 — wijs groepen van namen aan die waarschijnlijk dezelfde handeling beschrijven (een andere schrijfwijze, een andere woordvolgorde, een vertaling). Zeg per groep hoe zeker je daarvan bent, in drie standen: zeker, waarschijnlijk, onduidelijk. Een naam die je niet met zekerheid kunt plaatsen hoort in 'onduidelijk', niet stilzwijgend in de dichtstbijzijnde groep.

Stap 2 — zet per groep de losse volumes en het gecombineerde volume naast elkaar. Laat zien welk aandeel van het totaal in de grootste variant zit.

Stap 3 — schrijf per groep één zin over welke conclusie op de losse volumes wél te trekken was en op het gecombineerde volume niet, of andersom. Als het antwoord 'geen verschil' is, zeg dat dan.

Stap 4 — weiger een 'inzicht' te formuleren zolang stap 1 nog groepen in de stand 'onduidelijk' bevat. Zeg in plaats daarvan welke informatie nodig is om die groepen te plaatsen: een schema, een eigenaar per event, of een datum waarop een naam is veranderd.
```