Wat is server-side tracking?
De korte versie: je haalt het verzamelen van analytics- en advertentie-events weg uit de browser van de bezoeker en verplaatst het naar een server die jij beheert. De lange versie gaat over waarom dat uitmaakt, wat het werkelijk oplevert, en wanneer het het geld niet waard is.
Server-side tracking verplaatst het verzamelen van events van de browser van de bezoeker naar een server die jij beheert. In plaats van een stuk of tien leveranciersscripts die elk hun eigen request vanaf de pagina afvuren, stuurt de browser één event naar je eigen domein, en stuurt een server container dat door naar GA4, Meta, Google Ads en waar je verder maar heen wilt. Omdat dat request first-party is en het doorsturen buiten de browser gebeurt, kunnen adblockers er niet op matchen, gelden de cookielimieten van Safari er niet voor, en heb je één plek om consent af te dwingen en persoonsgegevens te verwijderen voordat er iets weggaat.
Wat het werkelijk herstelt, en wat niet
Geblokkeerde requests komen terug, omdat de browser niet langer met googletagmanager.com of connect.facebook.net praat. De cookielevensduur verbetert, omdat identifiers door een server gezet worden in plaats van door JavaScript, en dat haalt ze uit de zevendagenlimiet van Safari. Wat níet terugkomt is iedereen die consent geweigerd heeft — server-side is geen omweg daaromheen, en elke leverancier die anders suggereert verkoopt je een risico in plaats van een oplossing.
Het deel dat bepaalt of het werkt
Een server container die GA4 doorstuurt en verder niets herstelt bijzonder weinig. Het herstel komt uit wat je eromheen bouwt: een Conversions API-laag zodat Meta en de rest hun events ook server-side krijgen, deduplicatie zodat een browser-pixel en een server-event samenvallen tot één conversie, en first-party identiteit zodat terugkerende bezoekers herkenbaar blijven. De meeste teleurstellende implementaties zijn teleurstellend omdat ze bij de container gestopt zijn.
Wat het kost om te draaien
Voor de meeste sites onder vijf miljoen events per maand is de compute $25–80 per maand op Cloud Run of vergelijkbaar. Managed hosting bij een leverancier ligt ruwweg tussen $20 en $200, afhankelijk van volume. De grotere kostenpost is de bouw en het onderhoud, en de grootste verborgen kostenpost is dat niemand het merkt als het stukgaat — wat geruisloos gebeurt, want een kapotte container geeft nog steeds netjes 200 terug.
Wanneer het het niet waard is
Onder ongeveer tienduizend sessies per maand betaalt het herstel de draaikosten niet terug. Geef je niets uit aan betaalde media, dan koopt betere attributie je niets om op te sturen. En is je verkeer overwegend niet-EU en niet-Safari, dan gelden de twee grootste verliesposten nauwelijks voor je. Een lichtere eerste stap is dan Google Tag Gateway, dat je first-party serving geeft zonder container om te beheren.
- 01 Tel je maandelijkse sessies — onder de ~10.000 klopt de rekensom zelden
- 02 Kijk welk deel van je verkeer Safari of EU is; daar concentreert het verlies zich
- 03 Kijk naar je advertentiebudget: herstel is alleen waard wat het betere bieden oplevert
- 04 Controleer of je huidige setup al Conversions API-events stuurt, niet alleen GA4
- 05 Vraag je af wie het zou merken als de pipeline stopt, en hoe lang dat zou duren
Is server-side tracking hetzelfde als server-side GTM? +
Server-side GTM is één manier om het te doen — het server-containerproduct van Google. Server-side tracking is de aanpak in het algemeen, en kan ook met een eigen collector, een CDP, of een platform als Stape, Addingwell of Taggrs.
Hoeveel data herstelt server-side tracking werkelijk? +
Gepubliceerde cijfers liggen tussen 18% en 45% meer conversie-events, afhankelijk van hoeveel van je verkeer Safari of EU is en hoe geblokkeerd je publiek is. Het enige cijfer dat iets betekent is dat van jou, gemeten op je eigen verkeer.
Kun je met server-side tracking om consent heen? +
Nee. Het verandert waar de verwerking plaatsvindt, niet of je er een grondslag voor nodig hebt. Goed gedaan maakt het consent juist makkelijker af te dwingen, omdat een geweigerd signaal het uitgaande request helemaal niet laat opbouwen.
Wordt mijn site er langzamer van? +
Meestal juist sneller. Meerdere leveranciersscripts vervangen door één lichte tag haalt JavaScript uit het kritieke pad, wat je Core Web Vitals doorgaans verbetert in plaats van schaadt.
Liever dat iemand dit gewoon goed doet?
Consent-handhaving in de container, gekoppeld aan je CMP, met audit trail — onderdeel van elke bouw die we opleveren.