Den 3. juni 2026 tilføjede Google en guidet Google Tag Gateway-opsætning til websteder, der allerede er leveret gennem Amazon CloudFront. Den praktiske ændring er tilgængelighed: Tag Assistant leder nu en bruger gennem oprettelse af den påkrævede CloudFront oprindelse og stiadfærd i AWS-konsollen. Målemekanismen er velkendt førstepartsvideresendelse, og dens virkelige værdi skal måles i stedet for at udledes af lanceringssproget.
Hvad udgivelsen den 3. juni introducerede
Før udgivelsen kunne CloudFront allerede konfigureres manuelt som en gateway. Den nye arbejdsgang registrerer en eksisterende CloudFront-distribution til webstedet, åbner Tag Assistant ved siden af AWS-konsollen og forudfylder den oprindelse og adfærd, der kræves for en reserveret målesti.
Du gennemgår og opretter stadig AWS-ressourcer, venter på distributionsændringen, erstatter tag-scriptet på webstedet og verificerer hits i Tag Assistant. Dette er en guidet integration, ikke et nyt AWS-analyseprodukt og ikke en implementering med et enkelt klik af en server-side GTM-beholder.
Hvad CloudFront laver under motorhjelmen
CloudFront-adfærden sender anmodninger på en reserveret sti såsom /metrics til en Google fps.goog-oprindelse. Googles manuelle konfiguration deaktiverer caching, tillader de nødvendige HTTP-metoder og bruger AllViewerExceptHostHeader oprindelsesanmodningspolitik. Gatewayen videresender derfor hver måleanmodning; det er ikke en cache af konverteringshændelser.
Geolokalisering er en kritisk detalje. Google udleder normalt placering fra browserens IP-adresse, men bag gatewayen ser den CDN. CloudFront skal videresende seerens placeringsoplysninger korrekt. Manglende overskrifter kan forvrænge geografiske rapporter og regionsspecifik samtykkeadfærd.
Hvad ændrede sig ikke
GTG leverer stadig understøttede Google-tags og videresender understøttede målinger til Google. Det validerer ikke købsværdier i forhold til din handelsbackend, opbygger manglende hændelser, kører Meta CAPI-tags eller giver dig sGTM-klienter, triggere og variabler.
Google-tagget afhænger stadig af browserens udførelse. Samtykke, indholdssikkerhedspolitik, JavaScript-fejl, tag-sekventering, datalaget og sofistikeret filtrering kan alle påvirke resultatet. En førstepartssti kan reducere én klasse af blokering uden at gøre opsætningen ophævet.
Markedsføringspåstandene har brug for en afmålt baseline
Google beskriver GTG som en forbedring af signalgendannelse, rapporteringsnøjagtighed og konverteringsydelse. CloudFront-lanceringsnotatet og opsætningsvejledningen udgiver ikke en universel CloudFront-specifik løft. Det er det ærlige udgangspunkt: Retningen er plausibel, men størrelsen er stedspecifik.
Et websted, der kun mister anmodninger, fordi Google-værtsnavne er filtreret, kan gendanne mere end et websted, hvis hovedproblemer er nægtet samtykke, ødelagte e-handelsbegivenheder eller backend-afstemning. Rapportér accepterede hændelser, samtykkemix, browsermix og blokeringseksponering sammen med eventuelle før-og-efter-procenter.
EØS-ruteundtagelsen har betydning
Google dokumenterer en vigtig undtagelse for trafik i Det Europæiske Økonomiske Samarbejdsområde: Google Analytics-målingsdata går direkte til regionale Google-slutpunkter i stedet for CDN-stien. Google Ads konverteringshits fortsætter gennem gatewayen. Denne forventede adfærd kan få en simpel sammenligning af netværkstal til at se inkonsekvent ud.
For europæiske mærker skal du analysere GA4 og Google Ads separat og kontrollere regionsspecifikke samtykkestandarder. CloudFront geolocation konfiguration er ikke valgfri metadata; det kan påvirke både rapporterings- og samtykkeadfærd.
Hvem har mest gavn af den nye arbejdsgang?
Den stærkeste pasform er et mærke, hvis produktionswebsted allerede bruger CloudFront, hvis måling primært er Google-baseret, og hvis team trygt kan gennemgå en distributionsændring. Udgivelsen sparer manuel konfigurationstid og gør en korrekt baseline-opsætning mere tilgængelig.
En virksomhed, der har brug for flere annoncerings-API'er, datastyring på serversiden eller backend-begivenheder, bør ikke behandle arbejdsgangen som sluttilstanden. Brug det som en fokuseret Google-leveringsforbedring, eller kombiner førstepartsscript-servering med en ægte sGTM-indsamlingssti.
Kald ikke resultatet en løft, før du forener det
Flere anmodninger i browserens netværkspanel er ikke automatisk mere accepterede konverteringer. Sammenlign destinationsbehandling og tilskrevet konverteringer med ordrer eller kvalificerede kundeemner fra kildesystemet.
En forsvarlig CloudFront udrulningsplan
Behandl den guidede opsætning som en infrastrukturændring og et måleeksperiment.
- 01
Optag en baseline før lancering
Registrer to til fire repræsentative uger med samtykkerater, browsermix, accepterede GA4-begivenheder, Google Ads-konverteringer og kildesystemtotaler.
- 02
Bekræft forudsætninger og ejerskab
Bekræft Google-tagget, det korrekte websted CloudFront-distribution, AWS-adgang, en tilbagerulningsejer og en reserveret sti, der ikke er i konflikt med applikationen.
- 03
Kør Tag Assistant-arbejdsgangen
Åbn Google-tag-indstillinger, scan webstedet, vælg CloudFront og gennemgå oprindelsen og adfærden, som Tag Assistant beder dig om at oprette i AWS.
- 04
Gennemgå CloudFront adfærd
Bekræft stiprioritet, deaktiveret cachelagring, tilladte metoder, oprindelsesanmodningspolitik og videresendelse af seerplaceringsoplysninger, før produktionstrafik bruger dem.
- 05
Erstat og valider tag-scriptet
Implementer det medfølgende script, kør sundhedstjekket og bekræft i Tag Assistant, at hits bruger den reserverede førstepartssti.
- 06
Test samtykke og regional adfærd
Test givet og nægtet samtykke fra EØS- og ikke-EØS-lokationer. Forvent den dokumenterede GA4 routing-undtagelse og tjek Google Ads separat.
- 07
Mål og afstem resultatet
Sammenlign stabile kohorter, hvor det er muligt, og afstem derefter accepterede destinationsbegivenheder og tilskrevne konverteringer med forretningsresultater. Hold en tilbagerulningssti, indtil resultatet er forstået.
CloudFront-understøttelse ændrer rækkevidde, ikke GTG-produktgrænsen
Juni 2026 integrationen betyder noget, fordi det bringer guidet GTG opsætning til de mange mærker, der allerede er på AWS CloudFront. Det reducerer infrastrukturfriktion og burde mindske chancen for en grundlæggende routingfejl.
Dens ydeevne er stadig betinget. Udgivelsen skaber ikke kildehændelser, erstatter ikke samtykke, behandler data i sGTM eller garanterer en konverteringsforøgelse. Publicer dit eget afstemte resultat med den trafik- og samtykkekontekst, der er nødvendig for at fortolke det.
CloudFront integration: almindelige spørgsmål
Hvornår lancerede Google den guidede CloudFront-integration?
Googles Tag Manager-udgivelsesbemærkninger daterer den 3. juni 2026. CloudFront var mulig gennem manuel routing før det; udgivelsen tilføjede en guidet Tag Assistant-arbejdsgang.
Er CloudFront integrationen fuldautomatisk?
Nej. Tag Assistant guider dig i AWS-konsollen og forudfylder indstillinger, men du gennemgår og opretter oprindelsen og adfærden, implementerer erstatningsscriptet og tester resultatet.
Kan CloudFront cache måle hændelser?
Det burde den ikke. Googles manuelle opsætning specificerer CachingDisabled-politikken for den reserverede måleadfærd.
Vil hvert websted se flere konverteringer?
Der er ikke dokumenteret noget universelt resultat. Enhver ændring afhænger af årsagerne til det aktuelle tab, samtykke, browser- og blokeringsmix, implementeringskvalitet og destinationsbehandling.
Hvorfor kan GA4 og Google Ads vise forskellige ruter i EØS?
Google siger, at EEA Google Analytics-data går direkte til regionale Google-endepunkter, mens Google Ads-konverteringshits fortsætter gennem gateway-stien.