Google Tag Gateway ersetzt kein Server Side Tracking
Warum deine Google Analytics Requests auch mit Tag Gateway nicht über deine eigene Domain rausgehen sondern an region1.google-analytics.com
Das hier ist keine Anleitung zum Einbau des Google Tag Gateway. Solche Anleitungen gibt es schon zur Genüge. Eine sehr gute findet sich wie so oft bei Julius (Analytics Mania) oder hier direkt bei Google.
Aber als Webbie in der EU wirst du wahrscheinlich über dasselbe Problem gestolpert sein wie ich – das ganze haut nicht so hin, wie versprochen. Und genau dieses möchte ich hier adressieren.
Zunächst trotzdem ein paar Worte zum Google Tag Gateway.
Wie das Google Tag Gateway funktioniert
Ad Blocker blockieren das Laden von Ressourcen einer Website, wenn die für diese Ressourcen angefragten Urls Namen oder bekannte Muster von Werbetechnologien beinhalten. So z.B. das Laden des Tag Managers von der Url https://googletagmanager.com.
Und sie blockieren auch das Senden von Daten an Werbeplattformen, was wiederum so funktioniert, dass auch hier die Url, an die der Request z. B. eines Google Analytics Seitenaufrufs geschickt werden soll, auf bekannte Muster oder Namen von Werbetreibenden geprüft und ggf. blockiert wird. So z. B. das Senden des Google Analytics Requests an https://google-analytics.com/g/collect.
In der Theorie (und eben leider nicht in der Praxis) sollte der Google Tag Gateway dafür sorgen, dass Ressourcen wie der Tag Manager via der eigenen Domain und nicht der des Tagmanagers geladen (was tatsächlich funktioniert) und Requests an Google nicht direkt an die Domain von Google sondern zuerst an die eigene und erst von dort aus serverseitig an die von Google gesendet werden (was nicht funktioniert). Der Browser würde so nicht sehen, dass hier Daten an Google rausgehen, ein browserseitig aktiver Ad Blocker würde diese Daten nicht abfangen und nicht blockieren, da der Browser nur mit der eigenen Domain und nicht mit der von Google kommuniziert.
Aber es schickt die Google Analytics Requests nicht via deiner eigenen Domain
Wenn du das Tag Gateway entsprechend der Anleitungen eingebaut und aktiviert hast, wirst du wie hier auch von Google angeleitet prüfen, ob die Requests jetzt tatsächlich via der eigenen Domain rausgehen. Dazu gibt es zwei Optionen:
- Test via dem Tag Assistant
Hier solltest du dann beim Request selbst unter „Url“ nicht die von Google sehen, sondern deine eigene:
- Test via Direktklick auf den Request in den Dev Tools
Öffne die Dev Tools deines Google Chrome Browsers – Strg + Shift + I (Windows), F12 (Windows) oder Cmd + Option + I (Mac) – gehe dort in den Tab „Netzwerk“, filtere auf „collect“ und klicke dann direkt auf den Request, der in einem Browserfenster öffnet. Dort siehst du die Url, an die er geschickt wurde:
Und hier jetzt die Überraschung: Der Request geht nicht wie versprochen zurst an die eigene Domain raus, sondern wird nach wie vor direkt an Google geschickt, ganz entgegen des Versprechens des Google Tag Gateways.
Keine Sorge: Du hast alles richtig gemacht, das Tag Gateway ist aktiv. Prüfen kanns du das nochmal, indem du dir im Request unter „Initiatior“ die Initiatorkette ansiehst. Wird hier nicht direkt via https://googletagmanager.com geladen sondern über deine Domain und da über den von dir in der Tag Gateway Konfiguration selbst festgelegten Pfad aus 4 Zeichen, dann ist das Tag Gateway aktiv:
Kein Google Tag Gateway „First Party“ -Request in der EU
Warum also geht der Request an Google nicht zuerst an deine Domain und dann erst serverseitig an Google? Das führt doch das Tag Gateway ad absurdum!
Ja, genau so ist es. Und der Grund dafür der Folgende: Du bist in der EU. Und der Tag Gateway ist kein Server Side Tracking per se. Das bedeutet, du hast nicht die Letztentscheidung darüber, wohin deine Requests gesendet werden, das entscheidet das Javascript von Google. Und das erkennt, dass du in der EU bist, und nimmt dir das erst mal aus der Hand. Es entscheidet, dass der Request direkt an die Domain
https://region1.google-analytics.com/g/collect?
geht und dort verarbeitet wird. „region1“ steht dabei für Google Server, die in der EU arbeiten. Google nutzt die direkte Ansteuerung der region1-Server, um juristisch nachweisbar zu garantieren, dass EU-Analytics-Daten erst auf EU-Boden verarbeitet und IP-Adressen dort unmittelbar verworfen werden.
Und damit ist Schluss mit der versprochenen Tag Gateway Magic. Klingt doof, ist aber so. Nur ist das in keiner Google Dokumentation festgehalten, und auch Branchengrößen wie Julius Fedorovicius dürfte es erst verspätet aufgefallen sein:
Das Google Tag Gateway ist kein Ersatz für Server Side Tracking
Das bedeutet, dass das Google Tag Gateway in der EU kein niederschwelliger Ersatz für ein Server Side Tracking ist. Wobei auch andere Limitierungen dazukommen, wie etwa, dass das Tag Gateway keine serverseitigen „Cookies“ setzen kann, die beschränkte Cookielaufzeit von Safari, Firefox, etc. also nach wie vor greift.
Aber dass mit dem Tag Gateway nicht einmal die Requests über die eigene Domain rausgehen, stellt dessen Daseinsberechtigung nochmal mehr in Frage.
Warum das Google Tag Gateway trotzdem Sinn macht: Google Ads Conversion Tags
Dass es sich vielleicht trotzdem lohnt, das Tag Gateway einzusetzen, liegt daran, dass im Unterschied zu Google Analytics Requests die Requests an Google Ads tatsächlich über die eigene Domain rausgehen. Klingt absurd, ist aber einfach so.
Das bedeutet, wenn du dein Tracking nicht auf GA4 sondern auf Google Ads Conversion- und Remarketing Tags aufbaust, sollten diese es mit Tag Gateway durch die meisten Ad Blocker schaffen. Hier ein Test mit aktiviertem Ghostery, der alle GA4-Request blockiert hat aber den Google Ads Request durchlässt:
Um aber ausnahmslos jeden Netzwerk-Request (auch GA4 EU-Collect-Hits) ausschließlich an die eigene Domain zu schicken, ist ein Server-Side Google Tag Manager (sGTM) the way to go. Und das macht auch Sinn.
Solltest du aber die Kosten für Stape, Jentis etc. sparen wollen und auch keinen Bock auf aufwändige manuelle Implementierung haben, ist eine Umstellung auf Googel Ads Conversion Tags und das Google Tag Gateway durchaus eine Option.
Fazit: In a nutshell
Das Google Tag Gateway ist für den Raum EU ungeeignet, Google Analytics Requests serverseitig zu schicken und macht hier kaum einen Unterschied. „Kaum“ deswegen, weil zumindest der Tag Manager via der eigenen Domain geladen wird, was auch schon einen kleinen Unterschied machen kann.
Aber: Google Ads Conversion Tags werden so via der eigenen Domain geladen, was hier tatsächlich einen Unterschied machen kann.
Lass dich also nicht verrückt machen, wenn du nach Aktivierung des Tag Gateways die von Google in den Anleitungen empfohlenen Überprüfungen hinsichtlich der Url der Requests nicht positiv abschließen kannst. Niemand hat dir verraten, dass diese Überprüfung in der EU nicht positiv sein kann, weil Google in der EU eben auch mit Tag Gateway alle Google Analytics Requests weiterhin an die Domain von Google schickt.
Um zu entscheiden, welche Varianten des Trackings für dich Sinn machen oder um überhaupt einmal zu einem Conversion-Tracking zu kommen melde dich gerne für einen unverbindlichen Beratungscall:
