Naslag
Wat is server-side tagging?
Op deze pagina
Het korte antwoord
Bij gewone tagging stuurt de browser van je bezoeker de metingen rechtstreeks naar Google en Meta.
Bij server-side tagging stuurt hij ze eerst naar een adres op je eigen domein, en van daaruit gaan ze verder.
Dat adres is een server die jij beheert. Wat er vanaf daar naar een derde partij gaat, bepaal jij.
Hoe gaat het nu, zonder?
Bij de klassieke opzet laadt je site voor elke dienst een stukje code dat vanuit de browser rechtstreeks naar Google, Meta of TikTok stuurt. Dat werkt, maar het gebeurt op de plek waar je de minste controle hebt: een blokkeerder houdt het verzoek tegen, de tracking-preventie van de browser gooit cookies of verzoeken weg, en soms is de bezoeker al weg voordat het verzoek de deur uit is. Wat er wegvalt, zie je niet — het komt gewoon niet aan.
Wat verandert er met server-side?
Server-side tagging zet een station tussen de browser en de diensten: je eigen subdomein, bijvoorbeeld t.jouwsite.nl. De browser stuurt zijn gegevens daarheen — naar een adres dat bij je eigen site hoort — en die server beslist wat er vervolgens naar Google, Meta of TikTok gaat. Het verkeer verhuist van een plek die je niet beheert naar een plek die je wél beheert. De vorm van het plaatje verandert nauwelijks; wie de verzoeken doet en waar ze langskomen, verandert wel.
Server-side tagging of server-side tracking?
Je komt beide woorden tegen, vaak door elkaar en meestal voor hetzelfde ding. Er zit wel een verschil in, en het is de moeite waard omdat het bepaalt waar je naar zoekt.
Server-side tracking is het bredere woord: het meten gebeurt op een server in plaats van in de browser. Dat kan met een tagbeheerder, maar net zo goed met een eigen koppeling die rechtstreeks met de API van Google of Meta praat.
Server-side tagging is het smallere geval: server-side tracking waarbij er een tagbeheerder op die server draait — in de praktijk bijna altijd de servercontainer van Google Tag Manager. De tags die eerst in de browser stonden, staan nu daar.
Tagyard draait dat tweede. Wie op server-side tracking zocht en hier terechtkwam zit dus goed: dit is er een vorm van, en het is de vorm die je zonder eigen programmeerwerk in gebruik neemt.
Zoek je de kortere vergelijking met de klassieke opzet, dan staat die apart: client-side versus server-side tracking.
Wat levert het op? De voordelen op een rij
Minder wordt onderweg tegengehouden
Het verzoek gaat naar een adres op je eigen domein, dus blokkeerlijsten die op bekende trackerdomeinen werken raken het niet. Wat een blokkeerder wél kan blijven zien is het patroon van de aanvraag: het pad, de vorm van de gegevens, hoe vaak het gebeurt.
Je bepaalt wat er weggaat
De gegevens komen eerst bij jouw server binnen. Daar kun je zien en beperken wat er naar een derde partij gaat — velden weglaten, afronden, of een bestemming helemaal uitzetten. Dit is het voordeel dat het meest onderschat wordt, en het enige dat volledig binnen je eigen controle ligt.
Cookies worden door je eigen server gezet
Niet door javascript in de browser, maar door je server in het antwoord. Dat helpt — met de grens die in de volgende sectie staat, en die grens is belangrijker dan er meestal van gemaakt wordt.
Wat lost het niet op?
Hier gaan de meeste verwachtingen mis. Server-side tagging verplaatst waar je metingen langsgaan; het verandert niets aan de regels, aan de kwaliteit van je bron, of aan wat een browser besluit. Vier dingen om nuchter over te zijn.
Safari kapt je cookies alsnog af
Dit is de belangrijkste nuance en de meest genegeerde, en hij geldt voor elke gehoste opstelling — die van ons net zo goed.
WebKit behandelt een first-party subresource die via een CNAME ergens anders uitkomt als third-party CNAME cloaking, en kapt elke cookie in dat antwoord af op zeven dagen. Een A-record ontsnapt daar sinds Safari 16.4 niet automatisch aan: WebKit vergelijkt het IP-adres van de meetserver met dat van de website en past dezelfde grens toe als ze minder dan de helft van de adresbits delen — zestien voor IPv4. Zelf hosten op een aparte VPS voldoet daar vrijwel nooit aan.
Wat je er wél mee wint: op Chrome en Firefox geldt die grens niet, en een cookie die je server zet valt niet om zodra een blokkeerder het javascript tegenhoudt. Wat je er niet mee wint is een langlevende cookie op Safari.
Bronnen: WebKit, “CNAME Cloaking and Bounce Tracking Defense” (2020), en WebKit pull request 5347 (2022).
Je weet niet meer over je bezoeker dan de browser doorgaf
Server-side verplaatst waar de gegevens langsgaan; het verzint er niets bij. Wat de browser niet heeft gestuurd — omdat de bezoeker geen toestemming gaf, of omdat je site het niet meet — komt er aan de serverkant niet alsnog bij.
Een verkeerd meetplan wordt er niet beter van
Meet je de verkeerde gebeurtenis, dan meet je hem hierna nauwkeuriger verkeerd. De kwaliteit begint bij wat je site stuurt, niet bij waar het langskomt.
Toestemming blijft gelden
Server-side tagging is geen omweg om de cookiebanner heen. Het maakt het makkelijker om een toestemmingskeuze netjes door te geven, en dat is iets anders dan hem niet nodig hebben. Wie het als omweg verkoopt, verkoopt een probleem.
Wat heb je nodig om het in te stellen?
Een servercontainer in Tag Manager
In Google Tag Manager maak je naast je webcontainer een servercontainer aan. Daarin staat wat er met je metingen gebeurt zodra ze binnen zijn.
Een subdomein van je eigen domein
Een adres onder je eigen domein, bijvoorbeeld t.jouwsite.nl, waar het meetverkeer naartoe gaat.
Een DNS-record
Meestal een CNAME die dat subdomein naar je meetserver wijst. Op dat adres hoort een geldig certificaat te staan, anders weigert de browser de verbinding.
Ergens waar het draait
De servercontainer moet ergens staan. Dit is het enige van de vier dat geld kost, en de volgende sectie gaat erover.
Waar kun je het draaien?
Ruwweg drie manieren, en elke manier heeft een nadeel — ook de onze. Wie de aanbieders naast elkaar wil zien: server-side tracking tools vergeleken.
Bij Google, op Cloud Run
Je draait de servercontainer in je eigen Google Cloud-project. Dicht bij de bron en volledig in eigen beheer.
Nadeel: Bewerkelijk om goed te krijgen, en je betaalt per gebruik — waardoor je vooraf lastig weet wat het gaat kosten.
Zelf, op een eigen server
De standaardimage van Google op een VPS of een eigen machine, met je eigen certificaat ervoor.
Nadeel: Goedkoop in geld, duur in aandacht: certificaten, updates, en niemand die het merkt als het stilvalt.
Bij een partij die het draait
Een gehoste dienst zet de server voor je op en houdt hem draaiend. Stape, TAGGRS en Tagyard doen dit.
Nadeel: Een vast bedrag per maand, en je bent afhankelijk van die partij.
Wat kost het?
Zelf draaien kost vooral tijd, plus de rekening van je server of je cloudverbruik. Een gehoste opstelling begint rond de tien euro per maand voor een kleine site en loopt op met het aantal verzoeken. Concrete bedragen en volumes staan op de prijspagina.
Waar past Tagyard hierin?
Voor de duidelijkheid: dit stuk is geschreven door een partij die server-side tagging verkoopt. Lees het met die bril op.
Tagyard is de derde manier uit de vorige sectie — een gehoste dienst. Het verschil zit in twee dingen: het verkeerslog komt standaard mee, en een scherm zegt in gewone taal of je tracking werkt in plaats van dat je het uit logregels moet halen.
Of dat het verschil is dat jij zoekt, beoordeel je zelf. Wat Tagyard doet en voor wie staat op de homepage.