von Johannes Klampfl
Server Side Tagging (SST) ist in aller Munde und dabei gibt es verschiedene Setup Möglichkeiten für den Google Server-side Tag Manager. In diesem Artikel werden diese Möglichkeiten dargestellt und miteinander verglichen.
Webanalyse steht für Messbarkeit und ist die Grundlage für langfristige Erfolgskontrolle und Effizienzsteigerung Ihrer (Online) Marketing Aktivitäten.
Mehr ErfahrenWenn man diesen Prozess abschließt, passiert folgendes im Hintergrund:
Es wird ein neues GCP Projekt angelegt, welches als Namen die ID des zuvor erstellten GTM Containers erhält (z.B.: GTM-PF6F8LU). Innerhalb dieses Projektes wird eine App Engine Applikation – Achtung: in der Region us-central-1 – angelegt. Die Region der App Engine Applikation gilt für alle darin enthaltenen Services und kann nachträglich nicht mehr geändert werden. Die Region hat vor allem Auswirkungen auf die Kosten und den Datenschutz.
Innerhalb der App Engine Applikation wird ein neues Service, welches den eigentlichen Tagging Server beinhaltet angelegt. Dieser Tagging Server hat zwei mögliche Konfigurationen:
Wie man erkennen kann, besteht der Unterschied darin, dass die “Production Configuration” mehr Rechenleistung bereitstellt und damit mehr Kosten verursacht. Die “Testing Configuration” verursacht in den meisten Fällen keine Kosten.
Der automatische Prozess versetzt den Tagging Server in die “Testing Configuration”, welcher nach einer erfolgreichen Testphase mit Hilfe eines Bash Scripts manuell in die “Production Configuration” geändert werden muss.
Es sei auch erwähnt, dass der automatische Prozess das App Engine Logging aktiv lässt, welches bei viel Traffic zu entsprechenden Kosten führen kann. Das Logging kann auf folgende Weise manuell deaktiviert werden.
Die Anweisungen in der verlinkten Doku filtern jedoch nur die POST Request Logs, um auch GET Request Logs zu filtern muss diese Anweisung noch hinzugefügt werden:
Um auch die Health Checks Logs zu filtern, muss zusätzlich diese Anweisung noch hinzugefügt werden:
Was ebenfalls noch manuell gemacht werden muss ist die Zuweisung einer Tracking Subdomain.
Die folgende Dokumentation beschreibt die dafür notwendigen Schritte. Die Vorteile gegenüber des vorherigen Weges sind folgende:
Der manuelle Prozess wird mittels eines Bash Scripts innerhalb der Cloud Shell umgesetzt. Wichtig ist hier zu wissen, dass dieses Script mögliche bestehende App Engine Services löscht und dann ein neues Service, eben den Tagging Server erstellt.
Wie auch beim automatische Prozess, muss hier ebenfalls noch die Zuweisung einer Tracking Subdomain gemacht werden.
Es gibt auch die Möglichkeit den Tagging Server außerhalb der Google Cloud Platform zu hosten. Mehr zu diesem Thema kann in folgendem Blogartikel nachgelesen werden.
Der automatische als auch der manuelle Prozess setzen auf die App Engine innerhalb der GCP. Es gibt jedoch noch eine andere GCP Ressource welche als Basis für den Tagging Server verwendet werden kann, und zwar Cloud Run. Zum Zeitpunkt als der Server Side GTM veröffentlicht wurde, war Cloud Run noch in der Beta Phase und es fehlten essentielle Features um diese Ressource als Tagging Server zu verwenden. In der Zwischenzeit ist die Beta Phase jedoch vorbei.
Die Vorteile von Cloud Run sind:
Es gibt hier keine Unterscheidung zwischen “Test Configuration” und “Production Configuration”, denn dies sind Voreinstellungen des App Engine Bash Scripts. Ggf. muss auch bei diesem Weg das Logging manuell eingeschränkt werden.
Das Setup kann über das GCP User Interface gemacht werden, wobei hier das offizielle Tagging Server Docker Image verwendet wird. Eine zweite Möglichkeit ist das Bash Script von Simo Ahava zu verwenden, welches letztendlich die Einstellungen des App Engine Bash Scripts auf Cloud Run anwendet (z.B.: 3-6 Instanzen (default)).
Was die Zuweisung von Tracking Subdomains bei Cloud Run betrifft, sind alle üblichen Use Cases möglich (trifft auch für die App Engine zu):
Die beiden ersten Szenarien können bei Cloud Run als auch bei App Engine direkt über das User Interface umgesetzt werden, abgesehen von den zusätzlich notwendigen DNS Anpassungen.
Der einzige Nachteil bei Cloud Run ist, dass die Tracking Subdomain Zuordnung über das User Interface aktuell nur für folgende europäische GCP Regions möglich ist:
Sollte jedoch z.B. die Anforderung sein Cloud Run innerhalb der Region Frankfurt europe-west3 zu betreiben, muss statt der Zuordnung im User Interface ein Load Balancer eingerichtet werden. Die Kosten dafür sind jedoch überschaubar (ca. $ 30 / Monat für 50 Mio GA Hits) und steigen nicht proportional zu den Hits (ca. $ 35 / Monat für 100 Mio GA Hits).
War dieser Artikel hilfreich für Sie? In unserem Blog finden Sie viele weitere Beiträge zum Thema Digital Analytics und Server-Side Tagging!
Wir freuen uns auf Ihre Anfrage und beraten Sie gerne unverbindlich! Füllen Sie dazu einfach das Kontaktformular aus oder rufen uns direkt an.
Jetzt kontaktierenNewsletter
Holen Sie sich unsere Online Marketing-Insights und Trends direkt in Ihr Postfach!