Van wildgroei aan events naar een schaalbare server-side architectuur

Een grote organisatie haalde weinig uit zijn server-side omgeving in Tealium EventStream. De oorzaak zat niet in de server, maar eerder in de keten: een wildgroei aan losse events zonder gezamenlijk fundament. Door eerst de basis op orde te brengen, kwam er veel meer bruikbare en betrouwbare data in de server-side omgeving, voor dezelfde kosten als de oude setup.

Organisatie

Grote organisatie met meerdere teams

Stakeholders

CRO, analytics en marketing

Rol

Advies, architectuur en implementatie, samen met een interne medewerker

Doorlooptijd

Ruim een half jaar

Tools

Tealium iQ en EventStream, GA4, BigQuery

Resultaat

Veel meer bruikbare data uit server-side, voor dezelfde kosten

De uitgangssituatie

In de loop der tijd waren er steeds meer losse events bijgekomen: voor campagnes, voor experimenten, voor rapportages van verschillende teams. Elk team had zijn eigen wensen, maar er was geen gezamenlijk vastgelegd overzicht van wat er gemeten moest worden, met welke context en waarom. Dat leidde tot vier problemen:

• Dubbele en overlappende events. Teams maten dezelfde handelingen, elk op hun eigen manier.
• Geen vaste naamgeving. Dezelfde actie had in verschillende events een andere naam en andere parameters.
• Data die niet bruikbaar was voor analyse. Events misten context of waren niet met elkaar te combineren.
• Oplopende requests en kosten. Omdat de kosten van server-side afhangen van het aantal requests, ging er capaciteit op aan events zonder duidelijke functie.

Zo bleef er weinig ruimte over om server-side in te zetten waar het echt waarde oplevert, en had geen van de teams data waar het volledig op kon vertrouwen.

De aanpak

In plaats van direct aan de server-side inrichting te sleutelen, zijn we bij het begin van de keten gestart. Ik werkte hierin nauw samen met een interne medewerker van de organisatie: het afstemmen met de stakeholders en de implementatie hebben we samen gedaan.

1. Requirements vastleggen met alle stakeholders

Eerst hebben we CRO, analytics en marketing samen aan tafel gezet, in plaats van per team losse wensen te verzamelen. Per behoefte hebben we vastgelegd welke events echt nodig zijn, met welke context en voor welk doel. Dat leverde één gezamenlijke set requirements op, waar alle teams zich in herkenden.

2. Eventmodel, naamconventie en datalaag

Op basis van die requirements hebben we een eventmodel met een vaste naamconventie opgesteld, en de datalaag daarop geoptimaliseerd. Events en context zijn daardoor consistent en herbruikbaar beschikbaar, los van de tools die de data gebruiken. Meer over die aanpak lees je in een goede datalaag: wat is het en hoe ontwerp je die?

3. Eerst opruimen, dan uitbreiden in Tealium iQ

Daarna hebben we de tag management-architectuur in Tealium iQ structureel aangepast. Overbodige en overlappende events gingen eruit vóórdat er iets nieuws bijkwam. Wat overbleef, werd ondergebracht in één consistent eventmodel dat alle stakeholders bedient.

4. Doorgevoerd naar EventStream

Pas daarna is de nieuwe architectuur doorgevoerd naar Tealium EventStream. Omdat er minder en betere events binnenkomen, kon de server-side omgeving veel gerichter worden ingericht. Vanuit daar gaat dezelfde data naar de eindpunten, zoals BigQuery, een datalake en Google Ads, in plaats van een aparte datastroom per tool.

Ook is er een server-side GA4-setup ingericht, naast de bestaande client-side property. Die levert schonere en consistentere data op, geeft meer controle over welke data naar Google gaat, en maakt het mogelijk om beide properties naast elkaar te vergelijken en verschillen te valideren.

Wat er is opgeleverd

• Eventmodel en naamconventie: een vaste structuur voor events en parameters, zodat nieuwe metingen consistent blijven.
• Datalaagspecificatie: uitvoerbaar voor de developers, en onafhankelijk van de tools die de data gebruiken.
• Documentatie en beheerafspraken: wie eigenaar is van de meting, en hoe nieuwe events worden aangevraagd en beoordeeld, zodat de wildgroei niet terugkomt.

Het resultaat

• De wildgroei aan losse events is tegengegaan, met aanzienlijk minder overbodige requests.
• De data is vooraf afgestemd met CRO, analytics en marketing, en daardoor voor alle partijen bruikbaar.
• Een overzichtelijkere tag management-architectuur die beter te onderhouden is.
• Veel meer bruikbare en betrouwbare data in de server-side omgeving.
• Eén eventmodel dat door verschillende tools wordt gebruikt, zoals BigQuery, het datalake en Google Ads.
• Een server-side setup voor GA4, naast de bestaande client-side property.
• Dat alles voor dezelfde kosten als de oude setup, waar weinig uit te halen viel.

Wat deze case laat zien

Server-side tracking is zo goed als de data die je erheen stuurt. De kosten hangen af van het aantal requests, dus elk overbodig event kost geld en capaciteit. Drie keuzes maakten hier het verschil:

• Stakeholders samen aan tafel. Eén gezamenlijke set requirements voorkomt dat elk team zijn eigen variant van hetzelfde event laat bouwen.
• Eerst opruimen, dan uitbreiden. Wie op een rommelige basis doorbouwt, betaalt daar bij server-side letterlijk voor.
• Eén eventmodel voor alle tools. Eén goede datastroom die je hergebruikt, in plaats van een aparte stroom per tool.

Lees meer in server-side tracking: wanneer heb je het nodig en wanneer niet? en wat kost server-side tracking? Een ander voorbeeld van wat server-side oplevert: sturen op marge in plaats van omzet.