Uitgave juni 2026

    Google Tag Gateway op Amazon CloudFront: wat is er feitelijk veranderd?

    De release van juni verlaagde de installatiedrempel voor websites op AWS. CloudFront werd daardoor geen server-side GTM, een uplift is niet gegarandeerd en browsermetingen blijven afhankelijk van toestemming en bronkwaliteit.

    2 augustus 2026 · 11 minuten lezen

    Op 3 juni 2026 voegde Google een begeleide Google Tag Gateway-installatie toe voor websites die al via Amazon CloudFront worden geleverd. De praktische verandering is toegankelijkheid: Tag Assistant begeleidt de gebruiker nu bij het aanmaken van de vereiste CloudFront-origin en het padgedrag in de AWS-console. Het meetmechanisme blijft first-party forwarding; de praktijkwaarde moet je meten, niet afleiden uit de lanceringstekst.

    Wat de release van 3 juni introduceerde

    Vóór de release kon CloudFront al handmatig als gateway worden geconfigureerd. De nieuwe workflow detecteert een bestaande CloudFront-distributie voor de website, opent Tag Assistant naast de AWS-console en vult de origin en het behavior voor een gereserveerd meetpad vooraf in.

    Je beoordeelt en maakt de AWS-resources nog steeds zelf aan, wacht op de distributiewijziging, vervangt het tagscript op de site en verifieert hits in Tag Assistant. Dit is een begeleide integratie, geen nieuw AWS-analyseproduct en geen one-click implementatie van een server-side GTM-container.

    Vereist een bestaande website CloudFront-distributie
    Creëert een Google-gatewayorigin
    Creëert een behavior met hoge prioriteit voor het meetpad
    Biedt een vervangend first-party tagscript

    Wat CloudFront onder de motorkap doet

    Het CloudFront-behavior verzendt verzoeken op een gereserveerd pad, zoals /metrics, naar een Google-origin op fps.goog. De handmatige configuratie van Google schakelt caching uit, staat de vereiste HTTP-methoden toe en gebruikt het origin request policy AllViewerExceptHostHeader. De gateway stuurt daarom elk meetverzoek door; het is geen cache van conversiegebeurtenissen.

    Geolocatie is een cruciaal detail. Google leidt de locatie normaal af uit het IP-adres van de browser, maar achter de gateway ziet Google het CDN. CloudFront moet de locatiegegevens van de bezoeker correct doorsturen. Ontbrekende headers kunnen geografische rapporten en regiospecifiek toestemmingsgedrag verstoren.

    CachingDisabled voor het meetgedrag
    AllViewerExceptHostHeader stuurt de bezoekerscontext door
    Het gereserveerde pad moet voorrang krijgen op bredere behaviors
    Zowel de healthcheck als de geolocatiecheck moet slagen

    Wat veranderde er niet

    GTG levert nog steeds ondersteunde Google-tags en stuurt ondersteunde metingen door naar Google. Het valideert geen aankoopwaarden tegen je commerciële backend, bouwt geen ontbrekende evenementen op, voert Meta CAPI-tags uit en geeft je geen sGTM-clients, triggers en variabelen.

    De Google-tag is nog steeds afhankelijk van de browseruitvoering. Toestemming, contentbeveiligingsbeleid, JavaScript-fouten, tagsequencing, de datalaag en geavanceerde filtering kunnen allemaal van invloed zijn op het resultaat. Een first-party pad kan één blokkeringsklasse verminderen zonder dat de installatie deblokkeerbaar wordt.

    Geen programmeerbare servercontainer
    Geen reparatie voor onvolledige brongebeurtenissen
    Geen wijziging in de toestemmingsverplichtingen
    Geen garantie tegen elke blocker of browserbeleid

    De marketingclaims hebben een gemeten basislijn nodig

    Google beschrijft GTG als een verbetering voor signaalherstel, rapportagenauwkeurigheid en conversieprestaties. De releasenote en installatiegids van CloudFront publiceren geen universele, CloudFront-specifieke uplift. Dat is het eerlijke uitgangspunt: de richting is plausibel, maar de omvang is site-specifiek.

    Een site die alleen verzoeken verliest omdat Google-hostnamen worden gefilterd, kan meer herstellen dan een site waarvan de belangrijkste problemen het weigeren van toestemming, kapotte e-commercegebeurtenissen of backend-afstemming zijn. Rapporteer geaccepteerde gebeurtenissen, toestemmingsmix, browsermix en blootstelling aan blockers, naast eventuele voor-en-na-percentages.

    Presenteer geen leveranciersmediaan als je prognose
    Scheid herstelde verzoeken van nieuwe geldige conversies
    Corrigeer voor campagnes, seizoensinvloeden en toestemmingsmix
    Gebruik bestemmingsdiagnostiek en totalen uit het bronsysteem

    De uitzondering op de EER-routering is van belang

    Google documenteert een belangrijke uitzondering voor verkeer in de Europese Economische Ruimte: Google Analytics-meetgegevens gaan rechtstreeks naar regionale Google-endpoints in plaats van het CDN-pad. Google Ads-conversiehits gaan door via de gateway. Dit verwachte gedrag kan ervoor zorgen dat een eenvoudige vergelijking van het aantal netwerktellingen er inconsistent uitziet.

    Voor Europese merken analyseert je GA4 en Google Ads afzonderlijk en verifieert je de regiospecifieke toestemmingsstandaarden. CloudFront geolocatieconfiguratie is geen optionele metadata; het kan zowel het rapportage- als het toestemmingsgedrag beïnvloeden.

    Wie profiteert het meest van de nieuwe workflow?

    De sterkste match is een merk waarvan de productiewebsite al CloudFront gebruikt, waarvan de meting voornamelijk op Google is gebaseerd en wiens team veilig een distributiewijziging kan beoordelen. De release bespaart handmatige configuratietijd en maakt een correcte basislijnconfiguratie toegankelijker.

    Een bedrijf dat meerdere advertentie-API's, databeheer op de server of backend-evenementen nodig heeft, mag de workflow niet als de eindstatus beschouwen. Gebruik het als een gerichte Google-leveringsverbetering of combineer eigen scriptweergave met een echt sGTM-verzamelpad.

    Noem het geen uplift voordat de cijfers zijn afgestemd

    Meer verzoeken in het browsernetwerkpaneel betekenen niet automatisch meer geaccepteerde conversies. Vergelijk bestemmingsverwerking en toegeschreven conversies met bestellingen of gekwalificeerde leads uit het bronsysteem.

    Een verdedigbaar CloudFront-uitrolplan

    Beschouw de begeleide opstelling als een infrastructuurverandering en een meetexperiment.

    1. 01

      Leg een pre-lanceringsbasislijn vast

      Registreer twee tot vier representatieve weken aan toestemmingspercentages, browsermix, geaccepteerde GA4-gebeurtenissen, Google Ads-conversies en bronsysteemtotalen.

    2. 02

      Bevestig vereisten en eigendom

      Controleer de Google-tag, de juiste website CloudFront-distributie, AWS-toegang, een rollback-eigenaar en een gereserveerd pad dat niet conflicteert met de applicatie.

    3. 03

      Voer de Tag Assistant-workflow uit

      Open de tag-instellingen van Google, scan de website, selecteer CloudFront en bekijk de oorsprong en het gedrag dat Tag Assistant je vraagt te creëren in AWS.

    4. 04

      Controleer het CloudFront-behavior

      Controleer de padprioriteit, uitgeschakelde caching, toegestane methoden, het origin request policy en het doorsturen van bezoekerslocatie voordat productieverkeer het behavior gebruikt.

    5. 05

      Vervang en valideer het tagscript

      Implementeer het meegeleverde script, voer de statuscontrole uit en bevestig in Tag Assistant dat hits het gereserveerde first-party pad gebruiken.

    6. 06

      Test toestemming en regionaal gedrag

      Test verleende en geweigerde toestemming van EER- en niet-EER-locaties. Verwacht de gedocumenteerde GA4-routeringsuitzondering en controleer Google Ads afzonderlijk.

    7. 07

      Meet en stem het resultaat af

      Vergelijk waar mogelijk stabiele cohorten en stem vervolgens geaccepteerde bestemmingsgebeurtenissen en toegeschreven conversies af op bedrijfsresultaten. Houd een terugdraaipad aan totdat het resultaat bekend is.

    CloudFront-ondersteuning vergroot het bereik, niet de productgrens van GTG

    De integratie van juni 2026 is van belang omdat het begeleide GTG-installatie biedt voor de vele merken die al op AWS CloudFront draaien. Het vermindert de infrastructuurfrictie en zou de kans op een fundamentele routeringsfout moeten verkleinen.

    De prestaties ervan zijn nog steeds voorwaardelijk. De release creëert geen brongebeurtenissen, vervangt geen toestemming, verwerkt geen gegevens in sGTM of garandeert geen conversieverhoging. Publiceer je eigen afgestemde resultaat, met de verkeers- en toestemmingscontext die nodig is om het te interpreteren.

    CloudFront-integratie: veelgestelde vragen

    Wanneer lanceerde Google de begeleide CloudFront-integratie?

    De release-opmerkingen van Google's Tag Manager dateren van 3 juni 2026. CloudFront was daarvoor mogelijk via handmatige routering; de release voegde een begeleide Tag Assistant-workflow toe.

    Is de CloudFront-integratie volledig automatisch?

    Nee. Tag Assistant begeleidt je in de AWS-console en vult instellingen vooraf in, maar je beoordeelt en creëert zelf de origin en het behavior, implementeert het vervangende script en test het resultaat.

    Slaat CloudFront meetgebeurtenissen op in het cachegeheugen?

    Dat zou niet moeten. De handmatige installatie van Google specificeert het CachingDisabled-beleid voor het gereserveerde meetgedrag.

    Zal elke site meer conversies genereren?

    Er is geen universeel resultaat gedocumenteerd. Elke wijziging is afhankelijk van de oorzaken van huidig ​​verlies, toestemming, browser- en blockermix, implementatiekwaliteit en bestemmingsverwerking.

    Waarom kunnen GA4 en Google Ads verschillende routes in de EER weergeven?

    Google zegt dat Google Analytics-gegevens uit de EER rechtstreeks naar regionale Google-endpoints gaan, terwijl Google Ads-conversiehits via het gateway-pad doorgaan.

    Primaire bronnen en verder lezen

    Gerelateerde artikelen

    Meer nodig dan het doorsturen van Google-verzoeken?

    Tracking Hippo host je sGTM-verwerkingslaag op bewaakte EU-infrastructuur voor metingen op meerdere platforms aan de serverzijde.

    Ontdek de voordelen