Server Side GTM und First Party Mode: Mehr Kontrolle, weniger Restriktionen
Management Summary
FPM und ssGTM: Verbesserte Kontrolle und weniger Cookie-Beschränkungen – erfahre in diesem Blogartikel, ob dieses Setup für dein Unternehmen geeignet ist.
Hinweise
Laut der offiziellen Google Dokumentation ist der First Party Mode (FPM) noch in beta:
- Note: First-party mode is in beta. Setting up First-party mode may help your tag setup perform better, resulting in better quality measurement signals. If you have a question or issue with your setup, reach out to us at 1p-mode-beta-feedback@googlegroups.com.
Quelle
Zusätzlich soll darauf hingewiesen werden, dass der First Party Mode auch ohne Server Side GTM umsetzbar ist, da in unserem Umfeld jedoch häufig bereits der Server Side GTM im Einsatz ist, bezieht sich dieser Blog Artikel speziell auf diese Kombination und nicht rein auf den First Party Mode.
Vorteile
Mehr Kontrolle
Da vor dem ssGTM ein Reverse Proxy geschalten wird, hat man damit die Möglichkeit Daten zu verändern oder zu entfernen, bevor diese z.B. in der GCP bzw. am ssGTM eintreffen.
Ein Beispiel wäre die Entfernung der User IP Adresse am Reverse Proxy bevor diese an den ssGTM geschickt wird. Dies ist vielleicht in einem Unternehmen notwendig, welches sehr strenge Datenschutzregeln hat.
Die Frage, welche sich in diesem Zusammenhang stellt, ist, welcher Reverse Proxy wird dafür verwendet? Ein Load Balancer in der GCP? Features in Cloudflare (ein US Unternehmen)? Oder ein anderer Anbieter?
Vorteil: Mehr Kontrolle – Quelle: e-dialog
ITP Restriktionen abschwächen
Das Problem in diesem Zusammenhang ist, dass die IP der Website (z.B.: analytics-test-1.com 162.159.134.42) und die IP der ssGTM Tracking Subdomain (z.B.: sst.analytics-test-1.com 35.190.14.188) (zu) unterschiedlich sind. ITP stuft in diesem Fall den ssGTM und dessen über den Set-Cookie HTTP Response Header gesetzte Cookies (z.B.: FPID) als verdächtig ein und limitiert daher die Cookie Lebenszeit auf 7 Tage.
Verwendet man hingegen den First Party Mode, dann operiert der ssGTM unter derselben IP Adresse wie die Website und die Lebenszeit der gesetzten Cookies wird nicht limitiert.
Vorteile bringt dies daher nur für Tools, welche nur First Party Cookies setzen (z.B.: GA4 mittels FPID Cookie). Die Third Party Cookies vieler anderer Tools (z.B.: Google Ads, Floodlight Tags, LinkedIn etc.) werden weiterhin von ITP limitiert. Selbst wenn diese Tags in den ssGTM umgezogen werden, setzen diese ihre Cookies in einem Third Party Context und werden daher limitiert.
Keine Änderung
Ad/Tracking Blocker umgehen
Die meisten Blocker verwenden Listen mit Domains und/oder Pfaden.
Blocker welche nur Domain Listen (z.B.: googletagmanager.com) verwenden, wurden bereits mit dem bisher üblichen Setup von ssGTM mit Tracking Subdomain und dem Laden des Client Side GTM und der Google Bibliotheken umgangen.
Blocker welche in ihren Listen ebenfalls anhand von Pfaden (z.B.: /gtm.js) blockieren, identifizieren z.B. auch den Client Side GTM wenn dieser über FPM geladen wird (z.B.: analytics-test-1.com/metrics/gtm.js).
In beiden Fällen bringt der FPM leider keine Verbesserung.
CSP kann vereinfacht werden
Ein weiterer Vorteil, welcher von FPM angeführt wird, ist, dass die CSP der Website vereinfacht werden kann. Wenn man auch in diesem Fall annimmt, dass der Client Side GTM bereits über eine eigene Subdomain geladen wird, und diese sowieso eine Subdomain der Website Domain ist, hält sich der Vorteil vermutlich auch hier in Grenzen.
Dieser Vorteil trifft also nur zu, wenn der Client Side GTM noch direkt über https://www.googletagmanager.com eingebunden ist und nicht über die Tracking Subdomains des ssGTMs.
Nachteile
Zusätzliche Kosten
Abhängig vom Setup können keine oder eben zusätzliche Kosten für den vorgeschalteten Reverse Proxy entstehen.
Implementierungsaufwand
Aufwand entsteht für folgende Punkte:
- Der Code des Client Side GTMs muss auf der Website angepasst werden
- Der Reverse Proxy muss aufgesetzt werden
- Der Client Side GTM benötigt nur eine kleine Anpassung
- Testing und Evaluierung des Trackings
Cookies an Google
Ein Nachteil, der immer wieder erwähnt wird, ist, dass alle Website-Cookies an den Google Host beim FPM gesendet werden.
Wenn FPM mit ssGTM kombiniert wird, ist dies nicht der Fall, denn die Cookies werden an den selbst gehosteten ssGTM gesendet und nicht direkt an den Google Host.
Definitionen
Proxy vs. Reverse Proxy
Im Zusammenhang mit FPM wird oft der Begriff “Reverse Proxy” verwendet.
Den klassischen “Proxy” kennen viele. Er wird vom Client/User eingesetzt und wird meistens zum Zweck von Datenschutz und Umgehung von Geolocation Sperren (z.B.: streamen im Ausland) eingesetzt.
Im Unterschied dazu wird der “Reverse Proxy” vom Webserver eingesetzt und vor diesen geschaltet. Ein Reverse Proxy kann viele Einsatzbereiche haben, einige davon sind: Security, Load Balancing, Caching etc. Sprich: Reverse Proxy ist der Oberbegriff und z.B. ein Load Balancer ist ein spezieller Typ eines Reverse Proxies.
Um FPM umzusetzen, ist es notwendig, die Requests der Google Bibliotheken (Client Side GTM, GTag) und die Tracking Requests selbst (/collect etc.) zum ssGTM umzuleiten.
Ob dies von einem Load Balancer oder einem anderen Reverse Proxy Typ gemacht wird, ist nicht relevant, hier gibt es viele Möglichkeiten.
Reverse Proxy vs. FPM
Bei einem fertigen FPM Setup in Kombination mit ssGTM werden alle Tracking Ressourcen und Requests über einen vorher definierten Pfad gesendet, z.B.: /metrics
Der Client Side GTM wird dann über folgende URL geladen: analytics-test-1.com/metrics/gtm.js
Um dieses Routing der /metrics/* Requests zum ssGTM kümmert sich der Reverse Proxy.
First Party Mode ist quasi das Feature von Google bzw. dem ssGTM, dass dieser bei einem Request von der URL analytics-test-1.com/metrics/gtm.js tatsächlich die Client Side GTM Library zurück liefert. Der First Party Mode befähigt den ssGTM, dass dieser auf die Tracking Requests über den neuen Pfad /metrics richtig reagiert.
CNAME Cloaking
Beim CNAME Cloaking im Tracking Bereich versucht man die tatsächliche Quelle von Ressourcen zu verbergen. Dabei wird ein CNAME, d.h. eine Weiterleitung von einem Domain Namen auf einen anderen Domain Namen, dafür verwendet.
In dem Beispiel unten besteht eine CNAME Weiterleitung von cdn.analytics-test-1.com auf third-party.com
In diesem Fall würde im Network Tab der Developer Tools tatsächlich die Domain cdn.analytics-test-1.com angezeigt werden, jedoch würde die tatsächliche IP 33.33.33.33 wo die Ressource gehostet ist angezeigt werden.
Auf diese Weise können Tracking-Blocker, welche nach der Domain third-party.com Ausschau halten, diese nicht erkennen und dementsprechend nichts blocken.
Das Setup mittels Cloud Run und dem Custom Domain Feature hat zwar Ähnlichkeit zum CNAME Cloaking, trifft aber nicht ganz darauf zu. Denn man verknüpft mittels CNAME den eigenen ssGTM und keine Drittanbieter Domain.
Wie man sieht ist die Domain keine zuverlässige Quelle um Tracking zu erkennen, aus diesem Grund prüft ITP daher die IPs, weicht die IP von einer bestimmten Ressource zu weit ab (verglichen mit der IP der Website), dann werden die dazugehörigen Cookies ebenfalls limitiert.
Das heißt auch, egal ob man seinen ssGTM mittels Cloud Run und Custom Domain Feature (CNAME Record) nutzt, oder Cloud Run und einen Load Balancer (A Record), die IP des ssGTM weicht zu stark von der IP der Website ab und wird somit von ITP erkannt.
Fazit
FPM in Kombination mit ssGTM bietet einige Vorteile, ist aber vermutlich nicht für jedes Szenario notwendig.
