Data & Tracking
Server-side tagging: zo zet je het op met Google Tag Manager
Kopieer voor AI
Server-side tagging betekent dat je tags niet langer allemaal in de browser van je bezoeker laat draaien, maar dat de browser één datastroom naar een server stuurt die jij beheert. Die server, een Google Tag Manager server container, verwerkt de data en stuurt ze door naar GA4, Google Ads, Meta of andere platformen. Het resultaat: minder scripts op je site, meer controle over wat je deelt en duurzamere first-party cookies. In dit artikel lees je hoe het werkt, wanneer het de moeite loont en hoe je het stap voor stap opzet.
Wat is server-side tagging?
Bij klassieke, client-side tagging laadt elke tool zijn eigen script in de browser: de Google-tag, de Meta-pixel, de LinkedIn Insight Tag. Elk script stuurt zelf data naar zijn eigen server. Je hebt weinig zicht op wat er precies vertrekt.
Bij server-side tagging verandert die route. De browser stuurt meetverzoeken naar jouw tagging server. Google beschrijft het in zijn documentatie over server-side tagging als een container die “draait op een server die jij beheert”, in je eigen Google Cloud-project of een andere omgeving. In die container zetten zogenoemde clients de binnenkomende verzoeken om naar events, waarna tags die events doorsturen naar de platformen die je kiest. Tot je iets doorstuurt, heb alleen jij toegang tot die data.
Client-side en server-side naast elkaar
| Client-side tagging | Server-side tagging | |
|---|---|---|
| Waar draaien de tags? | In de browser van de bezoeker | In een server container die jij beheert |
| Scripts op je site | Eén per tool | Vooral de Google-tag of web container |
| Cookies | Vaak door JavaScript gezet, korter houdbaar | Door je server gezet op je eigen (sub)domein |
| Controle over gedeelde data | Laag: elk script stuurt zelf | Hoog: je filtert en verrijkt vóór het doorsturen |
| Kosten en onderhoud | Geen hosting | Hosting, monitoring en beheer |
Server-side tagging of server-side tracking?
In de praktijk gebruiken marketeers beide termen door elkaar. Strikt genomen is server-side tagging de techniek (tags in een server container), en server-side tracking het resultaat (meten via een server in plaats van rechtstreeks vanuit de browser). Wie “server side tracking” zoekt, zoekt meestal dezelfde opzet. Voor de specifieke Google Ads-kant, met enhanced conversions en offline conversies, lees je server-side tracking voor Google Ads.
Waarom kiezen bedrijven voor server-side tagging?
Controle over wat je deelt
Elke tag in de browser stuurt standaard alles wat hij kan opvangen: URL’s, referrers, soms zelfs formuliervelden in een querystring. In een server container zie je elk verzoek binnenkomen en beslis je per platform welke velden doorgaan. Een IP-adres inkorten, een e-mailadres uit een URL strippen of een veld enkel naar Google Ads sturen en niet naar Meta: dat regel je op één plek.
Duurzamere first-party cookies
Draait je tagging server op een subdomein van je eigen site (bijvoorbeeld meten.jouwdomein.be), dan zet die server cookies in een first-party context. Google noemt dat in zijn handleiding over een eigen domein een best practice die je “de veiligheids- en duurzaamheidsvoordelen van server-set cookies” geeft. Op het standaarddomein van je cloudprovider draait de server in een third-party context en kan hij enkel JavaScript-cookies zetten. Meer over waarom dit telt, lees je in ons stuk over first-party data.
Minder scripts in de browser
Elke extra pixel kost laadtijd. Door tools als Meta en LinkedIn via de server te bedienen in plaats van via een eigen script, verdwijnt een deel van die JavaScript uit de browser. Reken wel niet op wonderen: de Google-tag of web container blijft nodig om de data te verzamelen.
Een plek om data te verrijken
Een server container kan events aanvullen met gegevens die de browser niet kent, zoals een marge per product of een leadstatus. Zo stuur je Google Ads een conversiewaarde die dichter bij omzet ligt.
Server-side tagging en consent (GDPR)
De Gegevensbeschermingsautoriteit is duidelijk: een cookie voor analytische doeleinden is niet strikt noodzakelijk en vraagt dus toestemming, en je moet die toestemming even makkelijk kunnen intrekken als geven. In Nederland hanteert de Autoriteit Persoonsgegevens dezelfde lijn. Dat verandert niet doordat de data via jouw server loopt.
Wat wel verandert: je kan de consentstatus meesturen naar de server container en daar per tag respecteren. Google werkt met vier consenttypes: ad_storage, analytics_storage, ad_user_data en ad_personalization. In de basic-variant laden Google-tags pas na een keuze in de banner, in de advanced-variant laden ze meteen met een standaardstatus “denied” en sturen ze metingen zonder cookies. Hoe je dat voor Google Ads inricht, staat in consent mode v2 voor Google Ads.
Server-side tagging opzetten in 7 stappen
1. Maak een inventaris van je tags en consent
Lijst op welke tags vandaag draaien, welke events ze meten en onder welke consentcategorie ze vallen. Dit is ook het moment om op te ruimen: dubbele GA4-tags en vergeten pixels verhuis je niet mee. Zonder deze stap kopieer je bestaande fouten naar een duurdere omgeving.
2. Maak een server container aan in Google Tag Manager
Kies in Google Tag Manager voor een nieuwe container van het type “Server”. De container komt standaard met een GA4-client en GA4-tags, zodat je meteen GA4-verkeer kan ontvangen.
3. Kies je hosting
Je kan de tagging server automatisch laten aanmaken in Google Cloud (Cloud Run) of zelf provisionen. Google raadt aan om in productie minstens twee instanties te draaien, zodat je geen data verliest bij een storing, en vermeldt daar een richtprijs per server per maand die bij Google zelf wordt afgerekend. Je hebt daarnaast een aparte preview server nodig om te kunnen testen. Wie geen eigen cloudbeheer wil, kiest voor een beheerde host zoals Stape: minder onderhoud, wel een extra leverancier in je verwerkingsregister.
4. Koppel een eigen subdomein
Richt een subdomein in zoals meten.jouwdomein.be en laat het naar je tagging server wijzen, of serveer de container via een pad op je eigen domein. Pas dan profiteer je van server-set cookies in een first-party context. Vergeet je deze stap, dan draait alles in een third-party context en mis je een groot deel van het voordeel.
5. Stuur je web container naar de server
In je web container (of de Google-tag) stel je de server-URL in, zodat GA4-hits naar jouw tagging server gaan in plaats van rechtstreeks naar Google. Werk je met een data layer, dan blijft die de bron van je events en parameters: de server krijgt wat de web container doorgeeft.
6. Zet clients en tags op in de server container
Voeg per platform de juiste tag toe: GA4, Google Ads conversies, de Meta Conversions API, eventueel LinkedIn. Stuur je hetzelfde event zowel via de browser als via de server naar Meta, geef dan een gedeelde event-ID mee zodat Meta kan dedupliceren. Laat elke tag enkel afvuren wanneer de consentstatus dat toelaat.
7. Test, zet live en monitor
Test elke wijziging in preview, zowel in de web container als in de server container. In Google Tag Assistant zie je welke tags afvuren en met welke data, in de preview van de server container zie je per binnenkomend verzoek welke client het opving en welke tags het doorstuurden. Controleer daarna in GA4, Google Ads en Meta Events Manager of de events met de juiste waarden binnenkomen. Na livegang monitor je of de servers bereikbaar blijven en of je eventaantallen stabiel blijven.
Veelgemaakte fouten bij server-side tagging
- Geen eigen subdomein. De server draait op het standaarddomein van de cloudprovider, waardoor de cookies third-party blijven.
- Dubbel tellen. De oude browsertags blijven aan staan naast de nieuwe server-side tags, of Meta krijgt browser- en serverevents zonder gedeelde event-ID.
- Consent vergeten aan serverkant. De banner werkt in de browser, maar de server stuurt alles door ongeacht de keuze.
- Eén instantie in productie. Bij een storing gaat je meetdata verloren tot iemand het merkt.
- Een rommelige basis meeverhuizen. Server-side tagging repareert geen slechte events of een ontbrekende data layer. Lees ook de klassiekers in veelgemaakte fouten in Google Analytics tracking.
Hoe controleer je of je server-side opzet werkt?
- Open de preview van je web container en controleer in Tag Assistant of de GA4-hits naar je eigen subdomein vertrekken.
- Open de preview van je server container en kijk per verzoek welke client het opving en welke tags afvuurden, met welke statuscode.
- Controleer in GA4 DebugView of de events binnenkomen met de juiste parameters.
- Gebruik de testevents in Meta Events Manager en de conversiediagnose in Google Ads.
- Vergelijk na een week de eventaantallen met je oude opzet en met je CRM.
Twijfel je of je huidige opzet klopt voor je eraan begint? Een tracking audit brengt eerst de bestaande tags, consent en dataverschillen in kaart.
Wanneer loont server-side tagging, en wanneer niet?
Het loont vooral als je serieus budget in Google Ads of Meta steekt en die platformen betere signalen nodig hebben, als je meerdere platformen bedient vanuit dezelfde events, of als je strikt wil bepalen welke data je deelt. Voor een kleine B2B-site met een handvol aanvragen per maand en één GA4-property is een propere client-side opzet met correcte conversie tracking vaak voldoende. Begin dan daar.
In onze setups beginnen we zelden met de server. Bij Suivo zat de winst in één robuuste formulier-listener en een schone data layer, bij Kaizo in één duidelijke conversie, de geboekte demo, die GA4, Google Ads en Meta op dezelfde manier zien. Server-side tagging bouwt op zo’n basis verder, het vervangt hem niet.
Veelgestelde vragen
Is server-side tagging GDPR-conform?
Niet automatisch. Het geeft je wel betere middelen om GDPR-conform te werken: je ziet alle uitgaande data, kan velden filteren en kan per tag de consentstatus respecteren. De verplichting om toestemming te vragen voor analytische en advertentiecookies blijft gewoon gelden.
Heb ik nog een gewone Google Tag Manager container nodig?
Ja, in vrijwel elke opzet. De web container of de Google-tag verzamelt de events in de browser en stuurt ze naar je server. De server container verwerkt en verdeelt ze. Meer over de basis lees je in ons artikel over Google Tag Manager.
Omzeilt server-side tagging adblockers?
Gedeeltelijk, en dat is niet het doel. Via een eigen subdomein worden verzoeken minder vaak geblokkeerd dan bekende third-party domeinen, maar bezoekers die geen toestemming geven, mag je ook server-side niet meten met cookies.
Wat kost server-side tagging?
De kosten bestaan uit hosting (Google Cloud of een beheerde host) en uit de tijd voor opzet, testen en onderhoud. Hoeveel werk dat is, hangt af van het aantal platformen, je consentopzet en de staat van je huidige tracking. Wij werken daarom op aanvraag, na een korte analyse.
Wat is het verschil met server-side tracking voor Google Ads?
Server-side tagging is de brede infrastructuur voor al je platformen. Voor Google Ads komen daar specifieke technieken bij, zoals enhanced conversions en offline conversies uit je CRM. Die lees je in server-side tracking voor Google Ads en enhanced conversions instellen.
Server-side tagging laten opzetten?
We zetten server-side tagging op als onderdeel van een volledige meetopzet: inventaris, server container, eigen subdomein, consent en een testronde per platform. Bekijk hoe onze tracking specialist werkt, of start met een tracking audit als je eerst wil weten waar je meting vandaag lekt. Liever meteen overleggen? Neem contact op.
Gratis website-scan
Geef je website in en krijg binnen enkele minuten een automatische scan met concrete technische en SEO-verbeterpunten. Geen verkooppraatje.
Je gegevens gebruiken we alleen voor je scan. Geen spam, uitschrijven kan altijd.