← Terug naar blog

Een goede datalaag: wat is het en hoe ontwerp je die?

Een datalaag klinkt als een technisch detail, maar is in veel digitale meetoplossingen een van de belangrijkste fundamenten. Een goed ontworpen datalaag maakt tracking stabieler, begrijpelijker en beter onderhoudbaar. Een slecht ontworpen datalaag zorgt juist voor veel maatwerk, kwetsbare tags en eindeloze discussies tussen marketing en development.

In dit artikel leg ik uit wat een datalaag is, waarom je hem nodig hebt en hoe je er een ontwerpt die over een paar jaar nog steeds bruikbaar is.

Wat is een datalaag (datalayer)?

Een datalaag (in het Engels data layer) is een gestructureerde manier om informatie over een website of app beschikbaar te maken voor analytics-, marketing- en personalisatietools. Denk aan:

• pagina-informatie en contentcategorieën;
• productgegevens en e-commerce-informatie;
• klantstatus, zoals ingelogd of nieuwe klant;
• gebruikersacties en formulierinteracties;
• transacties.

In plaats van dat iedere tool zelf uitzoekt waar die informatie op de pagina staat, wordt ze op één plek centraal beschikbaar gemaakt:

Datastroom

Website / app

Datalaag

Tag management

Analytics

Marketing

Andere tools

De datalaag is daarmee het contract tussen je digitale product en je meetstack. Is dat contract vaag, dan ontstaat er ruis in elke tool erachter. Is het helder, dan kun je van tool wisselen zonder je website opnieuw te bouwen.

Veel mensen denken bij een datalaag direct aan het dataLayer-object van Google Tag Manager. Maar dat is de invoer van één specifieke tool, met een eigen syntax. Zelf werk ik het liefst met een toolonafhankelijke datalaag, die je eenvoudig doorzet naar welke tag manager dan ook. Verderop laat ik zien hoe dat werkt.

Waarom is een datalaag belangrijk?

Zonder datalaag wordt tracking gebouwd op de manier waarop een website toevallig in elkaar zit. Een tag herkent een knop dan aan een CSS-class, een HTML-element, een tekst, een URL of de DOM-structuur. Dat werkt, totdat een developer de website aanpast. Een knop verandert bijvoorbeeld van

<button class="add-to-cart">

naar

<button class="product-action">

De website werkt nog precies zoals bedoeld, maar je tracking is stuk. En omdat niemand een foutmelding ziet, valt het vaak pas weken later op in een rapport: een van de signalen dat je GA4-data niet klopt. Een goede datalaag maakt je meting onafhankelijk van zulke implementatiedetails.

Een datalaag is geen lijst met alle beschikbare data

Een veelgemaakte fout is de gedachte: "laten we gewoon alles in de datalaag zetten". Dat voelt veilig, maar levert meestal een onnodig complexe oplossing op die niemand meer overziet, en vergroot het risico dat er persoonsgegevens in terechtkomen die daar niet horen.

Een goede datalaag bevat niet zoveel mogelijk informatie, maar de informatie die nodig is om relevante interacties en context betrouwbaar te meten. Daarvoor moet je eerst weten wat je wilt meten.

Begin bij de meetvraag, niet bij development

Een goed datalaagontwerp begint bij de businessvraag. Stel dat het doel is: meer online aanvragen.

1. KPI's: aantal aanvragen, conversieratio en de waarde van aanvragen.
2. Relevante events: formulier geopend, formulier gestart, formulier succesvol verzonden.
3. Context per event: formuliernaam, product, pagina en klanttype.
4. Pas daarna: de technische structuur van de datalaag.

Zo voorkom je dat de datalaag een verzameling technische gegevens wordt zonder duidelijke functie. Elk veld is terug te voeren op een vraag die iemand beantwoord wil zien.

Principes voor een duurzame datalaag

1. Toolonafhankelijk: de datalaag heeft een eigen naam en structuur, los van de syntax van GTM, Tealium of een andere tool. Hoe de data in een specifieke tool terechtkomt, is een aparte vertaalstap.
2. Consistente naamgeving: kies één conventie (bijvoorbeeld snake_case) en leg die vast, voor events én parameters.
3. Vaste datatypes: een prijs is altijd een getal, een ID altijd een string. Nooit "149,95" op de ene pagina en 149.95 op de andere.
4. Gedocumenteerd: elk event en elke parameter heeft een definitie, datatype en voorbeeldwaarde.
5. Getest: automatische controles vangen veel fouten op voordat ze productie bereiken.
6. Privacybewust: geen persoonsgegevens in de datalaag, tenzij bewust gekozen en gerechtvaardigd.

Eerst het datamodel, dan de implementatie

Consistentie is een van de belangrijkste onderdelen van een goede implementatie. Wil je een productweergave meten, dan leg je vooraf vast hoe het event heet en welke gegevens erbij horen. In een toolonafhankelijke datalaag gebruik je daarvoor je eigen, beschrijvende namen:

// Toolonafhankelijke datalaag: eigen naam, eigen structuur
window.siteData = window.siteData || [];

siteData.push({
  event: "product_viewed",
  product: {
    id: "SKU-8841",
    name: "Trailschoen",
    category: "Schoenen",
    price: 149.95,
    currency: "EUR"
  }
});

Dezelfde bouwstenen komen terug bij het toevoegen aan de winkelwagen en uiteindelijk bij de bestelling:

siteData.push({
  event: "order_completed",
  order: { id: "T-104233", revenue: 149.95, currency: "EUR" },
  products: [
    { id: "SKU-8841", name: "Trailschoen", price: 149.95, quantity: 1 }
  ]
});

Nergens in deze code staat iets over GTM, GA4 of Tealium. De website beschrijft alleen wat er gebeurt.

Doorzetten naar welke tag manager dan ook

Een klein stuk code luistert naar nieuwe events in de datalaag, ook naar events die al zijn gepusht voordat de tag manager geladen was, en vertaalt ze naar de syntax van de tag manager die je gebruikt. Voor Google Tag Manager ziet dat er bijvoorbeeld zo uit:

// Vertaling naar Google Tag Manager (GA4-e-commercestructuur)
window.dataLayer.push({
  event: "view_item",
  ecommerce: {
    currency: product.currency,
    value: product.price,
    items: [{
      item_id: product.id,
      item_name: product.name,
      item_category: product.category,
      price: product.price
    }]
  }
});

En dezelfde gebeurtenis naar Tealium iQ:

// Vertaling naar Tealium iQ
utag.link({
  tealium_event: "product_view",
  product_id: [product.id],
  product_name: [product.name],
  product_category: [product.category],
  product_price: [product.price.toFixed(2)]
});

Wissel je van tag manager, of komt er een tool bij, dan pas je alleen deze vertaling aan. De website en de datalaag blijven ongemoeid, en developers hoeven de syntax van een specifieke tool niet te kennen. De exacte structuur hangt af van je situatie, maar het principe blijft: definieer het datamodel voordat je gaat implementeren, en houd het los van je tools.

Begrijpelijk voor meerdere teams

Een datalaag is niet alleen een technisch document voor developers. Marketing moet kunnen zien welke gebeurtenissen worden gemeten, analisten welke data beschikbaar is, product welke interacties worden vastgelegd, en development wat er precies gebouwd moet worden. Daarom is goede documentatie onmisbaar. Een bruikbare specificatie ziet er bijvoorbeeld zo uit:

Vul dit per parameter aan met datatype, voorbeeldwaarde en of het veld verplicht is. Zo wordt een meetplan een echte implementatie-instructie, en kan een tester objectief vaststellen of iets klopt.

Veelgemaakte fouten

1. De datalaag wordt achteraf bedacht

De website is al gebouwd en pas daarna wordt gekeken hoe tracking mogelijk is. Dat leidt vrijwel altijd tot workarounds die later duur worden.

2. Alles wordt opgelost met DOM-scraping

Als informatie niet netjes beschikbaar is, wordt die rechtstreeks uit de HTML gehaald. Dat is snel, maar maakt tracking kwetsbaar voor elke designwijziging.

3. Iedere tool krijgt zijn eigen logica

GA4 heeft een eigen eventstructuur, een advertentieplatform een andere en een CDP weer een andere. Krijgt elke tool zijn eigen implementatie, dan groeit de complexiteit snel. Beter is één centraal datamodel waaruit je alle tools voedt. Datzelfde geldt voor de datalaag zelf: bouw je die direct in de syntax van één tag manager, dan zit je daar vervolgens aan vast.

4. Timing klopt niet

Een event wordt pas gepusht nadat de tag manager de datalaag al heeft gelezen, of een pageview vuurt voordat de paginagegevens beschikbaar zijn. Het resultaat: lege of ontbrekende waarden, vaak alleen bij bepaalde browsers of snelle verbindingen, en dus lastig te reproduceren.

5. Er is geen eigenaar en geen versiebeheer

Een datalaag verandert mee met je digitale product. Zonder duidelijke eigenaar raakt de documentatie achterhaald, en zonder versiebeheer weten developers niet wat ze wel en niet mogen wijzigen.

Hoe ziet een goede architectuur eruit?

Een eenvoudige uitgangssituatie ziet er zo uit:

Architectuur

Website / app

Toolonafhankelijke datalaag

Tag management

GA4

Advertentie­platformen

CDP

Data warehouse

De precieze architectuur verschilt per organisatie. Tag management kan bijvoorbeeld ook (deels) server-side plaatsvinden, met een server-side tag manager zoals GTM server-side of Tealium EventStream die de data vanuit de website of de backend ontvangt en doorzet naar de tools. Maar het principe blijft: je meting mag niet volledig afhankelijk zijn van één analytics- of marketingtool. Dan kun je tools vervangen, nieuwe kanalen toevoegen en data hergebruiken, zonder opnieuw te beginnen.

Wat betekent dit voor bureaus?

Voor marketing- en developmentbureaus is een goede datalaag vaak het verschil tussen een eenmalige trackingimplementatie en een oplossing die schaalt. Zeker bij meerdere klanten loont een herhaalbare aanpak:

1. bepaal de meetrequirements;
2. ontwerp het eventmodel;
3. definieer de datalaag;
4. vertaal dit naar trackingrequirements;
5. implementeer;
6. test;
7. documenteer;
8. richt structurele kwaliteitscontrole in.

Daarmee wordt analytics minder afhankelijk van individuele specialisten en losse GTM-configuraties. Zo kan ik bureaus helpen.

Conclusie

Een datalaag is geen doel op zich, maar de technische basis die je meting betrouwbaar en onderhoudbaar maakt. De belangrijkste ontwerpvraag is daarom niet "welke variabelen zetten we in de datalaag?", maar "welke informatie hebben we nodig om onze digitale interacties betrouwbaar te meten?" Vanuit dat antwoord ontwerp je een datalaag die marketing én development helpt, ook over een paar jaar nog.