Zelf gehoste server-side GTM versus managed hosting: wat het je operationeel echt kost

Korte samenvatting: Als je GTM server-side zelf host, draai je de gratis Docker-container van Google op je eigen servers; het alternatief is om dit uit te besteden aan een managed provider. Bij beide draait dezelfde Google-software. Het verschil zit hem in wie het bijbehorende werk doet: domeinen en beveiligingscertificaten, schaalbaarheid bij pieken in het verkeer, software-updates, monitoring en weerstand tegen adblockers. Zelf hosten is zinvol voor grote teams met een bestaande platform-engineeringafdeling en strikte regels over externe gegevensverwerkers. Voor de meeste andere teams is een managed provider meestal goedkoper als je de engineeringtijd meerekent.

Google biedt de server-side Tag Manager-container gratis aan. Het Docker-image staat in een openbaar register en de handleiding voor het instellen past op één pagina. Een ervaren technicus kan nog voor de lunch een container op een virtuele server aan de praat hebben.

Het draaien van die container is nog maar het begin. Voor een productieomgeving met tagging heb je ook aangepaste domeinen nodig, TLS-certificaten (de beveiligingscertificaten waarmee browsers via HTTPS verbinding kunnen maken), de mogelijkheid om tijdens pieken in het verkeer extra servers toe te voegen, software-upgrades en privacybeleid voor al je aangesloten platforms.

Dat stelt teams voor een praktische architectuurkeuze. Je kunt die omringende laag intern bouwen en draaien op je eigen virtuele machines of Kubernetes-cluster, waarbij je de volledige controle behoudt over je netwerkgrens en de ruwe verzoeklogs. Of je kunt gebruikmaken van een managed sGTM-provider die de routing, certificaten, upgrades en edge-tools voor je regelt.

Beide opties draaien onder de motorkap precies dezelfde Google-containerimage. Door te kijken naar de concrete operationele werkzaamheden aan beide kanten, kun je het beste bepalen welk model het beste bij je team past.

Zelfgehoste server-side GTM versus beheerde sGTM in één oogopslag

	Zelf hosten op je eigen servers	Beheerde sGTM-hosting
Software	Dezelfde Google-container	Dezelfde Google-container
Installatie	Jouw technici zorgen voor de routing, certificaten, schaalbaarheid en monitoring	Plak een configuratiestring in een dashboard
Domeinen in meerdere landen	Certificaten en routing worden per domein door jouw team beheerd	Voeg domeinen toe in een dashboard
Software-updates	Jouw team houdt nieuwe versies in de gaten, test ze en implementeert ze opnieuw	Wordt afgehandeld door de provider
Adblocker en Safari-tools	Intern ontwikkeld en onderhouden	Inbegrepen
Gegevensverwerking	De tagging-server draait op je eigen infrastructuur	Verzoeken gaan via de provider op basis van een gegevensverwerkingsovereenkomst
Doorlopende kosten	Serverkosten plus tijd van de technici	Maandelijks abonnement op basis van het aantal verzoeken
Meest geschikt voor	Zeer hoog volume, bestaand platformteam, strikte regels voor gegevensverwerking	De meeste teams en bureaus

Waarom teams verder kijken dan Google Cloud Run voor sGTM-hosting

Als teams voor het eerst server-side Google Tag Manager (sGTM) testen, beginnen ze meestal met de automatische provisioning van Google binnen de GTM-interface. In de cursus ‘Server-side tagging basics’ van Google staat dat deze implementatie met één klik alleen bedoeld is om te testen, omdat er dan één Cloud Run-instantie wordt aangemaakt die vastzit aan us-central1 in Iowa.

Als je Cloud Run in een productieomgeving zet, veranderen de kosten en de architectuur al snel. In de installatiehandleiding van Google Cloud Run wordt een minimum van twee tagging-instances aanbevolen, voor ongeveer $45 per maand per stuk (1 vCPU en 0,5 GB geheugen, waarbij de CPU altijd toegewezen is), plus een aparte preview-server. En in de documentatie over aangepaste domeinen van Google wordt aangeraden om een globale externe Application Load Balancer toe te voegen, die het inkomende verkeer over je servers verdeelt (voor ongeveer $18 per maand voor de doorstuurregel plus gegevensverwerking).

Standaard registreert Cloud Run ook inkomende verzoeken. Google waarschuwt dat dit aanzienlijke kosten voor Cloud Logging met zich mee kan brengen als je meer dan ongeveer een miljoen verzoeken per maand hebt ($0,50 per GiB boven de maandelijkse gratis limiet van 50 GiB), tenzij je de standaard log-sink in de Logs Router aanpast. Bij 10 miljoen events per maand komt een ruwe schatting van Cloud Run al uit op zo’n $110 tot $155+ per maand aan basisinfrastructuur ($90 voor twee tagging-instanties, $18+ voor de load balancer en tot $45 als de preview-server ‘warm’ blijft), en dan zijn pieken in het verkeer of niet-uitgesloten verzoeklogs nog niet eens meegerekend.

Afgezien van de factuur blijft Google Cloud een Amerikaanse aanbieder die onder Amerikaanse jurisdictie valt, en veel organisaties hebben hun infrastructuur al gestandaardiseerd op AWS, Azure of Europese hosts voor virtuele machines en Kubernetes, in plaats van een apart GCP-factureringsaccount aan te houden alleen voor marketingtags. Die afwegingen worden uitgebreider vergeleken in het artikel ‘Google Cloud Run versus managed sGTM-hosting’.

Zodra een team Cloud Run uitsluit, splitst de keuze zich in twee richtingen. Optie A is zelfhosting buiten Google Cloud: je haalt de Docker-image van Google naar je eigen virtuele machines (VM’s) of Kubernetes-cluster, en zet de routing, TLS, schaalbaarheid en monitoring zelf op. Optie B is het gebruik van een managed sGTM-hostingprovider die die infrastructuurlaag voor je beheert.

Een veelvoorkomende situatie ziet er zo uit. Een website die in meerdere landen actief is, draait op domeinen in verschillende landen, verwerkt gevoelige gezondheids- of financiële gegevens en verwerkt honderden miljoenen tot zo’n miljard verzoeken per maand. Het technische team besluit om sGTM intern op eigen VM’s te bouwen.

Waarom je keuze voor sGTM-hosting invloed heeft op je gegevenskwaliteit

Een servercontainer staat in het live-pad van zowel je analytische rapportages als de signalen van je advertentieplatform. Hij verwerkt binnenkomende HTTP-verzoeken van browsers in realtime, plaatst first-party cookies bij bezoekers die toestemming hebben gegeven, verwijdert persoonlijke identificatiegegevens en stuurt ‘schone’ events door naar GA4, productanalyses, datawarehouses en advertentie-API’s. Als de container uitvalt of verbindingen verliest tijdens een verkeerspiek, is het browsertabblad van de bezoeker al gesloten, waardoor die events zowel uit je rapporten als uit je biedmodellen verdwijnen.

Wat de analyse betreft, bepaalt de hostingconfiguratie rechtstreeks hoe lang cookies blijven staan en hoe goed de sessies werken. De Intelligent Tracking Prevention (ITP) van Safari beperkt de geldigheidsduur van door de browser geplaatste JavaScript-cookies tot zeven dagen, terwijl die van Google basisprincipes van server-side tagging Let op: een first-party servercontainer kan cookies instellen met de HttpOnly-vlag, waardoor ze langer meegaan. Hoe lang dat precies is, hangt af van de hostingconfiguratie. Safari vergelijkt het IP-adres achter je tagging-subdomein met dat van je hoofdsite, en een door de server geplaatste cookie van een subdomein dat naar een ander IP-bereik verwijst, kan nog steeds worden beperkt tot zeven dagen. Waar de tagging-server wordt gehost, is mede bepalend voor hoe lang je cookies meegaan. Ons artikel over De limiet van 7 dagen voor cookies in Safari Hierin wordt uitgelegd hoe ‘same-origin routing’ dit voorkomt. Als het TLS-certificaat van een tagging-subdomein verloopt of de routing niet meer werkt, worden terugkerende bezoekers weer als nieuwe gebruikers geregistreerd, waardoor de rapporten over multi-sessie-funnels en attributie in de war raken.

Adblockers zorgen voor een extra laag signaalverlies nog voordat een event je server bereikt. Standaardverzoeken van de browser naar googletagmanager.com of herkenbare analyse-eindpunten worden geblokkeerd door standaardfilterlijsten zoals EasyPrivacy, wat leidt tot vertekeningen in het aantal paginaweergaven, conversiepercentages en kanaalattributie in GA4. Door verzoeken via je eigen domein te leiden en de loader en verzoekpaden te maskeren, zorg je ervoor dat goedgekeurde analytics- en marketingverzoeken de container bereiken in plaats van in de browser te worden verwijderd.

Voor betaalde media raden advertentieplatforms ook aan om events zowel vanuit de browser als vanaf de server te versturen, met ontdubbeling. Meta noemt dit een redundante opzet met een overeenkomende event_id, en in een voorbeeldreactie in de documentatie van Meta’s Dataset Quality API staat dat vergelijkbare adverteerders die de Conversions API for Search-events naast de Pixel hebben ingesteld, gemiddeld 32,9% meer ‘gerapporteerde conversies’ zagen in vergelijking met opstellingen waarbij alleen de Pixel werd gebruikt.

Hoe server-side GTM-hosting werkt

In dit gedeelte wordt uitgelegd wat er precies bij het draaien van de container komt kijken. Als je niet degene bent die de container gaat bouwen, komt het er kort gezegd op neer dat Google de software levert en dat jouw team, of een provider, voor de rest moet zorgen.

Google ondersteunt officieel zelfhosting buiten Google Cloud. In de handleiding van Google voor handmatige installatie zijn alleen Cloud Run en App Engine geautomatiseerd, terwijl in andere omgevingen de Node.js-server binnen de openbare Docker-image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable draait:

• Twee implementaties: Je draait een groep servers (een cluster) voor liveverkeer en een aparte preview-server die de debugmodus van GTM aanstuurt. In de handleiding van Google staat dat je precies één preview-server moet draaien en deze niet verder moet opschalen dan één instantie.
• Omgevingsvariabelen: Beide lezen CONTAINER_CONFIG (uit GTM: containerinstellingen -> "Tagging-server handmatig instellen"). De preview-server stelt RUN_AS_PREVIEW_SERVER=true in. Het taggingcluster stelt PREVIEW_SERVER_URL in (moet HTTPS zijn) en optioneel PORT (standaard 8080). GOOGLE_APPLICATION_CREDENTIALS en GOOGLE_CLOUD_PROJECT zijn alleen nodig als je BigQuery of Firestore buiten GCP gebruikt.
• Schaalbaarheid en statuscontroles: Elke server gebruikt maximaal één virtuele processor (vCPU), en extra processors worden niet gebruikt en belemmeren de automatische schaalbaarheid. Je verwerkt dus meer verkeer door servers toe te voegen in plaats van ze groter te maken. Elke server heeft een /healthy-adres dat monitoringtools controleren om te zien of hij nog draait, en elke load balancer of CDN die ervoor staat, moet een time-out van meer dan 20 seconden hebben, anders werkt de preview-modus niet meer.

Er zijn nog twee andere producten die vaak worden verward met sGTM-hosting. Zelfstandige gateways, zoals de Conversions API Gateway van Meta en de gateway-producten die door sGTM-aanbieders worden verkocht, zijn bedoeld voor teams die geen sGTM gebruiken. De gegevens stromen rechtstreeks van de browserpixel naar de gateway en vervolgens naar Meta, waardoor de servercontainer en de bijbehorende transformaties worden overgeslagen.

Op dezelfde manier stuurt Google Tag Gateway verzoeken voor Google-tags ongewijzigd door via je CDN, maar dit geldt alleen voor Google-tags. Google meldt een signaalverbetering van 11% en raadt aan om het samen met sGTM te gebruiken. Het geldt alleen voor Google-producten, dus het vervangt sGTM niet voor Meta, TikTok of het beheer van persoonlijk identificeerbare informatie (PII). Onze ervaring is dat het combineren van beide kan interfereren met een bestaande serverconfiguratie, dus raden we over het algemeen aan om voor één van beide te kiezen, zoals besproken in Google Tag Gateway vs. server-side GTM.

Optie A: sGTM zelf hosten op je eigen VM’s of Kubernetes

Kubernetes is een veelgebruikt systeem om containers op meerdere servers te draaien en te schalen.

Als een team uit verschillende landen sGTM intern op zijn eigen VM’s bouwt, is het ophalen en starten van de Docker-container slechts de eerste stap. De rest van de technische werkzaamheden zit in de omliggende lagen, die volgens de handleiding van Google aan jouw team worden overgelaten.

Routering tussen meerdere domeinen, TLS en cookies

Omdat die duurzame HttpOnly-cookies alleen werken in een first-party-context, raadt de handleiding van Google aan om de tagging-server te hosten op dezelfde oorsprong als je website (zoals example.com/metrics) of op een aangepast subdomein (track.example.com).

Als je op meerdere landendomeinen first-party cookies op elke site wilt gebruiken, moet je per markt een apart tagging-subdomein (of same-origin-pad) beheren. Elk domein heeft zijn eigen DNS-record, TLS-certificaat, routeringsregel en ingangsconfiguratie nodig. Je moet ook elke servercontainer-URL in de GTM-containerinstellingen registreren met bijbehorende URL-paden, zodat de previewmodus op alle sites werkt.

Het register in de gaten houden en handmatige upgrades

Het openbare register van Google toont twaalf releases met tags tussen februari 2024 en oktober 2026, ongeveer één per drie maanden, met ongeveer één grote versie per jaar.

Op de pagina met release-opmerkingen van Google staan versienummers met korte opmerkingen zoals "Basisimage bijgewerkt voor beveiligingsupdates", en Google stuurt geen aankondigingen over nieuwe releases. Als je zelf je server host, moet je het register in de gaten houden, de nieuwe image ophalen en testen, de preview-server en het cluster opnieuw inrichten met een rollback-plan, en de oude instances buiten gebruik stellen. Je moet die openbare HTTPS-previewserver ook zelf draaien en beveiligen, en de servers regelmatig opnieuw opstarten, zoals de handleiding van Google aanbeveelt.

Automatische schaalbaarheid, monitoring en weerstand tegen adblockers

Stel je voor: er wordt om 9.00 uur ’s ochtends in vijf landen tegelijk een campagne-e-mail verstuurd, precies op het moment dat een uitverkoop van start gaat. Omdat elke instantie maximaal 1 vCPU gebruikt, heb je horizontale automatische schaalbaarheid nodig, capaciteitsplanning voor pieken en /healthy-waarschuwingen met een technicus op afroep, zodat het monitoren niet stilletjes stopt. Als een opzet door één persoon wordt gebouwd zonder een gedeeld platformteam, moeten waarschuwingen ook duidelijk worden overgedragen, zodat er nog steeds iemand wordt opgeroepen als die persoon van functie verandert.

Zelfs als je een subdomein naar je eigen VM laat verwijzen, voorkomt dat nog niet dat adblockers standaardpaden zoals gtm.js of /g/collect herkennen. Bij een zelfgehoste stack worden botfiltering, validatie van verzoeken en aangepaste loaderpaden of scriptmaskering intern ontwikkeld en onderhouden.

Platformtag-sjablonen: geen tekortkoming van zelfhosting

Een veelgemaakte fout is beweren dat zelfhosters geen Meta- of TikTok-tags hebben. Dat is niet zo. Beide publiceren officiële sGTM-sjablonen die op elke host draaien: de Conversions API-tag van Meta (installatiehandleiding) en het Events API-sjabloon van TikTok.

Toch zijn deze officiële sjablonen vrij eenvoudig. Meta’s template.tpl verstuurt één POST per event, zonder batchverwerking, herhalingspogingen of foutregistratie. De repository van Meta heeft een achterstand aan openstaande issues, en die van TikTok is sinds mei 2024 niet meer bijgewerkt. Sjablonen van derden en uit de community in de GTM Community Template Gallery voegen hulpmiddelen voor het verwijderen van dubbele gegevens, het afhandelen van toestemming en logboekregistratie toe, en ze werken ook op zelfgehoste containers.

Optie B: Gebruikmaken van een managed sGTM-hostingprovider

Managed providers (zoals TAGGRS en Stape) draaien voor jou dezelfde gtm-cloud-image-container, ingebed in een control plane die speciaal is gebouwd voor marketingworkloads. Je containerconfiguratie staat nog steeds in je eigen Google Tag Manager-account, waar je zelf de controle hebt over elke client, tag, trigger en variabele.

Wat naar de provider wordt verplaatst, is de infrastructuurcyclus achter de container. Je plakt je CONTAINER_CONFIG-string in het dashboard, en het platform zet het load-balanced tagging-cluster en de enkele preview-server op, houdt /healthy in de gaten en rolt automatisch nieuwe versies van gtm-cloud-image uit, zonder dat je team zich bezig hoeft te houden met implementatiescripts.

Ook tools voor multi-domain routing en edge-oplossingen zitten in het platform inbegrepen. In plaats van in elke markt zelf certificaatvernieuwingen te regelen en intern aangepaste reverse proxies te bouwen, voeg je je landensubdomeinen toe in het dashboard, stel je de DNS-records in en schakel je de ingebouwde tools in voor het maskeren van adblocker-scripts, het herstellen van Safari ITP-cookies, het filteren van bots en het analyseren van verzoeken.

Privacy en EU-gegevenssoevereiniteit: wat is nu eigenlijk het verschil?

Het verwijderen van PII gebeurt met de standaard Transformaties van Google binnen je eigen GTM-servercontainer. Ze werken op dezelfde manier, of je ze nu zelf host of via een provider gebruikt, zoals te zien is bij Transformaties in GTM. Server-side tagging en de levensduur van cookies zijn ook geen vervanging voor toestemming van de gebruiker: je container moet nog steeds de keuzes van je Consent Management Platform (CMP) afdwingen.

Het echte voordeel van zelfhosting is dat ruwe verzoeken niet via de infrastructuur van een externe sGTM-leverancier gaan en daar ook niet worden geregistreerd. Bij een managed provider zijn de logboekbeleidsregels van belang. De optionele Logs-functie van Stape laat bijvoorbeeld cookies en PII-velden weg, maar slaat wel „het volledige webadres van een HTTP-transactie, inclusief het pad en de queryparameters” op, met een bewaartermijn van 3 tot 10 dagen bij betaalde abonnementen.

TAGGRS biedt geen viewer voor onbewerkte verzoek-URL’s in het dashboard, houdt het aantal verzoekcategorieën bij voor facturering en analyse, en registreert systeemactiviteiten voor beveiligingsmonitoring binnen zijn beveiligingsmaatregelen. Providers pakken het risico van verwerkers aan met een gegevensverwerkingsovereenkomst (DPA), hosting binnen de EU en bewaartermijnen waarover je kunt onderhandelen bij Enterprise-abonnementen, terwijl zelfhosters geen externe verwerker gebruiken en intern hun eigen toegangscontroles, audits en verwerkingsregistraties opstellen.

In Europa staat de fysieke locatie van de server ook los van het rechtsgebied van het bedrijf en de verdere doorgifte van gegevens. Amerikaanse cloud- of sGTM-aanbieders vallen onder de Amerikaanse CLOUD Act (18 U.S.C. § 2713), waarbij een rechtmatig Amerikaans verzoek betrekking heeft op gegevens die onder het beheer of de controle van een Amerikaanse aanbieder vallen, ongeacht of deze in de VS of in Europa zijn opgeslagen.

Zodra je container events doorstuurt naar Amerikaanse advertentieplatforms, is voor die verdere doorgifte nog steeds een rechtsgrondslag volgens de AVG nodig, evenals een kader voor gegevensoverdracht, zoals het EU-VS-kader voor gegevensbescherming (bevestigd door het Gerecht van de EU in september 2025, waarbij een beroep nog in behandeling is). Teams die met gevoelige gezondheids- of financiële gegevens werken, moeten hun keten van verwerkers en de waarborgen voor gegevensoverdracht doornemen met hun functionaris voor gegevensbescherming (DPO) of juridisch adviseur. Zie ‘European Server-side Tracking’ voor de volledige keten.

Facturering en de werkelijke eigendomskosten

Managed providers brengen kosten in rekening op basis van het aantal verzoeken, waarbij ze de inkomende HTTP-verzoeken tellen die je servercontainer ontvangt. Zoals uit de documentatie over het Enhanced Tracking Script en de prijspagina’s van de providers blijkt, telt elk inkomend HTTP-verzoek dat de container bereikt mee voor je maandabonnement, terwijl uitgaande verzoeken vanuit de container naar advertentieplatforms dat niet doen.

GA4 kan meerdere events in één hit bundelen. Tegelijkertijd zorgen het laden van het gtm.js-script, verzoeken om cookies te herstellen, controles op adblockers, preview-verkeer en bots allemaal voor extra inkomende HTTP-verzoeken, waardoor hetzelfde websiteverkeer tot verschillende kosten kan leiden. Lagere abonnementen hanteren een harde limiet (doorsturen wordt onderbroken tenzij automatische upgrade is ingeschakeld), terwijl Enterprise-contracten een aangepaste speling bieden.

Bij grote volumes (honderden miljoenen tot zo’n miljard verzoeken per maand verspreid over domeinen in verschillende landen), wat kost het in de praktijk om dit zelf te hosten? Als ruwe schatting van de benodigde mankracht – in plaats van een officieel cijfer – kost het opbouwen en draaien van sGTM in eigen beheer op die schaal in het eerste jaar ongeveer één senior engineer en daarna een halve fulltime engineer, plus de kosten voor VM’s en bandbreedte. Voor een eerlijke budgetvergelijking moeten teams die interne engineeringtijd en de kosten voor rekenkracht afwegen tegen een offerte voor Enterprise Managed, in plaats van tegen de lijstprijzen voor zelfbeheer.

Zelf hosten versus beheerde sGTM: gedetailleerde technische vergelijking

Gebied	Optie A: Zelf hosten (VM's / Kubernetes)	Optie B: Beheerde sGTM-provider
Runtime en installatie	Draait gtm-cloud-image:stable (max. 1 vCPU per instantie); zet een cluster op, 1 preview-server zonder automatische schaalbaarheid, een load balancer (time-out >20 s) en voer intern /healthy-checks uit	Draait dezelfde gtm-cloud-image:stable; cluster, preview-server en schaalbaarheid worden automatisch geïmplementeerd vanuit CONTAINER_CONFIG
Domeinen in meerdere landen	Beheer zelf de DNS-records, TLS-certificaten, ingress-regels en de URL’s voor de GTM-containerinstellingen per domein	Voeg domeinen toe in het dashboard en stel de DNS in; SSL-vernieuwing en routing worden beheerd
Beeldupdates	Houd GCR handmatig in de gaten (11 releases van februari 2024 tot oktober 2026), test, implementeer opnieuw en onderhoud rollback-scripts	Automatisch getest en uitgerold door de provider
Adblockers en ITP-tools	Bouw en patch zelf aangepaste loaderpaden, scriptmaskering, botfilters en cookielogica in eigen beheer	Gebundelde platformtools voor scriptmaskering, ITP-cookieherstel en botfiltering
Privacy & compliance	GTM-transformaties verwijderen PII; onbewerkte verzoeken komen niet in logs van derden terecht; het interne team stelt beveiligings- en auditdocumentatie op	GTM-transformaties verwijderen PII; verzoeken worden via servers van leveranciers doorgestuurd onder een DPA, met EU-hostingopties en leverancierscertificeringen
Kostenstructuur	Kosten voor VM’s en bandbreedte + ~1 fulltime engineer in jaar 1 en ~0,5 op permanente basis (schatting)	Vaste maandelijkse verzoekniveaus, of een op maat gemaakt Enterprise-contract op schaal

Wanneer moet je sGTM zelf hosten en wanneer kun je beter gebruikmaken van managed hosting

Het zelf hosten van sGTM op je eigen VM’s of Kubernetes-cluster is een uitstekende keuze voor teams die al een 24/7 container- of VM-platform draaien met technici die op afroep beschikbaar zijn, strenge regels hebben voor gegevensopslaglocatie of het verbod op verwerking door derden voor gezondheids- of financiële gegevens, en op lange termijn zelf willen zorgen voor upgrades en monitoring.

Als je de ontwikkelingstijd meerekent, is een volledig eigen oplossing op je eigen VM’s verspreid over meerdere domeinen puur vanuit kostenoogpunt zelden rendabel bij minder dan ongeveer 500 miljoen verzoeken per maand. Deze drempel geldt voor volledige zelfhosting op je eigen servers met je eigen ontwikkelteam. Vergelijkingen tussen managed hosting en Google Cloud Run komen meestal op veel lagere cijfers uit, omdat Cloud Run een deel van het infrastructuurwerk wegneemt, maar de kosten voor inactieve servers wel behoudt.

Als die schaal-, platform- en nalevingsvoorwaarden niet aanwezig zijn, of als een bureau containers voor meerdere klantaccounts beheert, neemt een managed provider het hierboven genoemde certificaatbeheer, de upgrades en het edge-onderhoud voor zijn rekening.

Waar TAGGRS van pas komt

Voor teams die Europese gegevenssoevereiniteit en een beheerde infrastructuur willen zonder de containerstack zelf te beheren, biedt TAGGRS sGTM-hosting aan die volledig is afgestemd op Europese regelgeving. TAGGRS is een Nederlands bedrijf met EU-hosting op UpCloud in Nederland, Duitsland, België, Frankrijk, Zweden en Noorwegen, een openbare status op status.taggrs.io en een ISO/IEC 27001:2022-certificering van DEKRA. (Ter verduidelijking: als je in plaats van sGTM een standalone Meta CAPI Gateway-hosting gebruikt, draait die gateway op Google Cloud in plaats van op UpCloud.)

Het Enhanced Tracking Script (ETS v3) vervangt het standaard GTM-snippet, waarbij het script wordt gemaskeerd en de paden van goedgekeurde events worden versleuteld voordat ze de container bereiken, zonder dat je zelf een proxy nodig hebt. Hoewel geen enkel script alle blokkers omzeilt (EasyPrivacy heeft bijvoorbeeld een regel voor .js?tg=$~third-party toegevoegd), zorgt de versleuteling van verzoekpaden voor meer veerkracht: er wordt zo’n 9% tot 30% meer gemeten verkeer teruggewonnen, afhankelijk van hoe intensief het publiek van een website adblockers gebruikt.

Op de prijspagina van TAGGRS beginnen de abonnementen bij Gratis (10.000 verzoeken, geen creditcard), Basic (€ 22/maand, jaarlijks gefactureerd voor 750.000), Pro (€ 57/maand voor 3 miljoen) en Ultimate (€ 127/maand voor 10 miljoen, vergeleken met de schatting van ongeveer $ 110 tot $ 155+ voor Cloud Run bij dat volume), inclusief live chat, helpdesk en telefonische ondersteuning. TAGGRS Enterprise biedt onbeperkte verzoeken, aangepaste SLA’s, SAML SSO, een toegewijde technische accountmanager en implementatie binnen ongeveer 4 weken. Bekijk TAGGRS vs Stape voor een vergelijking van de platforms.

Conclusie

Met de Docker-image van Google kun je sGTM heel eenvoudig op je eigen VM’s of Kubernetes-cluster buiten Google Cloud draaien, als je directe controle wilt over je netwerkgrenzen en de ruwe verzoeklogs. Naast de container zelf omvat een productieomgeving multi-domain TLS, een preview-server zonder automatische schaalbaarheid, GCR-image-rollouts, weerstand tegen adblockers en monitoring op afroep, die je zelf op je eigen platform kunt verzorgen of kunt uitbesteden aan een managed host.

Om je huidige opzet te controleren, kun je de gratis website-trackingchecker gebruiken. Je kunt je cijfers ook invoeren in de ROI-calculator of aan de slag gaan met het gratis abonnement van TAGGRS (10.000 verzoeken per maand). De praktische vraag is niet zozeer of je team het kan bouwen, maar meer of het het over twee jaar nog wil blijven beheren, nadat de ontwikkelaar die het heeft gebouwd alweer verder is gegaan.

Veelgestelde vragen

Wat is het verschil tussen zelfgehoste en beheerde server-side GTM?

Beide draaien op dezelfde Google-containersoftware. Bij zelfhosting beheert jouw team de servers en zorgt het voor domeinen, beveiligingscertificaten, schaalbaarheid, software-updates en monitoring. Bij managed hosting regelt een provider die infrastructuur, terwijl jij de volledige controle houdt over je tags en instellingen in je eigen GTM-account.

Kan ik later overstappen van zelfgehoste sGTM naar een beheerde provider?

Ja. Je containerconfiguratie staat in je GTM-account in plaats van op de server, dus als je van provider wisselt, hoef je alleen maar je taggingdomein naar de nieuwe infrastructuur te verwijzen en je configuratiestring te plakken. Je tags, triggers en variabelen blijven hetzelfde.

Ondersteunt Google officieel het zelf hosten van sGTM buiten Google Cloud?

Ja. In de handleiding van Google staat beschreven hoe je gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable op elke Docker-host of elk Kubernetes-cluster kunt draaien. Je draait een taggingcluster (maximaal 1 vCPU per instantie) en 1 preview-server zonder automatische schaalbaarheid, en je regelt zelf TLS, load balancing (>time-out van 20 seconden) en handmatige upgrades.

Moet ik aangepaste Meta CAPI- en TikTok-tags bouwen als ik zelf host?

Nee. Meta en TikTok publiceren officiële sGTM-sjablonen die op elke host draaien, hoewel ze allebei vrij eenvoudig zijn (die van Meta verstuurt één POST per event zonder batchverwerking, herpogingen of foutregistratie, en de repository van TikTok is voor het laatst bijgewerkt in mei 2024). Sjablonen van derden werken ook op zelfgehoste containers.

Is het verwijderen van PII veiliger op een zelfgehoste sGTM-server dan bij een beheerde provider?

Binnen de container maakt het verwijderen van PII bij beide gebruik van dezelfde Google-eigen transformaties. Het verschil zit er stroomopwaarts: op je eigen VM’s komen onbewerkte HTTP-verzoeken niet langs de servers van een externe sGTM-leverancier en worden ze daar ook niet gelogd, terwijl ze bij een beheerde provider vallen onder een DPA, EU-hosting en beleid voor het bewaren van logbestanden.

Waarom is het aantal sGTM-verzoeken hoger dan het aantal events in mijn GA4-rapporten?

sGTM-hosts verwerken elke inkomende HTTP-aanvraag naar je taggingdomein, inclusief het laden van gtm.js-scripts, het herstellen van cookies, adblocker-controles, preview-sessies en bots, terwijl GA4 ook meerdere events kan bundelen tot één hit. Uitgaande verzoeken vanuit de servercontainer naar advertentieplatforms tellen niet mee voor je verzoekentarief.

Vanaf welk verkeersvolume is het financieel zinvol om sGTM zelf te hosten?

Als je de engineeringtijd meerekent (bij benadering één senior engineer in het eerste jaar en daarna een halve fulltime engineer, als schatting), is een volledige multi-domain-opbouw op je eigen VM’s buiten Google Cloud financieel gezien meestal pas rendabel bij zo’n 500 miljoen verzoeken per maand of meer. Teams van die omvang wegen hun personeelskosten en VM-kosten af tegen een Enterprise Managed-contract, naast hun eigen platformcapaciteit en processorregels.