Je betaalt voor clicks, je ziet conversies in Google Ads, en toch matcht er niets met wat je backend zegt. Als founder of marketingmanager van een mkb-bedrijf heb je geen tijd om drie dashboards met elkaar in discussie te laten gaan. Ergens lekt je data, en iedereen roept dat server side tracking de oplossing is.
Dat klopt deels. Server side tracking (ook geschreven als serverside tracking of server-side tracking) verplaatst je meetlogica van de browser van je bezoeker naar een server die jij beheert. Dat lost een aantal echte problemen op. Het lost ook een aantal dingen nadrukkelijk niet op, en dat vertellen leveranciers je er zelden bij.
In dit artikel lees je wat server side tracking precies is, wat het concreet met je data doet en wanneer het de investering waard is. Zoek je een vergelijking van tools, lees dan ons overzicht van server side tracking tools. Wil je meteen installeren, dan staat het stappenplan in onze handleiding voor server side tracking met GTM en TAGGRS. Dit stuk gaat over het wat, het waarom en het wanneer. Na het lezen weet je of je dit nu moet oppakken, of dat je je tijd beter ergens anders in steekt.
Wat is server side tracking?
Server side tracking is een meetmethode waarbij je website-events eerst naar een server sturen die jij beheert, en die server stuurt ze daarna door naar platformen zoals Google Ads, GA4 en Meta. De browser van je bezoeker praat dus niet meer rechtstreeks met tien advertentieplatformen, maar alleen met jouw eigen (sub)domein.
Vergelijk het met post versturen. Bij client-side tracking moet elke bezoeker zelf tien losse kaartjes naar tien verschillende bedrijven sturen, en een deel komt nooit aan. Bij server side tracking geeft de bezoeker één envelop af bij jouw balie, en jij verzorgt de verzending.
In de praktijk draait dit meestal op een server-side Google Tag Manager container, gehost op een subdomein van je eigen site (zoals tracking.jouwdomein.nl) bij Google Cloud of een managed aanbieder. De technische opzet staat uitgebreid beschreven in Google’s documentatie over server-side tagging.
Waarom je huidige tracking data lekt
Client-side tracking lekt data omdat browsers, ad blockers en consentkeuzes het uitvoeren van meetscripts steeds vaker beperken. Elk van die drie zorgt voor eigen gaten in je conversiedata.
De grootste boosdoener is Safari. Apple lanceerde Intelligent Tracking Prevention (ITP) in 2017 en blokkeert sinds 2020 third-party cookies volledig. Daarbovenop beperkt Safari cookies die via JavaScript worden gezet tot maximaal 7 dagen. Komt een klant na twee weken terug om te kopen, dan is de koppeling met de oorspronkelijke advertentieklik weg.
Daarnaast blokkeren ad blockers de bekende meetdomeinen van Google en Meta, en laden tags simpelweg niet als een pagina traag is of iemand wegklikt voordat het script vuurt. Het resultaat: je stuurt campagnes aan op onvolledige cijfers, zonder foutmelding.
Herken je dit beeld in je account? We schreven eerder over de meest voorkomende Google Ads trackingproblemen en hoe je ze opspoort.
De ontbrekende data is niet willekeurig
Het echte probleem is niet dát je conversies mist, maar wélke conversies je mist. De ontbrekende data is geen willekeurige steekproef, en daardoor optimaliseren je algoritmes op een vertekend beeld van je klant.
Mensen die ad blockers gebruiken zijn vaak technisch onderlegde bezoekers. Safari- en iOS-gebruikers vormen een eigen segment met eigen koopgedrag. Juist die groepen verdwijnen het vaakst uit je data.
Smart Bidding en Meta’s algoritmes leren dus van een scheef sample. Ze bieden vervolgens meer op de doelgroepen die je wél goed meet, en minder op de groepen die je mist. Je campagnes geven geen foutmelding. Ze presteren gewoon stilletjes minder dan ze zouden kunnen.
Wat server side tracking echt met je data doet
Server side tracking haalt een deel van je verloren conversies terug, verlengt de levensduur van je cookies en geeft je controle over welke data elk platform ontvangt. Geen van die drie voordelen is absoluut, dus laten we ze eerlijk langslopen.
1. Langere cookies, met een voetnoot. Safari beperkt cookies die via JavaScript worden gezet tot 7 dagen. Cookies die via een HTTP-response van je eigen server worden gezet, kunnen wél langer meegaan. Maar let op: wijst je subdomein via een CNAME naar een derde partij, of komt de response van een IP-adres van een derde partij, dan past Safari dezelfde 7-dagenlimiet toe. De manier waarop je je subdomein opzet, bepaalt dus of je dit voordeel echt pakt.
2. Minder blokkeerbaar, niet onblokkeerbaar. Browserextensies zien server-to-server verkeer niet en kunnen het dus niet tegenhouden. DNS-blockers zoals Pi-hole of AdGuard DNS kunnen jouw tracking-subdomein echter alsnog blokkeren zodra het op een filterlijst belandt. Wie beweert dat server side tracking onblokkeerbaar is, verkoopt je een sprookje.
3. Controle over je datastromen. Jij bepaalt welke velden naar welk platform gaan. Je kunt persoonsgegevens hashen of strippen voordat ze een derde partij bereiken, events verrijken met CRM-data en dubbele conversies wegfilteren. Voor Meta stuur je events via de Conversions API naast de pixel, met deduplicatie aan.
4. Een snellere site. Minder third-party scripts in de browser betekent minder laadwerk op het apparaat van je bezoeker. Prettige bijvangst, geen hoofdreden.
Wat server side tracking niet oplost
Server side tracking is geen manier om toestemming te omzeilen en het repareert geen kapotte meetopzet. Wie op je cookiebanner “alles weigeren” klikt, mag je ook server-side niet volgen. De AVG kijkt naar wat je verzamelt, niet waar je het verwerkt.
Een tweede harde waarheid: een kapotte datalayer verhuist gewoon mee. Als je events client-side verkeerd zijn geconfigureerd, stuur je dezelfde fouten voortaan via je server door. Draai je bijvoorbeeld op Shopify, zorg dan eerst dat je datalayer via de GTM custom pixel goed staat.
De volgorde is dus altijd: eerst je meting auditen, dan pas de architectuur verbouwen.
Coby’s Server-Side Beslisframework
Beantwoord deze vijf vragen om te bepalen of server side tracking nu de moeite waard is voor jouw bedrijf. Dit is het framework dat wij zelf bij audits gebruiken.
- Meet je datagat. Vergelijk over 30 dagen je conversies in Google Ads en Meta met je backend (Shopify, je CRM of je boekhouding). Ligt het verschil structureel boven de 15 tot 20 procent, dan is dat een duidelijk signaal.
- Check je verkeersmix. Heb je veel Safari- en iOS-verkeer, en komen klanten meestal meerdere keren terug voordat ze converteren? Dan raakt de 7-dagencookie van Safari je attributie nu al.
- Check je volume. Zit je onder de 10.000 sessies per maand? Wacht dan nog even. Maak eerst je client-side meting schoon: nette eventnamen, een kloppende datalayer, een goede GA4-inrichting en gefilterd test- en botverkeer, zoals Cookiebot-verkeer in GA4.
- Reken de kosten door. Reken op grofweg 30 tot 80 euro per maand aan hosting, plus enkele dagen implementatiewerk. Geef je meer dan zo’n 10.000 euro per maand uit aan advertenties, dan verdient betere data zich vrijwel altijd terug. Onder de 5.000 euro per maand is de rekensom een stuk minder vanzelfsprekend.
- Plan een parallel-run. Laat de oude en nieuwe setup twee tot vier weken naast elkaar draaien en vergelijk per kanaal de conversieaantallen. Pas als de cijfers overeenkomen, zet je de oude tags uit.
Kom je door alle vijf de vragen heen, kies dan je tool met onze tools-vergelijking en volg daarna de TAGGRS-handleiding hierboven.
Veelgemaakte fouten bij server side tracking
De meeste mislukte migraties gaan niet mis op techniek, maar op testen en verwachtingsmanagement. Dit zijn de fouten die wij het vaakst tegenkomen.
- De container op een standaard Google-URL laten draaien in plaats van op je eigen subdomein. Daarmee verlies je het first-party voordeel, en dat was nou net het punt.
- De Conversions API aanzetten zonder deduplicatie. Dezelfde aankoop telt dan dubbel, je ROAS lijkt ineens prachtig en je algoritme gaat overbieden op lucht.
- De client-side tags te vroeg uitzetten, voordat de parallel-run heeft bewezen dat de nieuwe data klopt.
- Stakeholders niet voorbereiden op de sprong in cijfers. Na de overstap stijgen je gerapporteerde conversies, omdat je méér meet, niet omdat je campagnes ineens beter draaien. Zet een annotatie in je dashboards, leg nieuwe baselines vast en vergelijk de eerste maanden niet klakkeloos met oude periodes.
- Server side tracking zien als privacy-vrijbrief. Consent blijft consent, en je consent management platform blijft gewoon nodig.
Hoe Coby dit aanpakt
Bij Coby begint elk traject met de meting, niet met de campagnes. We vergelijken eerst je frontend-data met je backend-cijfers, benoemen exact waar het lek zit en bepalen dan pas of server side tracking de juiste fix is. Soms is het antwoord namelijk: nog niet.
Die volgorde komt niet uit de lucht vallen. Marloes werkte als Agency Account Strategist voor Google in de Benelux en Nordics en zag daar te veel accounts die optimaliseerden op halve data. Daarom is tracking bij ons de fundering van elk account, geen bijzaak.
Wat dat oplevert? Voor De Eenhoorn (OneMeeting Group) bouwden we eerst de meting opnieuw op en daarna pas de campagnes. Resultaat: een ROAS van 1.500 procent en een leadvolume dat groeide van 2 à 3 per maand naar 4 à 5 per week. Niet omdat server side tracking magie is, maar omdat beslissingen op complete data simpelweg beter uitpakken. Meer over onze aanpak lees je bij data & analytics.
Conclusie
Server side tracking maakt je data completer, je cookies duurzamer en je datastromen controleerbaar, maar het is geen wondermiddel en geen consent-truc. Gebruik het beslisframework hierboven om te bepalen of jouw bedrijf er nu klaar voor is. Twijfel je over jouw situatie? Plan een gratis kennismaking van 30 minuten en we kijken samen naar je data.
Veelgestelde vragen over server side tracking
Wat is server side tracking?
Server side tracking is een meetmethode waarbij je website-events eerst naar een eigen server gaan, die ze vervolgens doorstuurt naar platformen zoals Google Ads en Meta. Zo ben je minder afhankelijk van de browser van je bezoeker en houd je controle over welke data elk platform ontvangt.
Wat is het verschil tussen server side tracking en de Meta Conversions API?
De Conversions API is één specifieke server-koppeling naar Meta. Server-side Google Tag Manager is de bredere infrastructuur die events naar meerdere platformen tegelijk kan routeren, waaronder via diezelfde Conversions API. Het één is de leiding, het ander is één van de bestemmingen.
Omzeilt server side tracking de AVG of mijn cookiebanner?
Nee. Server side tracking verandert waar data wordt verwerkt, niet wat je mag verzamelen. Weigert een bezoeker toestemming, dan mag je die bezoeker ook server-side niet tracken.
Wat kost server side tracking per maand?
Reken op ongeveer 30 tot 80 euro per maand aan hosting voor een site met gemiddeld verkeer, plus eenmalig enkele dagen implementatie- en testwerk. Managed aanbieders bundelen hosting en tooling, wat handig is als je geen cloud-ervaring in huis hebt.
Kunnen ad blockers server side tracking blokkeren?
Browserextensies niet, want die zien het server-to-server verkeer niet. DNS-blockers zoals Pi-hole kunnen je tracking-subdomein wél blokkeren zodra het op een filterlijst staat. Server side tracking is dus veel minder blokkeerbaar, maar niet onblokkeerbaar.
Wanneer heb ik server side tracking nog niet nodig?
Zit je onder de 10.000 sessies per maand met een eenvoudige funnel en beperkte ad spend, dan weegt de complexiteit meestal niet op tegen de winst. Maak dan eerst je client-side meting op orde en kom hier later op terug.
Geschreven door Marloes Slotboom, founder van Coby Agency. Laatst bijgewerkt: augustus 2026