Wenn Sie server-side GTM bereits verwenden, erstellen Sie keine zweite konkurrierende Google-Messpipeline, nur um Google Tag Gateway hinzuzufügen. Das von Google empfohlene kombinierte Muster trennt zwei Pfade gleichen Ursprungs: Ein Skriptpfad leitet gtm.js- oder gtag.js-Anfragen an Google weiter, während ein Erfassungspfad Messereignisse an Ihren Tagging-Server weiterleitet. Der Servercontainer bleibt der Ort, an dem Ereignisse verarbeitet und weitergeleitet werden.
Die kombinierte Architektur
Ein Same-Origin-Setup kann Pfade wie www.example.com/scripts zum Laden von Erstanbieter-Google-Skripten und www.example.com/metrics für den Servercontainer verwenden. Das CDN oder der Load Balancer leitet jedes Präfix an einen anderen Ursprung weiter. Google warnt davor, dass beide Pfade ungenutzt sein dürfen und kein /gtm enthalten dürfen.
Der Browser lädt den Webcontainer oder das Google-Tag über den Skriptpfad. Das Google-Tag wird dann so konfiguriert, dass die Messung an den Erfassungspfad gesendet wird. Der sGTM-Client übernimmt diese Anfrage, erzeugt ein Ereignis und löst die entsprechenden Server-Tags aus.
Beim Ausführen ist beides nützlich
Die Kombination ist nützlich, wenn Sie die Browser-Ausfallsicherheitsvorteile des Ladens von Erstanbieter-Skripten nutzen möchten und außerdem Transformationen, Datenminimierung, Nicht-Google-Ziele oder Beobachtbarkeit von sGTM benötigen. Für eine dauerhafte Einrichtung empfiehlt Google ausdrücklich das Laden von Erstanbieter-Skripten zusammen mit serverseitigem Tagging.
Es ist weniger nützlich, wenn GTG nur die Funktionalität duplizieren würde, die bereits von einem korrekt konfigurierten sGTM-Lader und einer Sammelroute eines Erstanbieters bereitgestellt wird. Überprüfen Sie die aktuellen Pfade, bevor Sie eine weitere Regel hinzufügen. Die Architektur soll nach der Änderung übersichtlicher werden und nicht nur mehr Produkte enthalten.
Die Duplikat-Ereignisfalle
Das gefährliche Muster besteht darin, dieselbe Google-Konvertierung direkt über einen GTG-Weiterleitungspfad und außerdem über sGTM zu senden, wo ein Server-Tag sie erneut übermittelt. Möglicherweise sind beide Netzwerkanfragen erfolgreich, was zu überhöhten Conversions führt, die wie eine verbesserte Wiederherstellung aussehen.
Definieren Sie einen Lieferungseigentümer für jedes Ereignis und Ziel. Stabile Transaktions-IDs oder Ereignis-IDs sind immer noch nützlich, aber die Deduplizierung sollte ein Sicherheitsmechanismus und nicht die primäre Architektur sein. Sehen Sie sich die Browser- und Servercontainer gemeinsam in der Vorschau an und zählen Sie ausgehende Zielanforderungen.
Same-Origin ist besser als eine zufällige Tracking-Subdomain
Google dokumentiert, dass Same-Origin als Best Practice für die Sicherheit und Haltbarkeit serverseitiger Cookies dient. Ein Pfad auf dem Website-Host, z. B. www.example.com/metrics, hat denselben Ursprung. Eine Subdomain wie „metrics.example.com“ ist eine Erstanbieterdomäne, hat aber nicht denselben Ursprung.
Same-Origin-Routing erfordert normalerweise ein CDN oder einen Load Balancer und eine sorgfältige Pfadpriorität. Leiten Sie alle vom Tagging-Server benötigten Cookies und Abfragezeichenfolgen weiter, leiten Sie jeden Clientpfad einschließlich des dokumentierten /_/*-Unterpfads weiter und überprüfen Sie den Integritätsendpunkt, bevor Sie Produktions-Tags ändern.
Einwilligung und Privatsphäre bestimmen weiterhin den Ablauf
Die Erstversorgung ist eine Transportentscheidung, keine Genehmigung. Initialisieren Sie die Standardeinstellungen für die Einwilligung vor der Messung, übergeben Sie den Einwilligungsstatus an die Erfassungsanforderung und konfigurieren Sie Server-Tags, damit verweigerte Speicher- oder Werbeoptionen wie geplant behandelt werden.
Daten an der Servergrenze minimieren. Überprüfen Sie, welche Cookies, Header, Abfrageparameter und Ereignisfelder in den Servercontainer gelangen, und lassen Sie dann nur die Felder zu, die jedes Ziel benötigt. GTG löscht Erstanbieter-Cookies, die nicht von Google stammen, auf seinem eigenen Weiterleitungspfad, aber Ihr sGTM-Erfassungspfad hat seine eigenen Verantwortlichkeiten für die Datenverarbeitung.
Eine klare Entscheidungsregel
Wenn Sie kein sGTM haben und nur eine unterstützte Google-Messung benötigen, kann GTG allein ausreichend sein. Wenn Sie über sGTM verfügen, aktivieren Sie das Erstanbieter-Google-Skript, das als Teil dieser Architektur dient, und sorgen Sie dafür, dass die Messwerterfassung auf den Servercontainer gerichtet bleibt.
Wenn zwei Teams GTG und sGTM besitzen, veröffentlichen Sie vor dem Start eine Streckenkarte und eine Event-Eigentumsmatrix. Eine CDN-Regel, eine Web-Container-Einstellung und ein Server-Tag können jeweils ändern, wohin dasselbe Ereignis geht; Undokumentierte Überschneidungen sind die übliche Quelle für Duplikate.
Verwenden Sie zwei Pfade, nicht zwei Messwerteigentümer
Der Skriptpfad und der Sammlungspfad sind absichtlich unterschiedlich. Der Skriptpfad lädt Google-Code vom Erstanbieter; Der Sammelpfad sendet Ereignisse an sGTM. Lassen Sie nicht zu, dass beide Pfade unabhängig voneinander die gleiche Konvertierung liefern.
Konfigurieren Sie GTG mit server-side GTM
Die genauen Menüs variieren je nach CDN, aber die Verantwortlichkeiten und die Validierungsreihenfolge bleiben gleich.
- 01
Bestätigen Sie, dass der Servercontainer produktionsbereit ist
Verwenden Sie eine Produktions-Tagging-Bereitstellung, einen funktionierenden Vorschauserver, Zugriffskontrollen, Überwachung und eine benutzerdefinierte Domäne, bevor Sie die Browserroute ändern.
- 02
Reservieren Sie zwei ungenutzte Pfade mit demselben Ursprung
Wählen Sie einen Skriptpfad wie /scripts und einen Sammlungspfad wie /metrics. Keiner der Pfade darf mit der Site in Konflikt stehen oder /gtm enthalten.
- 03
Leiten Sie den Sammelpfad an sGTM weiter
Konfigurieren Sie das CDN oder den Load Balancer so, dass das vollständige Sammlungspräfix, die Cookies und Abfragezeichenfolgen an den Tagging-Server weitergeleitet werden, einschließlich der von Server-Clients benötigten Pfade.
- 04
Fügen Sie die Sammlungs-URL in den Server-Container-Einstellungen hinzu
Legen Sie die Server-Container-URL auf die URL desselben Ursprungs einschließlich ihres Pfadpräfixes fest und bestätigen Sie dann, dass der erwartete Client eine Vorschauanforderung anfordert.
- 05
Leiten Sie den Skriptpfad für GTG weiter
Leiten Sie das reservierte Skriptpräfix an den Google-Gateway-Ursprung weiter und aktualisieren Sie die gtm.js- oder gtag.js-Quelle, um über diesen Pfad zu laden.
- 06
Richten Sie Google-Ereignisse auf den Erfassungspfad
Legen Sie server_container_url oder die entsprechende Google-Tag-Einstellung auf den Endpunkt /metrics fest, damit die Messung in sGTM eingeht, anstatt zweimal direkt zum selben Ziel zu gehen.
- 07
Konfigurieren Sie Clients, Tags und Einwilligungen
Überprüfen Sie die Clientpriorität, Ereignistransformationen, Zustimmungsprüfungen, Ziel-Tags und stabile Ereigniskennungen im Servercontainer.
- 08
Testen Sie die komplette Route
Bestätigen Sie, dass das Skript von /scripts geladen wird, eine Anfrage /metrics erreicht, der Server-Client sie beansprucht und genau eine erwartete Anfrage für jedes Ziel verlässt.
- 09
Überwachung nach Veröffentlichung
Warnen Sie bei Gesundheitsstörungen und ungewöhnlichem Volumen, überprüfen Sie die Zieldiagnosen und gleichen Sie Käufe oder Leads mit der Wahrheit im Quellsystem ab.
Führen Sie komplementäre Schichten aus, keine parallelen Pipelines
GTG und sGTM arbeiten gut zusammen, wenn das Gateway die Bereitstellung von Erstanbieter-Skripten übernimmt und sGTM über die Ereignisverarbeitung verfügt. Das Zwei-Pfad-Muster macht diese Grenze sichtbar und testbar.
Die Konfiguration schlägt fehl, wenn dieselbe Konvertierung zwei Lieferungseigentümer hat. Dokumentieren Sie Pfade, bewahren Sie eine Ereignisidentität, testen Sie Zustimmungszustände und zählen Sie die Anfragen, die tatsächlich den Server verlassen.
GTG plus sGTM: häufige Fragen
Sollte jedes sGTM-Setup auch Google Tag Gateway verwenden?
Google empfiehlt die Skriptbereitstellung durch Erstanbieter. Überprüfen Sie jedoch zunächst Ihren vorhandenen Loader und Ihre Routen. Einige sGTM-Setups bedienen bereits Abhängigkeiten von Erstanbietern und benötigen möglicherweise nur ein Konfigurationsupdate.
Können GTG und sGTM denselben Pfad verwenden?
Das CDN-Muster von Google verwendet separate Pfade: einen für Skripte und einen für die Ereigniserfassung. Getrennte Routen verhindern Herkunftskonflikte und machen Verantwortlichkeiten klar.
Wie verhindere ich doppelte Google-Conversions?
Wählen Sie für jede Konvertierung einen Absender aus. Wenn sGTM die Google-Zielanfrage sendet, senden Sie nicht auch eine gleichwertige direkte Browseranfrage. Überprüfen Sie die Anzahl ausgehender Anfragen in der Vorschau und der Zieldiagnose.
Ist eine Subdomain dasselbe wie die Bereitstellung mit demselben Ursprung?
Nein. Eine Subdomain ist eine First-Party-Domain, aber „Same Origin“ bedeutet dasselbe Schema, denselben Hostnamen und denselben Port wie die Website. Google listet beide als unterstützende serverseitig gesetzte Cookies auf, bezeichnet jedoch dieselbe Herkunft als die beste Vorgehensweise.
Über welchen Pfad sollen Meta- oder TikTok-Ereignisse gesendet werden?
Diese Zielanforderungen sollten durch Server-Tags in sGTM oder einer anderen Serverintegration erstellt werden. Der Google-Skriptpfad von GTG ist keine allgemeine Nicht-Google-Konvertierungs-API-Route.