Was Server Side Tagging / Tracking ist und für wen es sich lohnt, das haben wir bereits in einem früheren Artikel ausführlich beleuchtet. Hier soll es nun praktischer werden: wir richten Server Side Tagging mit dem Google Tag Manager ein.
Überblick
Zunächst ein kleiner Überblick, was uns hier erwartet. Serverseitiges Tagging mit dem Google Tag Manager einzurichten lässt sich in die folgenden Schritte einteilen:
(1) einen GTM Container für serverseitiges Tagging erstellen
(2) ein Cloud Projekt in der Google Cloud Plattform erstellen
(3) Tags, Trigger, ggf. Variablen und Clienten im Server-Side Container einrichten
(4) Daten an den Container senden
(5) Testen und prüfen.
(6) Eine Custom Domain einrichten
Der serverseitige Google Tag Manager nutzt standardmäßig Googles Cloud Run. Entsprechend setzen wir das hier auch ein. Viele ältere Tutorials beruhen noch auf Googles App Engine, diesen Weg würden wir Anfängern jedoch nicht empfehlen.
Wichtig zu wissen: Das Setup des Servers unterscheidet sich je nachdem auf welchen Hosting Provider man setzt.
Und ein weiterer wichtiger Hinweis direkt zu Beginn: bloß weil unser Tracking nun serverseitig ist, sind damit nicht alle Fragen hinsichtlich ePrivacy und Datenschutz beseitigt. Wir haben weiterhin die Verpflichtung uns den expliziten Consent des Users zu holen, bevor wir Daten über ihn sammeln. Das heißt, dass der Cookie Banner Teil unserer Realität bleibt. Es ist weiterhin in unserer Verantwortung zu prüfen, was für Daten wir erheben (IP-Adressen, E-Mail-Adressen, Klarnamen, Blutgruppen, kulinarische oder sonstige Vorlieben und Aktivitäten haben in unseren Google Analytics Daten nichts zu suchen) und was mit den Daten passiert (z.B. sollten sie die EU nicht verlassen).
GTM Container für serverseitiges Tagging erstellen
Wir loggen uns in unseren Google Tag Manager Account ein und erstellen einen neuen Container. Wir werden nach Namen unseres Containers gefragt, sowie nach unserer Zielplattform. Wir wählen "Server" als Zielplattform und geben dem Container einen Namen unserer Wahl.
Google Cloud Projekt & Tagging Server erstellen
Im nächsten Schritt müssen wir ein neues Projekt auf der Google Cloud Plattform erstellen. Hier können wir einfach den Anweisungen auf dem Bildschirm folgen.
Nach Erstellung des neuen Google Tag Manager Containers werden wir gefragt, ob wir einen Tagging-Server automatisch oder manuell bereitstellen wollen. Wir entscheiden uns hier für die erste Option. (Stellt man seinen eigenen Server bereit, ist der folgende Prozess deutlich komplexer).
Im folgenden müssen wir ein Rechnungskonto auf der Google Cloud Plattform einrichten, falls wir noch keines haben.
Auch hier folgen wir einfach den Anweisungen auf dem Bildschirm, hinterlegen unsere Rechnungsdaten und Zahlungsinformationen. Anschließend werden wir automatisch zurück zum Google Tag Manager geführt und können die Einrichtung fortführen.
Sollte dieses Fenster nicht anzeigt werden, so klickt man einfach im Google Tag Manager oben links auf die Container ID (GTM-XXXXX), dann sollte sich das Fenster erneut öffnen.
Wir warten ein paar Minuten, bis Google mit der Erstellung des Servers fertig ist und holen uns in der Zwischenzeit eine neue Tasse Kaffee (optional).
Nach wenigen Minuten erhalten wir die Informationen über unseren soeben erstellten Server.
Einen Client einrichten
Zu den Tags, Triggern und Variablen, die wir noch aus dem Client-Side Tracking kennen, kommt ein neues Konzept hinzu, der Client.
Der Client ist die Instanz, welche die Daten, die der Server-Side Container im GTM sendet, empfängt und verarbeitet. Mittels dem Client werden die Daten also in unserem Container zur Verfügung gestellt.
Bei der Erstellung des Server Containers wurde bereits ein GA4-Client automatisch erstellt.
Es lassen sich mehr Clients erstellen, aktuell ist die Anzahl hier aber noch limitiert. Die Erstellung von Clients braucht zudem einiges an Javascript-Erfahrung und Kenntnis im Umgang mit den verfügbaren APIs.
Glücklicherweise können wir uns an dieser Stelle aber auf den automatisch generierten GA4-Client verlassen und erstellen keinen weiteren Client.
Den GA4-Tag einrichten
Im nächsten Schritt erstellen wir unseren GA4 Tag. Dieser empfängt Daten über Events auf unserer Website und leitet diese dann an die Google Analytics Server weiter. Wir erstellen also den Tag und fügen unsere Mess-ID ein. Weitere Konfigurationen nehmen wir nicht vor.
Anschließend widmen wir uns dem Trigger, der dieses Tag auslösen soll. Da wir uns mit einem frischen Container befassen, sehen wir hier in der Auswahl nur die drei voraktivierten Trigger: Benutzerdefiniert, Benutzerdefiniertes Ereignis, Seitenaufruf. Wir wählen Benutzerdefiniert.
Hier erstellen wir nun einen Trigger, der dann ausgelöst wird, wenn der Client Name des jeweiligen Events gleich GA4 ist, d.h.: Client Name (eine voreingestellte Variable, die wir jedoch noch in unseren Variablen aktivieren müssen) enthält GA4.
Damit stellen wir sicher, dass auch nur dann Requests an Google Analytics 4 gesendet werden, wenn wir das wirklich wollen. Wir ermöglichen es uns hiermit also, zu entscheiden, welche Informationen an welchen Client gesendet werden, sollte einmal ein neuer hinzukommen.
Daten an den Server Side GTM Container senden
Würden wir jetzt in den Vorschau-Modus des serverseitigen GTM Containers wechseln, würden wir noch nichts sehen. Das hat den einfachen Grund, dass wir bisher noch keine Daten an unseren serverseitigen GTM Container senden. Das wird sich nun ändern.
Es gibt mehrere Optionen, wie wir Daten an den GTM Container senden können. Wir könnten unsere Entwickler fragen ob sie die gtag.js Code-Snippets, die auf der Seite verbaut sind abändern können. Oder wir fragen sie, ob sie uns besonderen Code schreiben, mit dem wir Daten direkt an den Server Container senden können.
Aber: weil wir unsere Entwickler meist nicht unnötig mit solchen Details behelligen wollen, nutzen wir ja überhaupt erst den Google Tag Manager in the first place. Glücklicherweise können wir das auch hier tun, sprich: wir nutzen unseren bestehenden Google Tag Manager Web Container und weisen ihn an, die für GA4 bestimmten Daten nicht direkt an GA4 zu senden, sondern an unseren serverseitigen Container.
Zur Erinnerung: der Google Tag in unserem GTM Web Container sendet die Daten, die er empfängt, standardmäßig an eine URL wie z.B. google-analytics.com/collect weiter. Diese Ziel-URL ändern wir nun.
Das ist relativ einfach. Wir wechseln (praktischerweise in einem neuen Browsertab) in unseren Web-Container, öffnen unseren Google Tag / GA4 Konfigurationstag, suchen nach den Konfigurationseinstellungen und ergänzen hier einen neuen Parameter: server_container_url.
Diesem Parameter weisen wir als Wert nun die URL zu, die wir in einem vorherigen Schritt von Google erhalten haben: nämlich der URL der für unseren Server. Wer sich diese lange URL voller kryptischen Zeichen nicht gemerkt hat (hey, wir sind alle nur Menschen), kann sie ganz einfach wiederfinden: in unserem Serverseitigen GTM Container klicken wir auf unsere Container ID (GTM-XXXXX), zu finden oben rechts. Ein Popup öffnet sich. Die URL, die wir benötigen finden wir in diesem Popup ganz unten.
Wir kopieren die Server-URL und fügen sie - zurück in unserem Web-Container - als Wert für den Parameter server_container_url. Einmal speichern und wir sind bereit für einen ersten Testlauf.
Ein erster Testlauf
Wir aktivieren den Vorschau-Modus unseres Web Containers und besuchen unsere Website. Wir sehen als erstes, dass unser Google Tag / GA4 Tag ausgelöst wurde. Jetzt passieren im Idealfall zwei Sachen: 1) der Tag sendet Daten an unseren GTM Container und b) unser serverseitiger GTM Container empfängt diese.
Test 1: Sendet unser Google Tag Daten?
Wir wollen beides überprüfen. Ob und wohin der Google Tag Daten sendet, das können wir herausfinden, indem wir in den Entwicklertools unseres Browsers den Network-Tab aufrufen. Hier geben wir einmal "/collect" in das Suchfeld ein (ohne die " natürlich) und schon sollte hier unser Request auftauchen. Ist das nicht der Fall, kann es u.U. helfen die Seite bei geöffnetem Network-Tab einmal neu zu laden.
Wir prüfen einmal den Status unseres Requests und an welche Adresse er geht. Wir sind glücklich, wenn wir hier die URL unseres Servers wiederentdecken (eine URL die run.app enthält) und wir den Status 200 oder 204 haben.
Ist dem nicht so, sollten wir einmal prüfen, ob wir die richtige Server-URL in unserem Google Tag eingetragen haben.
Test 2: Empfängt unser Server Container Daten?
Hierzu müssen wir einmal in den Preview Mode unseres Server Containers wechseln und schauen ob hier der zuvor gesendete Request empfangen wurde.
Eine Custom-Domain erstellen und einrichten
Der Request den wir von unserem GA4-Tag an den GTM Server Container senden, nimmt aktuell den Weg über eine Drittpartei-Domain, die Google gehört ( ... run.app ). Mit anderem Worten: wir betreiben hier 3rd-Party-Tracking. Das wollen wir aber natürlich vermeiden.
Dazu senden wir unsere Requests in Zukunft einfach nicht mehr an die Google Server, sondern zunächst an eine eigene Subdomain, z.B. analytics.deinedomain.de. Damit befinden wir uns wieder in der schönen Welt des 1st-Party-Trackings.
Je nach Hoster sind die Details hier unterschiedlich. Im Großen und Ganzen müssen wir hier lediglich einen DNS-Record in unserer Domain einrichten.
Wir spielen das hier einmal für unsere Google Cloud Run Lösung durch. Wir öffnen zunächst wieder unseren serverseitigen GTM Container und klicken erneut auf unsre Container-ID um uns unsere Serverinfos anzeigen zu lassen. Im nun erscheinen Pop-Up halten wir Ausschau nach unserer Google Cloud Platform Project ID. Neben dieser befindet sich ein Link. Wir folgen diesem und landen in der Google Cloud Platform.
In der Suchzeile oben geben wir Cloud Run ein, wählen es aus und gelangen zu einer Übersicht, in welcher wir zwei Services sehen. Wie an den Namen unschwer erkennbar ist, kümmert sich einer um den Vorschau Modus, der andere um das Tagging.
Wie wir auch feststellen müssen, laufen beide Services über die die USA (Region us-central1). Da wir uns an DSGVO & Co. halten, sieht das nach einem ersten Hindernis aus. Glücklicherweise können wir aber die bestehenden Services einfach kopieren und hier eine Server Region im EU-Inland wählen.
Dazu markieren wir die Checkbox neben dem Server, anschließend auf Kopieren. Im neuen Fenster behalten wir alle Einstellungen bei, bis auf die Serverregion. Wir wählen hier in unserem Beispiel Frankfurt aus und speichern das Ganze. Anschließend können wir den alten Service löschen.
Wir klicken nun auf unseren neu erstellten Tagging Service, klicken dann auf den Tab Integrationen und dann auf Integration hinzufügen.
Hier wählen wir Custom Domains.
Unter dem Punkt Routes geben wir die Subdomain ein, die wir verwenden möchten, etwa analytics.deinedomain.de. Wir stellen vorher sicher, dass diese Subdomain auch auf unsere Server existiert.
Die Pfadeinstellungen können wir belassen, wie sie sind. Bei Service 1 prüfen wir einmal kurz, ob wir auch wirklich unseren Tagging-Server verwendet haben.
Wir aktivieren auch die benötigten APIs. Dies dauert eine Weile. Anschließend klicken wir auf veröffentlichen - und warten erneut eine kurze Weile.
Wir sehen eine Liste an Ressourcen, die installiert werden. Nach und nach sollte hier alles auf grün wechseln, bis auf das SSL Zertifikat. Dieses wird erst aktiv, wenn wir unsere DNS Records anpassen. Am unteren Ende der Custom Domain Einstellungen finden wir die Infos, die wir hierzu benötigen.
Wie das genau funktioniert ist - wie bereits angedroht - je nach Domainanbieter unterschiedlich. Auf Webgo sieht das ganze für uns wie folgt aus:
Wir speichern also unseren neuen DNS-Record und warten ein wenig. Nach kurzer Zeit sollte auch das SSL Zertifikat fertiggestellt sein. Unsere Custom Domain Integration ist nun aktiv.
Als nächstes wechseln wir in unseren serverseitigen GTM Container. Im Adminbereich wählen wir die Container-Einstellungen, fügen unsere Subdomain als Server Container URL ein und speichern.
Im Web-Container wiederum öffnen wir unseren Google Analytics 4 Tag und ändern nun den Wert von unserem server_container_url-Parameter auf unsere Subdomain. Haben wir weitere GA4-Tags (z.B. für Events, Conversions o. Ä.), sollten hier die Serverkonfigurationen in gleicher Weise angepasst werden.
Den Server upgraden
Damit unser serverseitiger GTM Container auch mit dem Traffic unserer Website zurechtkommt und wir keine Lücken in unserem Tracking haben, sollte unser Server einmal geupgraded werden.
Dazu kehren wir wieder zur Google Cloud Plattform zurück, wie bereits zuvor: In unserem Server Container klicken wir auf unsere GTM-ID und im sich daraufhin öffnenden Popup auf den Link neben unserer Google Cloud Plattform Project ID. Hier suchen wir erneut nach Cloud Run.
Wir wählen unseren Tagging-Server (nicht den Preview-Server!) aus und klicken auf den furchtbar benannten Button "Neue Überarbeitung überarbeiten und bereitstellen".
Im Abschnitt Autoscaling setzen wir das Minimum an Instanz auf 2 und das Maximum auf 10. Anschließend klicken wir auf Bereitstellen.
Eine Serverinstanz kostet im Schnitt 35-45 EUR. Bei einem Minimum von 2 Instanzen kommen wir somit auf monatliche Kosten von min. 70 - 90 EUR. Fällt viel Traffic an schaltet sich Google Cloud Run entsprechend hoch, wodurch wir hier mehr Instanzen verwenden und für uns hier auch höhere Kosten anfallen. Es gibt weitere Faktoren, die den Preis beeinflussen können, etwa die Anzahl an Requests, Logging o.Ä..
Die genauen Kosten für Server Side Tracking mit Google Cloud Run lassen sich also nur schwer im Voraus bestimmen. Wie hoch die Kosten tatsächlich ausfallen, dazu hat man nach einer kurzen Testphase deutlich verlässlichere werte.
Veröffentlichen
Jetzt sollte alles erledigt sein. Wir veröffentlichen die Änderungen in unseren Containern, falls noch nicht geschehen. And we are good to go.
Gratulation, wir haben soeben den Grundstein für unser Server Side Tracking gelegt.
Nächste Schritte
Es gibt viele weitere Punkte, die als nächstes angegangen werden sollten.
- Kosten senken: Wie bereits angerissen gibt es viele Faktoren, welche die Kosten des Server Side Trackings beeinflussen können. Gerade das Logging kann hier teuer werden. Dies lässt sich zum Glück abschalten.
- Transformationen: was Server Side Tracking u.a. hinsichtlich Datenschutz so interessant macht, ist, dass wir die Datenhoheit haben und Daten bearbeiten können, bevor wir sie z.B. an Google Analytics oder andere Drittanbieter schicken.
Weitere Literatur & Links
- Unser eigener Artikel zu Server Side Tracking natürlich
- Die Google Dokumentation https://developers.google.com/...
- Simo Ahavas Beitrag zur Einrichtung von Server Side Tracking mit Cloud Run geht stellenweise mehr ins Detail und ist wie immer sehr lesenswert
