Wat is een gtm server container en hoe zet je die op

Een gtm server container verwerkt uw tracking events op een server die u zelf beheert, in plaats van in de browser van de bezoeker. Dat levert betrouwbaardere leadmetingen op, omdat data niet meer verloren gaat door adblockers of browserbeperkingen. In dit artikel doorloopt u het volledige stappenplan, van aanmaken tot productie, plus de privacy-checks die daarbij horen.

Kort samengevat:

  • Een server container verwerkt meetverzoeken op een eigen server, waardoor gegevens minder snel verloren gaan door adblockers en browserbeperkingen.
  • Het instellen vereist het koppelen van een eigen subdomein, het configureren van clients en tags, en het aanpassen van de website- of app-code met een server_container_url.
  • Keuzes tussen Cloud Run, App Engine en Docker beïnvloeden de controle, beheertijd en snelheid van de server provisioning.
  • Voor een betrouwbare leadmeting moet u minimaal twee tot drie instance draaien en zorgen voor monitoring, backup en correcte privacy-instellingen.
  • Een server container vereiste dataverwerking blijft onder de privacyregels van de ePrivacyrichtlijn en moet zorgvuldig worden ingericht met toestemming en databeheer.
Adworth
Meet leads waarop u kunt sturen
Adworth helpt dienstverleners en B2B-bedrijven met betrouwbare leadmeting voor Google Ads en Microsoft Ads.

Bekijk Adworth

Inhoudsopgave

Wat is een server container en hoe werkt hij intern

Een server container is een aparte Google Tag Manager-omgeving die op een server draait, niet in de browser. Waar een gewone webcontainer tags direct in de pagina van de bezoeker uitvoert, ontvangt een server container HTTP-requests en verwerkt die zelf, los van de klantensoftware.

Binnen die server container claimen clients de binnenkomende requests. Een client herkent bijvoorbeeld een GA4-meetverzoek, zet dat om naar een gestandaardiseerd event, en geeft dat event door aan de rest van de container. Vervolgens bepalen tags en triggers wat er met dat event gebeurt: doorsturen naar Google Ads, naar GA4, of naar een ander platform, eventueel met aanpassingen aan de data onderweg.

Het verschil met een client-side implementatie zit in wie de controle heeft. Bij client-side tagging bepaalt de browser, en daarmee ook browserextensies en trackingbescherming, wat er gebeurt met een meetverzoek. Bij server-side tagging loopt het verzoek eerst via uw eigen server, voordat het naar een derde partij gaat. Dat geeft u de mogelijkheid om data te filtering, te verrijken met CRM-informatie, of te vertragen tot een conversie daadwerkelijk bevestigd is, bijvoorbeeld na een telefoongesprek of een offerteaanvraag.

Voor leadgeneratie is dat verschil relevant: een formulierinzending of belafspraak is vaak pas na enige tijd een echte lead, en een server container geeft u de ruimte om die vertraagde bevestiging correct te verwerken.

Wat is een server container en hoe werkt hij intern — overview diagram

Waarom server-side tagging inzetten voor leadgeneratie

Voor bedrijven die op leads sturen, is meetnauwkeurigheid direct verbonden aan budgetbeslissingen. Een server container helpt op een paar concrete manieren.

Metingen lopen minder snel mis door adblockers en browserbeperkingen, omdat het verzoek via uw eigen domein gaat in plaats van via een extern trackingscript dat direct herkenbaar is als advertentietechnologie. In combinatie met first-party cookies op een eigen subdomein, blijft een bezoeker langer herkenbaar tussen sessies, wat de toewijzing van conversies aan de juiste campagne en zoekwoord verbetert.

Dat brengt ook een keerzijde met zich mee. Een server container is geen instelling die u eenmalig aanzet en dan loslaat: er draait een server die onderhoud, monitoring en updates vraagt, en die kosten met zich meebrengt, ook al zijn die voor de meeste leadgeneratie bedrijven beperkt. De investering betaalt zich vooral terug wanneer conversies nu nog stelselmatig verloren gaan, of wanneer u toe wil naar server-side conversietracking gekoppeld aan uw CRM. Voor een bedrijf met een klein websiteverkeer en een simpel contactformulier is de opbrengst kleiner dan voor een organisatie met lange salescycli en meerdere conversiepunten.

Stappenplan: server container instellen en eerste events verzenden

Het opzetten van een server container verloopt in een vaste volgorde. Google Developers beschrijft dit proces als: container aanmaken, server provisionen, domein koppelen, configureren, testen en publiceren.

  1. Maak een server container aan. Ga in Google Tag Manager naar Admin, kies Create container en selecteer bij Target de optie Server.
  2. Provision een tagging server. Dit kan automatisch via Google Cloud Run, of handmatig via App Engine of een Docker image.
  3. Provision ook een preview server. Een preview server is nodig om de container te kunnen testen voordat u live gaat, en moet dezelfde containerconfiguratie gebruiken als de tagging server, zoals de handmatige installatiehandleiding beschrijft.
  4. Koppel een eigen subdomein. Wijs bijvoorbeeld een subdomein zoals analytics.uwdomein.nl toe aan de tagging server, zodat verzoeken als first-party gelden.
  5. Configureer clients en tags. Voeg de GA4-client toe zodat binnenkomende meetverzoeken herkend worden, en stel de bijbehorende tags in die deze events doorsturen.
  6. Pas de website- of appconfiguratie aan. Voeg in gtag.js de parameter server_container_url toe, zodat metingen naar uw eigen server gaan in plaats van rechtstreeks naar Google.
  7. Test in Preview. Bekijk of events correct binnenkomen, welke client ze claimt, en of tags afvuren zoals bedoeld.
  8. Publiceer de container. Zet de wijzigingen live nadat u in preview heeft bevestigd dat alles werkt.

Een voorbeeld van de configuratie in gtag.js ziet er zo uit:

gtag('config', 'TAG_ID', {
  'server_container_url': 'https://analytics.uwdomein.nl'
});

Dit stuurt metingen naar uw eigen server container in plaats van direct naar een extern domein, wat de basis vormt voor betrouwbaardere conversiedata bij leadgeneratie.

Pro-tip: test eerst met één enkele tag, zoals de GA4-configuratietag, voordat u meer tags en triggers toevoegt: zo herleidt u sneller waar een probleem ontstaat als events niet doorkomen.

Deployment-opties vergeleken: Cloud Run, App Engine en handmatige Docker

Er zijn drie manieren om een tagging server te draaien, en de keuze hangt af van hoeveel controle u wil over infrastructuur.

Voor productiegebruik geeft de Cloud Run installatiehandleiding van Google Developers een paar concrete aanbevelingen. Configureer minimaal twee tot drie instances, zodat er redundantie is als een instance uitvalt of traag reageert. Koppel de server aan een first-party subdomein in plaats van het automatisch gegenereerde Cloud Run-adres, zodat cookies als first-party gelden. Let bij een handmatige Docker-opzet extra op de timeout-instellingen van uw load balancer: deze moeten langer dan twintig seconden zijn, anders lopen preview-sessies vast, zoals de handmatige setupgids beschrijft.

Wie kiest voor Cloud Run of App Engine, wint tijd bij het opzetten. Wie kiest voor Docker, wint controle over precies welke afhankelijkheden en beveiligingsinstellingen er draaien, tegen de prijs van meer beheerwerk.

Website configureren: gtag.js en de events die tellen voor leadmeting

Zodra de server container draait, moet de website of app weten waar events naartoe moeten. Dat gebeurt via de parameter server_container_url in de gtag.js-configuratie, zoals eerder beschreven. Vanaf dat moment lopen standaardmetingen, zoals pageviews, automatisch via uw eigen server.

Voor leadgeneratie zijn een paar events extra belangrijk, naast de standaardconfiguratie:

  1. Formulierinzendingen registreren als apart event, met het formuliertype als parameter, zodat u onderscheid kunt maken tussen een offerteaanvraag en een simpele contactvraag.
  2. Telefonie-events koppelen, bijvoorbeeld via call tracking, zodat een telefonisch contactmoment ook als conversie meetelt.
  3. CRM-doorsturing inrichten, zodat een lead die later in het verkoopproces alsnog klant wordt, achteraf als offline conversie teruggekoppeld kan worden naar het advertentieplatform.

Voor eigen events die niet standaard door een client herkend worden, kan een sendEvent()-functie gebruikt worden, zoals Google Developers toont in een voorbeeld met een klikevent.

Test elke aanpassing in Preview mode, en controleer daarnaast of het /metrics/healthy endpoint van uw server een gezonde status teruggeeft: dat endpoint bevestigt dat de container actief is en verzoeken kan verwerken.

Productiechecklist: domein, instances en monitoring

Voordat een server container klaar is voor productie, zijn er een paar punten die niet overgeslagen mogen worden.

  1. Koppel een eigen subdomein aan de tagging server, zodat cookies als first-party gelden in plaats van als cookies van een externe partij.
  2. Zet de container in productiemodus in plaats van in testmodus, zodra u zeker bent van de configuratie.
  3. Draai minimaal twee tot drie instances, zoals Google Developers aanraadt voor redundantie.
  4. Richt logging en health checks in, zodat uitval of foutmeldingen snel opgemerkt worden.
  5. Documenteer een update- en rollbackproces, zodat een wijziging die problemen geeft snel teruggedraaid kan worden.

Minimaal twee tot drie instances wordt door Google Developers genoemd als redundantieadvies voor een productieomgeving: dat voorkomt dat een enkele instance een bottleneck wordt bij pieken in verkeer.

Een server container verandert niets aan de privacyregels die op tracking van toepassing zijn. De EDPB-richtlijnen 2/2023 over de technische scope van artikel 5(3) van de ePrivacy-richtlijn leggen uit dat het plaatsen van of toegang krijgen tot identifiers zoals IP-adressen, headers en session ID’s onder deze regelgeving kan vallen, ook wanneer dat via een server gebeurt in plaats van rechtstreeks via een browserscript.

Voor de praktijk betekent dit een paar concrete aandachtspunten:

Pro-tip: behandel een server container nooit als een manier om consentregels te omzeilen: de richtlijnen richten zich op wat er technisch gebeurt met identifiers, niet op waar de verwerking plaatsvindt.

Preview en troubleshooting: veelvoorkomende issues

Een aantal problemen komt vaak terug bij het opzetten van een server container.

Adworths praktijkperspectief op server-side tagging voor leadgeneratie

Er zijn bureaus die sinds lange tijd uitsluitend Google Ads en Microsoft Ads voor leadgeneratie beheren, zonder Smart Bidding en zonder Performance Max. Server-side tagging via GTM en GA4 kan in zo’n aanpak passen, omdat het leadkwaliteit meetbaar maakt in plaats van geschat.

Wij adviseren een migratie naar server-side pas wanneer een klant aantoonbaar conversies verliest door adblockers of browserbeperkingen, of wanneer offline conversie-import vanuit het CRM nodig is voor langere salescycli. Voor een simpel contactformulier met weinig verkeer is de investering vaak niet in verhouding tot de opbrengst.

— Arno Kooijman

Hulp bij server-side tagging en betere leadmeting

Sommige bureaus koppelen server-side conversiemeting en GA4-implementatie direct aan hun manier van Google Ads beheren: handmatig, met dagelijkse controle, zonder geautomatiseerde biedstrategieën.

Adworth

Er wordt gewerkt met B2B-bedrijven en dienstverleners die leads genereren via Google Ads en die klaar zijn voor een preciezere meting van wat een lead daadwerkelijk waard is.

Pro-tip: vraag bij twijfel eerst een technische check van uw huidige meetopzet, voordat u investeert in een volledige server-side migratie.

Bekijk onze dienstverlening op de dienstenpagina van Adworth of neem contact op om te bespreken wat server-side tagging voor uw leadmeting kan betekenen.

Officiële documentatie en nuttige handleidingen

Voor verdere technische verdieping zijn de officiële Google Developers overzichtspagina over server-side tagging, de EDPB-richtlijnen over ePrivacy en de praktische stappen in dit artikel van Frankwatching een goed startpunt.

Dit artikel bevat algemene informatie en vervangt niet het advies van een gekwalificeerde advocaat. Raadpleeg een gekwalificeerde juridische professional over uw eigen situatie voordat u op basis van deze inhoud handelt.

Bronnen

Veelgestelde vragen

Wat is een server container in Google Tag Manager?

Een server container is een Google Tag Manager omgeving die op een eigen server draait in plaats van in de browser van de bezoeker. Hij ontvangt meetverzoeken, verwerkt die via clients en tags, en stuurt de resulterende events door naar platforms zoals GA4 of Google Ads.

Wat is het verschil tussen een webcontainer en een servercontainer in GTM?

Een webcontainer draait tags direct in de browser van de bezoeker, terwijl een servercontainer meetverzoeken eerst via een eigen server verwerkt. Dat laatste geeft meer controle over welke data doorgestuurd wordt en vermindert het effect van browserbeperkingen op de meting.

Hoe maak je een server container aan in Google Tag Manager?

U maakt een server container aan door in Google Tag Manager naar Admin te gaan, Create container te kiezen en bij Target de optie Server te selecteren. Daarna provisioneert u een tagging server, koppelt u een eigen subdomein en configureert u de gewenste clients en tags, zoals beschreven in de officiële setupgids.

Wat betekent de container-ID in Google Tag Manager?

De container-ID is de unieke code die Google Tag Manager toewijst aan een specifieke container, zowel voor web als voor server. Deze ID gebruikt u om de container te koppelen aan uw website of app, bijvoorbeeld in de gtag.js-configuratie of in de servercontainerinstellingen.

Aanbevelingen