Server-side tagging: zo zet je het op met Google Tag Manager

Server-side tagging stuurt je meetdata eerst naar een server die jij beheert.

Je tags draaien dus niet langer allemaal in de browser van je bezoeker. De browser stuurt één datastroom naar een Google Tag Manager server container, die de data doorstuurt naar GA4, Google Ads, Meta of andere platformen.

Het verdict: server-side tagging geeft je controle over wat je deelt en duurzamere first-party cookies. Het is geen manier om consent te omzeilen, en het repareert geen slechte basis.

Het resultaat: minder scripts op je site, meer controle en betere signalen voor je advertentieplatformen.

Hieronder: hoe het werkt, wanneer het loont en een stappenplan in 7 stappen.

Wat is server-side tagging?

Server-side tagging verplaatst je tags van de browser naar een server container die jij beheert.

Hoe klassieke tagging werkt

Bij klassieke, client-side tagging laadt elke tool zijn eigen script in de browser. Denk aan de Google-tag, de Meta-pixel en de LinkedIn Insight Tag.

Elk script stuurt zelf data naar zijn eigen server. Je hebt weinig zicht op wat er precies vertrekt.

Wat er verandert met een server container

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”. Dat kan in je eigen Google Cloud-project of een andere omgeving.

In die container werken twee onderdelen samen:

• Clients: zetten binnenkomende verzoeken om naar events.
• Tags: sturen die events door naar de platformen die je kiest.

Tot je iets doorstuurt, heb alleen jij toegang tot die data.

Zo loopt die datastroom:

Client-side en server-side naast elkaar

Het verschil in vijf punten:

Kort: client-side is goedkoper, server-side geeft je de controle.

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. Server-side tracking is het resultaat: meten via een server in plaats van rechtstreeks vanuit de browser.

Wie “server side tracking” zoekt, zoekt meestal dezelfde opzet.

Waarom kiezen bedrijven voor server-side tagging?

Om vier redenen: controle, duurzamere cookies, minder scripts en verrijkte data.

1. Controle over wat je deelt

Elke tag in de browser stuurt standaard alles wat hij kan opvangen. Denk aan URL’s, referrers en soms zelfs formuliervelden in een querystring.

In een server container zie je elk verzoek binnenkomen. Je beslist per platform welke velden doorgaan.

Dit regel je op één plek, bijvoorbeeld:

• een IP-adres inkorten
• een e-mailadres uit een URL strippen
• een veld enkel naar Google Ads sturen en niet naar Meta

2. 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. Daar kan hij enkel JavaScript-cookies zetten.

Waarom dit telt, lees je in ons stuk over first-party data en in de uitleg over third-party cookies.

3. Minder scripts in de browser

Elke extra pixel kost laadtijd. Door tools als Meta en LinkedIn via de server te bedienen, verdwijnt een deel van die JavaScript uit de browser.

Let op: reken niet op wonderen. De Google-tag of web container blijft nodig om de data te verzamelen.

Wil je vooral snelheid winnen, kijk dan ook naar je website sneller maken.

4. Een plek om data te verrijken

Een server container kan events aanvullen met gegevens die de browser niet kent. Denk aan een marge per product of een leadstatus.

Zo stuur je Google Ads een conversiewaarde die dichter bij omzet ligt.

Hoe zit het met server-side tagging en consent (GDPR)?

Consent blijft net zo verplicht als bij client-side tagging.

Wat de toezichthouder zegt

De Gegevensbeschermingsautoriteit is duidelijk: een cookie voor analytische doeleinden is niet strikt noodzakelijk. Hij vraagt dus toestemming.

Je moet die toestemming bovendien even makkelijk kunnen intrekken als geven. In Nederland hanteert de Autoriteit Persoonsgegevens dezelfde lijn.

Dat verandert niet doordat de data via jouw server loopt. Of je een banner nodig hebt, lees je in cookiebanner verplicht in België.

Wat wel verandert: consent per tag

Je kan de consentstatus meesturen naar de server container en daar per tag respecteren.

Voor meting en advertenties werkt Google met vier consenttypes:

• ad_storage
• analytics_storage
• ad_user_data
• ad_personalization

Basic of advanced consent mode

Er zijn twee varianten:

• Basic: Google-tags laden pas na een keuze in de banner.
• Advanced: tags laden meteen met een standaardstatus “denied” en sturen metingen zonder cookies.

Hoe je dat voor Google Ads inricht, staat in consent mode v2 voor Google Ads.

Hoe zet je server-side tagging op in 7 stappen?

Van inventaris tot een geteste productie-opzet, in deze volgorde:

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. Een audit-checklist voor conversietracking helpt je daarbij.

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. Zo kan je meteen GA4-verkeer ontvangen.

Zo ziet die keuze eruit in Tag Manager:

Tip: geef de container een naam met je domein en “server”. Zo haal je web en server niet door elkaar.

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. Zo verlies je geen data bij een storing.

Prijs: Google rekent in die standaardconfiguratie ongeveer 45 dollar per server per maand (USD, gecontroleerd 21 oktober 2026). Met twee instanties kom je dus rond 90 dollar per maand, rechtstreeks bij Google 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. Dat betekent minder onderhoud, maar 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. Je kan de container ook via een pad op je eigen domein serveren.

Pas dan profiteer je van server-set cookies in een first-party context.

Google zet de opties naast elkaar:

• Subdomein: enkel je DNS-records aanpassen.
• Zelfde domein (pad): een CDN of load balancer moet verzoeken doorsturen.
• Standaarddomein: werkt meteen, maar zonder voordelen van server-set cookies.

Let op: vergeet je deze stap, dan draait alles in een third-party context. Je mist dan 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. Zo gaan GA4-hits naar jouw tagging server 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.

Welke events je best meet, lees je in event tracking uitgelegd.

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 verzoek welke client het opving en welke tags het doorstuurden.

Controleer daarna of de events met de juiste waarden binnenkomen in GA4, Google Ads en Meta Events Manager.

In Google Ads kijk je naar de conversieactie die je campagnes stuurt. Zo staat onze eigen contactformulier-conversie ingesteld:

De conversieactie voor ons contactformulier in ons eigen Google Ads-account, oktober 2026. Ze staat op primair, dus campagnes optimaliseren op echte aanvragen.

Komt die actie na de overstap nog met dezelfde aantallen binnen? Dan werkt je server-side stroom voor Google Ads.

Na livegang monitor je of de servers bereikbaar blijven en of je eventaantallen stabiel blijven.

Wat zijn veelgemaakte fouten bij server-side tagging?

Vijf fouten zien we het vaakst:

• Geen eigen subdomein. De server draait op het standaarddomein van de cloudprovider, waardoor de cookies third-party blijven.
• Dubbel tellen. Oude browsertags blijven aan naast de nieuwe, of Meta krijgt events zonder gedeelde event-ID.
• Consent vergeten aan serverkant. De banner werkt in de browser, maar de server stuurt alles door.
• 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 ontbrekende data layer.

De klassiekers aan browserkant staan in veelgemaakte fouten in Google Analytics tracking.

Hoe controleer je of je server-side opzet werkt?

Loop deze vijf checks af, in deze volgorde:

1. Open de preview van je web container en controleer in Tag Assistant of de GA4-hits naar je eigen subdomein vertrekken.
2. Open de preview van je server container en kijk per verzoek welke client het opving en welke tags afvuurden, met welke statuscode.
3. Controleer in GA4 DebugView of de events binnenkomen met de juiste parameters.
4. Gebruik de testevents in Meta Events Manager en de conversiediagnose in Google Ads.
5. Vergelijk na een week de eventaantallen met je oude opzet en met je CRM.

Google Ads en GA4 tellen conversies anders. Kleine verschillen zijn dus normaal, zie verschil tussen conversies in Google Ads en GA4.

In het overzicht van alle conversies zie je in één oogopslag welke acties meetellen:

Alle conversies in ons eigen Google Ads-account, 1 tot 16 oktober 2026. Eén primaire actie: het contactformulier.

Staat er na de overstap ineens een tweede, dubbele actie? Dan tel je dubbel.

Twijfel je of je huidige opzet klopt voor je eraan begint?

Een tracking audit brengt eerst je tags, consent en dataverschillen in kaart.

Wanneer loont server-side tagging, en wanneer niet?

Het loont vooral als je advertentieplatformen betere signalen nodig hebben, of als je strikt wil bepalen wat je deelt.

Wanneer het loont

Drie situaties:

• Budget: je steekt serieus budget in Google Ads of Meta.
• Meerdere platformen: je bedient ze vanuit dezelfde events.
• Datacontrole: je wil strikt bepalen welke data je deelt.

Wanneer een propere basis volstaat

Voor een kleine B2B-site met een handvol aanvragen per maand en één GA4-property is een propere client-side opzet vaak voldoende.

Zorg dan eerst voor correcte conversie tracking. Begin daar.

Vuistregel: zolang je basis niet klopt, levert een server container alleen extra kosten op.

Wat we in onze setups zien

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 zat ze 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. Op Cloud Run rekent Google ongeveer 45 dollar per server per maand, met minstens twee servers in productie. Hoeveel werk de opzet 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. Wil je eerst weten waar je meting vandaag lekt? Start met een tracking audit.

Liever meteen overleggen? Neem contact op.