Server Side GTM Setup Möglichkeiten
Management Summary
1 Automatischer Prozess
Die erste Möglichkeit für das Einrichten eines Server Side GTMs ist der automatische Prozess. Wenn man innerhalb eines GTM Accounts einen neuen Container vom Typ “Server” erstellt, erscheint das unten abgebildete Auswahl Fenster.
Wenn 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:
- Testing Configuration
- App Engine Standard Environment
- 1 Instanz F1
- Production Configuration
- App Engine Flexible Environment
- 3-6 Instanzen (default, kann geändert werden)
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:
- NOT LOG_ID(“appengine.googleapis.com%2Fnginx.health_check”)
Um auch die Health Checks Logs zu filtern, muss zusätzlich diese Anweisung noch hinzugefügt werden:
- NOT LOG_ID(“appengine.googleapis.com%2Fvm.events”)
Was ebenfalls noch manuell gemacht werden muss ist die Zuweisung einer Tracking Subdomain.
2 Manueller Prozess
Wie man in dem obigen Screenshot erkennen kann, gibt es ebenfalls einen manuellen Prozess zum Einrichten des Tagging Servers.
Die folgende Dokumentation beschreibt die dafür notwendigen Schritte. Die Vorteile gegenüber des vorherigen Weges sind folgende:
- Die Region der App Engine Applikation kann frei gewählt werden
- Es kann frei entschieden werden ob man dafür ein neues GCP Projekt anlegt oder ein bestehendes verwendet
- Man kann den Tagging Server sofort in der “Production Configuration” starten, wenn gewünscht
- Das App Engine Logging kann während dem Setup gleich deaktiviert werden, die beiden oben beschriebenen zusätzlichen Anweisungen müssen jedoch ggf. ergänzt werden
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.
3 Außerhalb der GCP
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.
4 Tagging Server mit Cloud Run
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:
- Die Region kann frei gewählt werden
- Auch hier kann ein bestehendes oder ein neues GCP Projekt verwendet werden
- Die Kosten sind etwas geringer als bei der App Engine
- Einfaches Setup über das GCP User Interface möglich
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.
Das dritte Szenario kann bei Cloud Run ebenfalls über das User Interface in der GCP umgesetzt werden, da hier pro Service eine eigene Subdomain zugewiesen werden kann. Will man dieses Setup mittels App Engine umsetzen muss dafür zusätzlich eine dispatch.yaml Datei verwendet werden. Denn bei der App Engine werden Subdomains immer für die komplette App Engine Applikation zugewiesen und daher muss ein zusätzliches Routing mit Hilfe der erwähnten dispatch.yaml Datei umgesetzt werden.
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:
- Belgien europe-west1
- Niederlande europe-west4
- Finland europe-north1
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!
