Veröffentlichung im Juni 2026

    Google Tag Gateway auf Amazon CloudFront: Was hat sich eigentlich geändert?

    Mit der Juni-Version wurden Probleme bei der Einrichtung von AWS-basierten Websites beseitigt. Es hat weder CloudFront in server-side GTM umgewandelt, noch einen Uplift garantiert oder die Browsermessung unabhängig von Zustimmung und Quellqualität gemacht.

    2. August 2026 · 11 Min. Lektüre

    Am 3. Juni 2026 fügte Google ein geführtes Google Tag Gateway-Setup für Websites hinzu, die bereits über Amazon CloudFront bereitgestellt wurden. Die praktische Änderung ist die Barrierefreiheit: Tag Assistant führt einen Benutzer jetzt durch die Erstellung des erforderlichen CloudFront-Ursprungs- und Pfadverhaltens in der AWS-Konsole. Der Messmechanismus ist das bekannte First-Party-Forwarding, und sein realer Wert muss gemessen und nicht aus der Startsprache abgeleitet werden.

    Was mit der Veröffentlichung vom 3. Juni eingeführt wurde

    Vor der Veröffentlichung konnte CloudFront bereits manuell als Gateway konfiguriert werden. Der neue Workflow erkennt eine vorhandene CloudFront-Verteilung für die Website, öffnet Tag Assistant neben der AWS-Konsole und füllt den Ursprung und das Verhalten vorab aus, die für einen reservierten Messpfad erforderlich sind.

    Sie überprüfen und erstellen weiterhin AWS-Ressourcen, warten auf die Verteilungsänderung, ersetzen das Tag-Skript auf der Website und überprüfen Treffer in Tag Assistant. Dies ist eine geführte Integration, kein neues AWS-Analyseprodukt und keine Ein-Klick-Bereitstellung eines server-side GTM-Containers.

    Erfordert eine vorhandene Website-CloudFront-Distribution
    Erstellt einen Google-Gateway-Ursprung
    Erstellt ein Messpfadverhalten mit hoher Priorität
    Stellt ein Ersatz-Erstanbieter-Tag-Skript bereit

    Was CloudFront unter der Haube macht

    Das CloudFront-Verhalten sendet Anfragen auf einem reservierten Pfad wie /metrics an einen Google fps.goog-Ursprung. Die manuelle Konfiguration von Google deaktiviert das Caching, lässt die erforderlichen HTTP-Methoden zu und verwendet die Ursprungsanforderungsrichtlinie AllViewerExceptHostHeader. Das Gateway leitet daher jede Messanfrage weiter; Es handelt sich nicht um einen Cache von Konvertierungsereignissen.

    Die Geolokalisierung ist ein entscheidendes Detail. Normalerweise leitet Google den Standort aus der IP-Adresse des Browsers ab, aber hinter dem Gateway sieht es das CDN. CloudFront muss die Standortinformationen des Betrachters korrekt weiterleiten. Fehlende Header können geografische Berichte und regionsspezifisches Einwilligungsverhalten verzerren.

    CachingDisabled für das Messverhalten
    AllViewerExceptHostHeader leitet Viewer-Kontext weiter
    Der reservierte Pfad muss umfassenderen Verhaltensweisen überlegen sein
    Gesundheits- und Geolokalisierungsprüfungen müssen beide bestanden werden

    Was sich nicht geändert hat

    GTG stellt weiterhin unterstützte Google-Tags bereit und leitet unterstützte Messungen an Google weiter. Es validiert keine Kaufwerte anhand Ihres Commerce-Backends, erstellt keine fehlenden Ereignisse, führt keine Meta CAPI-Tags aus und stellt Ihnen keine sGTM-Clients, Trigger und Variablen zur Verfügung.

    Das Google-Tag hängt weiterhin von der Browserausführung ab. Einwilligung, Inhaltssicherheitsrichtlinie, JavaScript-Fehler, Tag-Sequenzierung, die Datenschicht und ausgefeilte Filterung können das Ergebnis beeinflussen. Ein Erstanbieterpfad kann eine Blockierungsklasse reduzieren, ohne dass die Blockierung des Setups aufgehoben wird.

    Kein programmierbarer Servercontainer
    Keine Reparatur für unvollständige Quellereignisse
    Keine Änderung der Einwilligungspflichten
    Keine Garantie gegen jede Blocker- oder Browserrichtlinie

    Die Marketingaussagen benötigen eine gemessene Ausgangslage

    Google beschreibt GTG als eine Verbesserung der Signalwiederherstellung, der Berichtsgenauigkeit und der Konvertierungsleistung. Die CloudFront-Einführungsnotiz und die Einrichtungsanleitung veröffentlichen keine universelle CloudFront-spezifische Aktualisierung. Das ist der ehrliche Ausgangspunkt: Die Richtung ist plausibel, aber die Größe ist ortsspezifisch.

    Eine Website, die Anfragen nur deshalb verliert, weil Google-Hostnamen gefiltert werden, kann möglicherweise mehr wiederherstellen als eine Website, deren Hauptprobleme in der Verweigerung der Einwilligung, fehlerhaften E-Commerce-Ereignissen oder dem Backend-Abgleich liegen. Melden Sie akzeptierte Ereignisse, Einwilligungsmix, Browsermix und Blocker-Exposition zusammen mit allen Vorher-Nachher-Prozentsätzen.

    Geben Sie als Prognose keinen Anbietermedian an
    Trennen Sie wiederhergestellte Anforderungen von neuen gültigen Konvertierungen
    Kontrolle für Kampagnen, Saisonalität und Einwilligungsmix
    Verwenden Sie Zieldiagnosen und Quellsystem-Gesamtwerte

    Die EWR-Routing-Ausnahme ist wichtig

    Google dokumentiert eine wichtige Ausnahme für den Verkehr im Europäischen Wirtschaftsraum: Google Analytics-Messdaten gehen direkt an regionale Google-Endpunkte und nicht an den CDN-Pfad. Google Ads-Konvertierungstreffer werden über das Gateway fortgesetzt. Dieses erwartete Verhalten kann dazu führen, dass ein einfacher Vergleich der Netzwerkanzahl inkonsistent erscheint.

    Analysieren Sie für europäische Marken GA4 und Google Ads separat und überprüfen Sie die regionalspezifischen Einwilligungsstandards. Bei der Geolocation-Konfiguration CloudFront handelt es sich nicht um optionale Metadaten. es kann sich sowohl auf das Melde- als auch auf das Einwilligungsverhalten auswirken.

    Wer profitiert am meisten vom neuen Workflow?

    Am besten passt eine Marke, deren Produktionswebsite bereits CloudFront verwendet, deren Messung hauptsächlich auf Google basiert und deren Team eine Vertriebsänderung sicher prüfen kann. Die Version spart Zeit bei der manuellen Konfiguration und erleichtert die korrekte Grundkonfiguration.

    Ein Unternehmen, das mehrere Werbe-APIs, serverseitige Datenverwaltung oder Backend-Ereignisse benötigt, sollte den Workflow nicht als Endzustand betrachten. Nutzen Sie es als gezielte Verbesserung der Google-Bereitstellung oder kombinieren Sie die Skriptbereitstellung durch Erstanbieter mit einem echten sGTM-Erfassungspfad.

    Nennen Sie das Ergebnis nicht einen Uplift, bis Sie es in Einklang gebracht haben

    Mehr Anfragen im Browser-Netzwerk-Panel bedeuten nicht automatisch mehr akzeptierte Conversions. Vergleichen Sie die Zielverarbeitung und zugeschriebene Conversions mit Bestellungen oder qualifizierten Leads aus dem Quellsystem.

    Ein vertretbarer Rollout-Plan für CloudFront

    Betrachten Sie die geführte Einrichtung als eine Infrastrukturänderung und ein Messexperiment.

    1. 01

      Erfassen Sie eine Baseline vor dem Start

      Zeichnen Sie zwei bis vier repräsentative Wochen der Zustimmungsraten, des Browser-Mix, der akzeptierten GA4-Ereignisse, der Google Ads-Konvertierungen und der Quellsystem-Gesamtzahlen auf.

    2. 02

      Bestätigen Sie die Voraussetzungen und den Besitz

      Überprüfen Sie das Google-Tag, die korrekte Website-CloudFront-Verteilung, den AWS-Zugriff, einen Rollback-Eigentümer und einen reservierten Pfad, der nicht mit der Anwendung in Konflikt steht.

    3. 03

      Führen Sie den Workflow Tag Assistant aus

      Öffnen Sie die Google-Tag-Einstellungen, scannen Sie die Website, wählen Sie CloudFront aus und überprüfen Sie den Ursprung und das Verhalten, das Tag Assistant Sie in AWS erstellen soll.

    4. 04

      Überprüfen Sie das Verhalten von CloudFront

      Bestätigen Sie die Pfadpriorität, das deaktivierte Caching, die zulässigen Methoden, die Ursprungsanforderungsrichtlinie und die Weiterleitung der Standortinformationen des Betrachters, bevor der Produktionsverkehr diese verwendet.

    5. 05

      Ersetzen und validieren Sie das Tag-Skript

      Stellen Sie das bereitgestellte Skript bereit, führen Sie die Integritätsprüfung durch und bestätigen Sie in Tag Assistant, dass Treffer den reservierten Erstanbieterpfad verwenden.

    6. 06

      Testen Sie Einwilligung und regionales Verhalten

      Der Test wurde von EWR- und Nicht-EWR-Standorten genehmigt und verweigert. Erwarten Sie die dokumentierte Routing-Ausnahme GA4 und prüfen Sie Google Ads separat.

    7. 07

      Messen und vergleichen Sie das Ergebnis

      Vergleichen Sie nach Möglichkeit stabile Kohorten und gleichen Sie dann akzeptierte Zielereignisse und zugeschriebene Conversions mit den Geschäftsergebnissen ab. Behalten Sie einen Rollback-Pfad bei, bis das Ergebnis verstanden wird.

    Die Änderungen an der CloudFront-Unterstützung reichen nicht bis zur Produktgrenze GTG

    Die Integration vom Juni 2026 ist wichtig, weil sie den vielen Marken, die bereits auf AWS CloudFront sind, eine geführte GTG-Einrichtung bietet. Es reduziert die Reibungsverluste in der Infrastruktur und sollte die Wahrscheinlichkeit eines grundlegenden Routingfehlers verringern.

    Seine Leistung ist noch bedingt. Die Version erstellt keine Quellereignisse, ersetzt keine Einwilligung, verarbeitet keine Daten in sGTM und garantiert keine Conversion-Steigerung. Veröffentlichen Sie Ihr eigenes abgeglichenes Ergebnis mit dem für seine Interpretation erforderlichen Verkehrs- und Einwilligungskontext.

    CloudFront-Integration: häufige Fragen

    Wann hat Google die geführte CloudFront-Integration eingeführt?

    Die Versionshinweise zum Tag Manager von Google datieren ihn auf den 3. Juni 2026. CloudFront war zuvor durch manuelles Routing möglich; Mit der Version wurde ein geführter Tag Assistant-Workflow hinzugefügt.

    Erfolgt die CloudFront-Integration vollautomatisch?

    Nein. Tag Assistant führt Sie durch die AWS-Konsole und füllt die Einstellungen vorab aus, aber Sie überprüfen und erstellen den Ursprung und das Verhalten, stellen das Ersatzskript bereit und testen das Ergebnis.

    Speichert CloudFront Messereignisse im Cache?

    Das sollte nicht der Fall sein. Das manuelle Setup von Google gibt die CachingDisabled-Richtlinie für das reservierte Messverhalten an.

    Wird jede Website mehr Conversions verzeichnen?

    Es ist kein universelles Ergebnis dokumentiert. Jede Änderung hängt von den Ursachen des aktuellen Verlusts, der Einwilligung, dem Browser- und Blocker-Mix, der Implementierungsqualität und der Zielverarbeitung ab.

    Warum weisen GA4 und Google Ads möglicherweise unterschiedliche Routen im EWR auf?

    Google gibt an, dass EEA-Google Analytics-Daten direkt an regionale Google-Endpunkte weitergeleitet werden, während Google Ads-Conversion-Treffer über den Gateway-Pfad weiterlaufen.

    Primärquellen und weiterführende Literatur

    Verwandte Artikel

    Benötigen Sie mehr als nur die Weiterleitung von Google-Anfragen?

    Tracking Hippo hostet Ihre sGTM-Verarbeitungsschicht auf einer überwachten EU-Infrastruktur für serverseitige Messungen auf mehreren Plattformen.

    Entdecken Sie die Vorteile