Die Zukunft der Webanalyse trackt serverseitig – das habe ich bereits in diesem Blogartikel umfangreich erläutert und dabei einige Tool-Anbieter genannt. Jetzt geht es um die serverseitige Tracking Lösung von Google mit dem Google Tag Manager und Google Cloud Run.
Inhalt
- 1 Intro Serverseitiges Tracking
- 2 Alle Vorteile: Serverseitiges Tracking mit Google
- 3 Nachteile: Serverside Tracking mit Google
- 4 Vorbereitung: Was du für das serverseitige Tracking mit Google benötigst
- 5 Setup Google Cloud Run
- 6 Alternative #1: WEBkiste Service
- 7 Alternative #2: Stape.io
- 8 Daten-Check: Bessere Daten dank serverside Tracking
- 9 Fragen?
Intro Serverseitiges Tracking
>> Intro überspringen und gleich mit der Google-Lösung losstarten.
Warum der Umstieg vom client- auf serverside Tracking?
Der Umstieg vom aktuell client-seitigen auf das serverseitige Tracking ist immer dringender empfehlenswert, da die Datenqualität in Google Analytics aufgrund diverser Cookie-Einschränkungen stetig abnimmt.
Anfangs waren es „nur“ Ad Blocker und Cookie Blocker.
Dann kam ITP & Co – die Intelligent Tracking Prevention.
Diese führt seit 2019 zu einer schlechten Wiedererkennbarkeit der Nutzer in allen Analyse- und Werbetools, da die Cookie-Laufzeit in gängigen Browsern auf 7 (!) Tage beschränkt ist.
User die über Tracking Capabilities wie die gclid oder fcblid kommen, werden sogar nach nur 24 Stunden (!) nicht mehr wiedererkannt.
Eine verkürzte Cookie-Laufzeit (7 Tage / 24h) klingt im ersten Moment gar nicht so schlimm. Die Auswirkungen sind aber tatsächlich dramatisch:
>> Details im Blogartikel: Serverside Tracking Teil 1 – Cookies, ITP und der unvermeidbare Datenverlust
Gängige Browser, dass sind:
- Safari
- Firefox und
- Edge
Google wehrt sich mit Chrome vehement ähnliche Maßnahmen zu ergreifen – hat jedoch angekündigt 2024 nachzuziehen.
Allerspätestens 2024 wird serverseitiges Tracking in aller Munde sein…
Wie funktioniert serverseitiges Tracking?
Google Analytics und die meisten anderen Tools funktionieren Cookie🍪-basiert um Website-Nutzer wiederzuerkennen.
Anders als beim client-seitigen Tracking, werden beim serverseitigen Tracking die Daten zuerst vom Browser des Users an einen eigenen Webserver gesendet, bevor sie anschließend weiter an bspw. Google Analytics übertragen werden, wie folgende Grafik zeigt:
Was bleibt sind die Cookies🥮.
Diese werden jedoch serverseitig von deinem Proxy gesetzt und funktionieren dabei so stark wie ein Login-Cookie. Sie sind somit für Ad-Blocker, Cookie-Blocker und Tracking-Präventionen unantastbar.
Neben der Sicherstellung der Datenqualität ergeben sich daraus zahlreiche weitere Vorteile wie bspw. Datenhoheit, Datenkontrolle und eine schnellere Seitenladezeit.
>> Details im Blogartikel: Serverside Tracking Teil 1 – Vorteile des serverseitigen Trackings
Wann ist der beste Zeitpunkt für den Umstieg?
Jederzeit – aber: Je früher, desto besser!
Denn es geht um die Datenqualität in deinen Analyse- und Werbetools.
Tatsächlich bietet sich der Umstieg auf das serverseitige Tracking mit dem Umstieg auf das neue Google Analytics 4 sehr gut an.
Mit dem Umstieg auf GA4 sollte im besten Fall das gesamte Tracking einmal überarbeitet werden. Im Zuge dessen kann die Umstellung auf das serverseitige Tracking gleich mitgemacht werden.
Der Vorteil: Du startest mit der bestmöglichste Datenqualität in GA4.
Falls du bereits auf GA4 umgestiegen bist, kein Problem. Du kannst die Umstellung auf das serverseitige Tracking jederzeit nachziehen.
Meine Empfehlung: Notier dir den Zeitpunkt ab wann du auf das serverseitige Tracking umgestiegen bist, um die Änderung in der Analyse zu berücksichtigen.
Egal wann, ran an das serverseitige Tracking – im einfachsten und günstigsten Fall mit der Google Lösung.
Im folgende erkläre ich dir warum:
Alle Vorteile: Serverseitiges Tracking mit Google
Wer, wenn nicht Google, bietet eine serverseitige Tracking-Lösung.
Dazu kann die Google Cloud oder jede beliebige andere Cloud wie bspw. Azure (Microsoft), AWS (Amazon) oder ein eigener Server genutzt werden.
>> Hier findest du den Leitfaden für die manuelle Einrichtung.
Hinweis: Ein eigener Server ist nur dann empfehlenswert, wenn du eine eigene IT-Abteilung hast die sich 24/7 um den Server kümmert und entsprechend wartet. Ein vServer von bspw. Hetzner oder normales Webhosting ist dafür nicht geeignet, da dieser zu langsam läuft (= schlechte Performance), Lastspitzen nicht tragen kann oder deutlich teurer ist.
Am einfachsten funktioniert das Setup natürlich mit der Google Cloud – darauf setzten wir den Fokus in diesem Blogartikel.
Der Vorteil an der Google Cloud ist, das Google 24/7 die Wartung der Server übernimmt und eine 99.9%ige Ausfallsicherheit garantiert. Im besten Fall ist das serverseitige Tracking also einmal aufgesetzt und du musst dich nicht weiter darum kümmern.
Das ist sehr bequem.
Google bietet für das serverseitige Tracking Setup aktuell zwei Lösungen:
- ➖ Google App Engine – einfach dafür teurer
- ➕ Google Cloud Run – kompliziert dafür günstiger
➖ Googles App Engine
In der „Klick-klick-klick“ Do-it-yourself Lösung verwendet Google die App Engine.
Google empfiehlt mindestens drei Server-Instanzen parallel aufzusetzen, um Ausfallsicherheit und Lastspitzen zu gewährleisten. Pro App Instanz kannst du mit ca. 50€ / Monat rechnen, d.h. es fallen ca. 150€ an Serverkosten an.
Monatlich.
Das ist viel – vor allem, wenn du eventuell nur eine kleine Seite betreibst und für Tracking plötzlich mehr bezahlen musst, als für Hosting und Website gemeinsam.
Update: Im Dezember 2023 hat Google für das automatische Setup die App Engine ersetzt und verwendet ebenfalls Cloud Run. Allerdings ist die Konfiguration von Google ähnlich teuer und als Serverstandort ist die USA konfiguriert und nicht veränderbar.
Besser ist daher die „Nicht-Klick-klick-klick“ Lösung via Google Cloud Run:
➕ Google Cloud Run
Das Setup mit Google Cloud Run ist zwar komplizierter und muss wahrscheinlich von deinem Webmaster oder einer Agentur eingerichtet werden, dafür profitierst du von drei Vorteilen:
1.) Google Cloud Run ist selbst skalierend.
Beim Setup muss eine mini- und maximale Anzahl an Instanzen angegeben werden. Cloud Run skaliert automatisch runter auf die Mindestanzahl, wenn gerade wenig Traffic auf der Website ist, und und automatisch hoch, wenn der Traffic ansteigt.
Bezahlt wird, was du tatsächlich verbrauchst.
Sprich:
2.) Google Cloud Run ist kostengünstig.
Ein Cloud Run Service mit einer CPU und 256MB Arbeitsspeicher kann ca. 30 Millionen Anfragen verarbeiten. Die geschätzten Kosten laut Google Cloud Calculator betragen ca. 50€.
Benötigst du weniger Requests, bezahlst du weniger.
Benötigst du mehr Requests, bezahlst du mehr.
Mit genau diesem Setup betragen die Kosten für meine ANALYTICSkiste aktuell bspw. 5€/Monat.
Das ist leistbar. 💪
Info: Die genauen Preise für Google Cloud Run kannst du hier nachlesen.
Google stellt für die ersten drei Monate einen Gutschein in Höhe von 300€ zur Verfügung.
3.) Google Cloud Run Server stehen in einem europäischen Rechenzentrum, wenn gewünscht.
Ein weiterer Vorteil von Cloud Run ist, dass du beim Setup das Rechenzentrum auswählen kannst, in welchem die Server stehen. Dabei kannst du Europa (europe-west1) auswählen. Diese Server stehen in Belgien.
Ein europäisches Rechenzentrum hat zwei Vorteile:
- Datenschutz.
- Bestmögliche Performance, durch geografische Nähe zum Website-Besucher.
Ein weiterer Bonus ist, dass der Serverstandort einen niedrigen CO2-Wert aufweist.
Das bedeutet nicht:
Aber es ist der richtige Weg. 🙃
Daher meine Empfehlung: Setup via Google Cloud Run – darauf legen wir auch den Fokus in diesem Blogartikel.
Somit sind die Kosten ein großer Vorteil, die Google verhältnismäßig günstig ansetzt – egal ob AppEngine oder Cloud Run. Alternativen Lösungen sind vermutlich deutlich teurer.
Wichtig: Serverseitiges Tracking ist NICHT kostenlos. Es benötigt einen Server und dieser ist in der Regel kostenpflichtig.
Im Vergleich dazu, kostet das Hosting deiner Website bei einem Hostinganbieter wie World4You oder Cloudanbieter wie Hetzner ebenfalls monatlich ein paar Mücken💸.
Server GTM Container
Zusätzlich zur Google Cloud benötigst du einen serverseitigen Google Tag Manager Container. Dazu weiter unten mehr.
Wichtig: Der serverseitige GTM Container ergänzt deinen bisher genutzten Web GTM Container.
Den Web GTM Container kannst du also weiterhin und wie gewohnt nutzen. Alles läuft wie bisher – nur eben serverseitig bzw. eigentlich hybrid.
Das ist auch ein weiterer Vorteil von Google:
Google Ökosystem
Alle Google-Produkte können nahtlos miteinander und untereinander integriert werden.
Das gilt auch für andere Google Services wie bspw. BigQuery, Firestore, etc.
Deswegen ist die serverseitige Tracking Lösung von Google vermutlich die beste Wahl für KMUs, die vor allem die Kosten im Auge haben.
Zusammengefasst
Die Vorteile zusammengefasst:
- Flexibles Setup: Google Cloud, Azure, AWS & Co
- Relativ einfaches Setup
- Kostengünstig
- Europäischer Server-Standort
- Google Tag Manager weiterhin nutzbar (+ Server GTM Container)
- Nahtlose Integration aller Google Produkte
- Schneller Umstieg
Die Sache hat allerdings einen einzigen kleinen Haken:
Nachteile: Serverside Tracking mit Google
Rechtlich gesehen ist es irrelevant, ob eine US-Cloud ihren Server-Standort in Europa oder in den USA hat.
FISA (Foreign Intelligence Surveillance Act) und das Cloud-Gesetz erlaubt US-Überwachungsbehörden den Zugriff auf Daten von US-Unternehmen.
Somit ist eine Einhaltung der DSGVO mit einer US-Cloud und somit mit der Google-Cloud im Prinzip nicht möglich – egal ob das Rechenzentrum in Belgien steht oder nicht. Allerdings nur, wenn es kein Abkommen zwischen USA und Europa gibt.
Wichtig: Seit 14. Juli 2023 gibt es wieder ein Abkommen zwischen der USA und Europa – das Trans-Atlantic-Data-Privacy-Framework (TADPF).
Damit ist die Datenübertragung von der EU in die USA geregelt und somit der rechtssichere Einsatz von Google Analytics (und allen anderen US-Tools) in Europa gewährleistet werden – nachdem sowohl das Safe-Harbour Abkommen von 2015 als auch das Privacy-Shield von 2020 aufgehoben wurden.
Der Einsatz von Google Analytics und allen anderen US-Tools wie Meta, Mailchimp, Cloudflare und Open AI wird mit dem TADPF also wieder legal – jedoch erst nachdem sich US-Unternehmen nach dem DPF zertifiziert haben lassen.
Wichtig: Google hat diese Zertifizierung bereits wenige Tage später vorgenommen.
Allerdings, wenn Datenschutz für dich und dein Unternehmen auf aller oberster Priorität steht, empfehle ich einen alternativen Anbieter für serverseitiges Tracking:
Wichtig: >> Hier findest du eine Liste alternativer Anbieter für serverseitiges Tracking.
Schau dir auf jeden Fall auch JENTIS im Detail an.
Wenn du dich für Google entscheidest, dann folgen nun die Details:
Vorbereitung: Was du für das serverseitige Tracking mit Google benötigst
Im Grunde genommen benötigst du nur drei Dinge für das serverseitige Tracking Setup mit Google:
- Tracking-Domain
- Google Cloud Projekt
- Server GTM Container
Starten wir los:
Auswahl der Tracking-Domain
Egal ob serverseitiges Tracking mit Google oder einem anderen Anbieter, du benötigst IMMER eine eigene Tracking-Domain.
Erst dadurch werden die Tracking-Daten nicht direkt an google-analytics.com sondern über deine Domain an den deinen Server geschickt. Erst anschließend leitet dein Server die Daten an Google weiter:
Die Domain des Trackingservers muss eine Subdomain deiner Website sein.
Nur so kann der Server die gewünschten First-Party Cookies🍪 setzen.
Was war nochmal der Unterschied zwischen 1st- und 3rd-Party Cookie?
1st-Party Cookies hast du selber gebacken. 👩🏻🍳
Es sind deine Cookies, welche von dir selbst gesetzt und nur für deine Website geeignet sind.
Im Vergleich dazu: 3rd-Party Cookies hast du zwar selber gekauft🍘 oder geschenkt bekommen🍥 – jedenfalls von „extern“ bezogen. Deswegen sind sie „grauslich“. Du weißt nicht, was alles drinnen ist und ob du sie gut verträgst.
Third-Party Cookies sind fremde Cookies, welche von irgendwem gesetzt werden, der eigentlich nicht zu deiner Website gehört.
Ich empfehle als Tracking-Domain gerne die data.-Subdomain.
Das ist wunderschön unabhängig von “tracking” und “gtm” und wird daher am wenigsten von Browsern, Adblockern & Co blockiert. “data” ist unabhängig und kann alles sein.
Beispiel: data.deinedomain.com
Wichtig: Wenn du mehrere Domains nutzt, wie bspw. deinedomain.at, deinedomain.de und deinedomain.ch, benötigst du jeweils eine eigene Tracking-Subdomain pro Domain. Andernfalls setzt du Third-Party Cookies, welche von allen Browsern außer Chrome gänzlich blockiert werden.
Du kannst aber für alle drei Domains einen einzigen Tracking-Server verwenden. 👍
Hast du deine Tracking-Subdomain gewählt, muss diese im nächsten Schritt eingerichtet werden:
Setup der Tracking-Domain
Damit die Tracking-Daten über deine Domain an den deinen Server geschickt werden können, musst du die Domain entsprechend konfigurieren.
Dazu müssen folgende Einträge für die Domain hinzugefügt werden:
- 4x A-Einträge
- 4x AAAA Einträge und
- 1x TXT Eintrag
Wichtig: Es müssen A und AAAA Einträge sein, ein CNAME reicht nicht aus!
Eine nicht korrekt konfigurierte Domain wird von den Browsern als “CNAME-Cloaking” identifiziert und als nicht vertrauenswürdig eingestuft (siehe ITP).
Für Redundanz und Load-Balancing müssen es jeweils 4 Einträge sein.
Der TXT-Eintrag ist der Google-Site-Verfication Code.
Dieser ist eine Sicherheitsvorkehrung damit nicht irgendwer irgendwelche Einstellungen an deiner Domain vornehmen kann: Der, der den Google-Site-Vertification-Code generiert, muss im Anschluss die Domain am Tracking-Server verifizieren.
Den Google-Site-Verfication-Code erhältst du über die URL der Webmaster-Zentrale.
Hänge dazu hinter folgender URL deine Tracking-Domain an und rufe die URL im Anschluss auf:
https://search.google.com/search-console/not-verified?original_resource_id=https://data.deinedomain.com
Klicke auf „Inhaberschaft bestätigen“.
Wähle ganz unten „Domainname-Anbieter“ – auch wenn Google ggfs. sagt, dass du keinen Zugriff darauf hast.
Der Eintragstyp ist „TXT (empfohlen)“.
Der Google-Site-Vertification-Code wird nun automatisch generiert:
Jetzt hast du alles was du benötigst und kannst die folgenden DNS-Settings für deine Domain hinzufügen (lassen):
data.deinedomain.com TXT google-site-verification=Iv2tsNLzItZQgDo8AC5CNqJSRXWZdHWmq7a-v476cyw data.deinedomain.com A 216.239.32.21 data.deinedomain.com A 216.239.34.21 data.deinedomain.com A 216.239.36.21 data.deinedomain.com A 216.239.38.21 data.deinedomain.com AAAA 2001:4860:4802:32::15 data.deinedomain.com AAAA 2001:4860:4802:34::15 data.deinedomain.com AAAA 2001:4860:4802:36::15 data.deinedomain.com AAAA 2001:4860:4802:38::15
Hinweis: Die IP-Adressen sind für alle gleich, nur der Site-Verification Code ändert sich.
Sobald die DNS-Settings der Tracking-Subdomain korrekt hinzugefügt sind, kann die Domain bestätigt und bei Cloud Run der Service hinzugefügt werden.
Zuerst muss jedoch das Google Cloud Projekt erstellt werden:
Google Cloud Projekt einrichten
Alles was mit Cloud-Computing zu tun hat, läuft bei Google in der Google Cloud. Es ist auch die Infrastruktur, die Google für seine eigenen Produkte (Google Suche, YoutTube, etc.) nutzt.
Wir wollen den Cloud-Dienst „Cloud Run“ nutzen und müssen dazu erst ein Google Cloud Projekt erstellen.
Rufe dazu folgende URL auf:
Wähle einen passenden Projektnamen bspw. mycompany-serverside-gtm.
Den Speicherort kannst du auf „Keine Organisation“ lassen.
Klick auf „Erstellen“.
Im nächsten Schritt musst du die Abrechnung aktivieren – andernfalls kannst du keine Cloud-Services nutzen. Da ist Google sehr pingelig.
Rufe dazu folgende URL auf:
Wenn dein Unternehmen bereits Google Cloud Projekte im Einsatz hat, kannst du auf „Rechnungskonto verknüpfen“ klicken und deinem neuen Projekt ein vorhandenes Rechnungskonto hinzufügen.
Alternativ kannst du “Rechnungskonten verwalten” auswählen und auf der folgenden Seite ein neues Rechnungskonto erstellen.
Wichtig dabei ist, dass du die richtige Währung auswählst und nach der Eingabe aller notwendigen Firmen-, Kontakt- und Kreditkartendaten, die Abrechnung auch tatsächlich aktivierst. Andernfalls können die Services in der Google Cloud nicht genutzt werden.
Nochmals: Da ist Google sehr (sehr) pingelig.
Zuletzt muss noch der Server-GTM erstellt werden:
Server GTM erstellen
Damit das serverseitige Tracking mit Google funktioniert, benötigst du zusätzlich zu deinem Web-GTM-Container einen Server-GTM-Container.
Hinweis: Einen Server GTM Container benötigst du auch wenn du eine andere Cloud wie bspw. Azure (Microsoft), AWS (Amazon) oder ein eigener Server nutzt. Es ist das Verbindungsstück zwischen Web-GTM und deinem Tracking-Server.
Das geniale an der Google-Welt ist, dass du weiterhin und wie gewohnt deinen Web-GTM-Container für deine Tracking Tags, Trigger und Variablen nutzen kannst. Alles bleibt wie bisher – nur zusätzlich wird ein weiterer Container, der Server-Container, eingesetzt.
Beim serverseitigen Tracking mit Google hast also zwei Container im Einsatz:
- Web-GTM Container
- Server-GTM Container
Den Web-GTM hast du in der Regel bereits im Einsatz.
Den Server-GTM Container legen wir jetzt gemeinsam an.
Rufe dazu folgende URL auf:
Erstelle einen neuen Container in deinem bestehenden GTM Account:
- Container Name: deinewebsite.com SERVER
- Zielplattform: Server
Klicke nach dem Erstellen des SERVER GTM Containers auf „manuelle Einrichtung“ um Google Cloud Run als Dienst verwenden zu können.
Speicher dir die Configuration ID ab – diese benötigst du für das Google Cloud Run Setup:
Im Server-GTM Container hast du nun die Möglichkeit Clients, Tags, Trigger und Variablen zu definieren.
Clients nehmen eingehende Anfragen an und geben diese an Tags zur Verarbeitung weiter, wenn der Trigger für diesen Tag zutrifft.
GA4
Erstelle für GA4 einen GA4-Client (meist schon automatisch erstellt).
Dieser nimmt Anfragen entgegen, bei denen die URL mit der Signatur für GA4-Anfragen übereinstimmen.
Du benötigst weiters einen GA4 Tag mit Trigger.
Durch den Trigger “Wenn Client enthält GA4” bekommt der GA4-Tag die entsprechende Anfrage zugewiesen.
Der Tag übernimmt die Verarbeitung und leitet die Daten an Google Analytics weiter. Er beantwortet die Anfrage mit einem Status Code und neuen/aktualisierten Cookies.
Vorteil: Die Standard-GA-Tags anonymisieren die IP Adresse für Universal Analytics und Google Analytics 4 automatisch. Das letzte Octet ist immer 0.
Google Ads
Auch das Google Ads Tracking kann auf serverseitig umgestellt werden.
Der Vorteil ist ebenfalls eine verlängerte Cookie-Laufzeit (max. 90 Tage) und somit mehr und richtigere Daten für deine Werbeanzeigen.
Dazu müssen alle Google Ads Conversion Tags inkl. Conversion Linker vom Web-GTM Container in den Server-GTM Container übersiedelt werden.
>> Lesetipp: Google Ads Conversion Tracking: GA4 oder GTM?
Facebook Conversion API
Auch das Facebook Tracking kann auf serverseitig umgestellt werden. Facebook bietet dazu die Conversion API.
Der Vorteil ist ebenfalls eine verlängerte Cookie-Laufzeit (max. 90 Tage) und somit mehr und richtigere Daten für deine Werbeanzeigen.
Wichtig: Facebook empfiehlt für ein reibungsloses Tracking, zusätzlich zur Conversion API auch das Facebook Pixel einzusetzen.
Wird parallel zur Facebook Conversion API auch das Facebook Pixel eingesetzt, muss du zusätzlich eine eindeutige ID der Anfrage an Facebook weiterleiten. Nur so kann Facebook das Event deduplizieren, falls es sowohl über das Pixel als auch über die CAPI geschickt wurde. Andernfalls trackst du Daten doppelt.
Web GTM und Server GTM verknüpfen
Zuletzt muss noch der Web-GTM mit dem Server-GTM verknüpft werden, damit die beiden Container „miteinander sprechen“.
Dazu muss jedoch nur im Web-GTM in der Google Analytics 4 Konfiguration (Google Tag) ein neuer Konfigurationsparameter „server_container_url“ hinzugefügt werden und als Server-URL die neue data.-Tracking-Subdomain eintragen werden:
Fast fertig.
Optional, aber aus Datenschutzsicht absolut empfehlenswert ist, den GTM Basistracking-Code auf die Tracking-Subdomain auszubessern:
<!-- Google Tag Manager --> <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://data.deinedomain.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-123XYZ');</script> <!-- End Google Tag Manager -->
Dazu muss im Server GTM noch der Client „GTM Web Container“ hinzugefügt und die Web GTM Container ID angeben werden.
Nur damit wird auch der Web-GTM Container von deinem Server geladen.
Die IP-Adresse des Users wird somit nie direkt an Google nach Amerika gesendet, sondern immer zuerst anonymisiert.
Lässt du www.googletagmanager.com als Tracking-Domain, funktioniert das serverseitige Tracking zwar auch – aber ohne dem Datenschutz-Vorteil.
JETZT sind wir mit der Vorbereitung fertig. 🙌
Zusammengefasst
Für das serverseitige Tracking mit Google Cloud Run benötigst du vorbereitend:
- Eine Tracking-Domain.
- Ein Google Cloud Projekt mit hinterlegten Zahlungsdaten.
- Einen Server GTM Container.
Im nächsten Schritt geht es auch schon an die Einrichtung des Google Cloud Run Services:
Setup Google Cloud Run
Für das Setup deines Google Cloud Run Tracking-Servers benötigst du im Prinzip nur zwei Dinge – und gaaaaaanz viel Testing:
- Preview-Server
- Tracking-Server
Starten wir los:
Preview Server erstellen
Das Erstellen des Tracking-Servers mit Google Cloud Run basiert auf dem Manual-Setup-Guide von Google.
Gehe dazu in die Google Cloud und erstelle einen neuen Google Cloud Run Dienst:
Google stellt ein Docker Image zur Verfügung. Dieses lädt periodisch die Konfiguration des Google Tag Manager Server-Containers und führt diese für ankommende Anfragen aus.
Gib folgende Docker Image URL als Container-Image URL an:
gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
Weiters müssen einige Einstellungen vorgenommen werden.
Als Region empfehlen wir aus Datenschutz- und Performancegründen europe-west1 (= Belgien).
Als Mindestanzahl der Instanzen wähle 0. Als maximale Anzahl 1.
Unter “Variablen und Secrets” → CONTAINER_CONFIG muss die Configuration ID des Server GTMs hinzugefügt werden.
Da dies nur der Preview-Server ist, muss RUN_AS_PREVIEW_SERVER auf “true” gesetzt werden.
“Erstellen” klicken und warten bis der Server fertig erstellt ist.
Kopiere die URL des Preview Servers – diese benötigst du im nächsten Schritt.
Weiter geht es mit dem Tagging Server:
Tagging Server erstellen
Für die Erstellung des Tagging Servers muss ein weiterer Cloud Run Dienst erstellt werden.
Die Container-URL ist dieselbe wie für den Preview-Server:
gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
Damit der Server selbst skalierend funktioniert, d.h. die Anzahl der Instanzen automatisch erhöht, wenn mehr Traffic auf der Website ist und automatisch wieder runter fährt, sobald der Traffic zurückgeht, muss unter AUTOSCALING eine Mindest- und eine Maximalanzahl an Instanzen vergeben werden.
Um einen Kaltstart zu vermeiden wählen als Mindestanzahl: 1
Um eine Kostenexplosion zu vermeiden wählen wir als Maximalanzahl gerne: 10
Hinweis: Das Maximum von zehn Server-Instanzen ist ein Erfahrungswert, der gut für mittelgroße Websites passt. Für größere Websites mit mega (mega) viel Traffic, könnten mehr Instanzen notwendig sein. Das muss individuell getestet werden.
Wichtig: Wird das Maximum der Instanzen erreicht und es kommt weiterhin (zu) viel Traffic hinzu, kann der Server die Anfragen irgendwann nicht mehr abarbeiten und es werden nicht mehr 100% der Daten getrackt. Im schlimmsten Fall fehlt somit ein wichtiger Anteil der Tracking-Daten.
Empfehlung: Anzahl der Maximalen Server-Instanzen für dich testen und ggfs. hochstellen.
Unter “Container, Netzwerk, Sicherheit” im Punkt „Umgebungsvariablen“ → CONTAINER_CONFIG muss die Configuration ID des Server GTMs hinzugefügt werden.
Da dies nun der Tagging-Server ist, muss hier als PREVIEW_SERVER_URL die URL des Preview-Servers angegeben werden.
“Erstellen” klicken und warten bis der Server aktiv ist.
Sobald der Cloud Run Server aktiv ist kann der letzte Schritt vorgenommen werden:
Tracking Domain hinzufügen
Zuletzt muss deine Tracking-Subdomain (data.deinedomain.com) hinterlegt werden.
Wähle dazu im Cloud Run Dienst “Benutzerdefinierte Domains verwalten” aus:
Unter “Zuordnung hinzufügen” muss der Tagging-Server ausgewählt werden (NICHT der Preview Server).
Nun kann eine Domain ausgewählt und die data.-Subdomain eingetragen werden.
Dann auf “Weiter” klicken und die Domain bestätigen.
Jetzt ist die Tracking-Subdomain mit dem Cloud Run Server verknüpft. ✅
Testing
Um zu prüfen ob das serverseitige Tracking korrekt funktioniert, rufe deine data.-Subomain wie folgt auf:
https://data.deinedomain.at/healthy
Wird als Status “OK” zurückgegeben, läuft der Container korrekt. ✅
Prüfung der Server-Auslastung
Die Auslastung des Cloud Run Services kannst du unter “Messwerte” abgelesen:
Das erste Feld zeigt die “Anzahl der Anfragen”.
Das dritte Feld zeigt die „Anzahl der Container-Instanzen“.
Die Container-Instanzen werden automatisch an die aktuelle Last (Traffic) auf der Website angepasst und rechtzeitig neue Instanzen gestartet. Die Instanzen sind durch die Konfiguration der maximalen Anzahl begrenzt.
Nach ca. einer Woche kann meist ganz gut eingeschätzt werden, wie viele Instanzen für deine Website notwendig sind. 10 Instanzen sind ein guter Erfahrungswert und reicht in der Regel für mittelgroße Websites. Eine höhere Anzahl kann unerwartete Kosten bedeuten, sollte eine mutwillige Attacke (DDOS) die Last künstlich erhöhen.
Wichtig: Wir empfehlen individuell zu überprüfen, welche Anzahl an max. Instanzen für deine Website ausreichen.
Server Kosten kontrollieren
Über das Google Cloud Abrechnungskonto kannst du Details zu den Kosten des Cloud Run Services abrufen.
Eine monatliche Aufstellung könnte so aussehen:
Google Cloud Benachrichtigung erstellen
Um über ungewöhnliches Verhalten informiert zu werden, können in der Google Cloud “Benachrichtigungen” (Alerts) erstellt werden.
Ich empfehle das Setup von mind. zwei Benachrichtigungen:
- Benachrichtigung bei Traffic-Spitzen, damit ggfs. manuell das Instanzen-Limit hochgestellt werden kann.
- Benachrichtigung bei Tracking-Ausfall (Instanzen=0).
Benachrichtigungen können direkt bei den Dienstdetails unter Messwerte erstellt werden.
Klicke dazu beim entsprechenden Messwert auf das 3-Punkt-Menü –> Benachrichtigungsrichtlinie erstellen:
Zusammengefasst + Empfehlung
Für das Setup des Google Cloud Run Servers benötigst du im Prinzip nur zwei Schritte – jedoch, ehrlicherweise, auch jede Menge Erfahrung:
- Preview-Server
- Tagging-Server
Das Setup sollte daher gut durchgetestet werden.
Wenn irgendwo irgendwas nicht korrekt funktioniert, bedeutet das im schlimmsten Fall: Keine Daten in Google Analytics!
Weil das manuelle Setup aber nicht jedermanns Sache ist, gibt es zwei Alternativen:
Alternative #1: WEBkiste Service
Achtung: Hier folgt schonungslos Werbung – aber irgendwie gehört’s halt dazu…
Eine mögliche Alternative ist, dass wir das manuelle Setup für dich übernehmen.
D.h. wir durchlaufen den gesamten Prozess, den wir in diesem Blogartikel beschrieben haben, gemeinsam.
Wichtig: Ein ausgezeichnetes serverseitiges Tracking Setup benötigt eine ausgezeichnete Zusammenarbeit.
Deswegen teilen sich die Aufgaben auf.
Deine Aufgaben sind:
- Setup Google Cloud Projekt
- Setup data.-Subdomain
Setup Google Cloud Projekt
Es ist super mega wichtig, dass DU das Google Cloud Projekt erstellst, denn die Inhaberschaft lässt sich nicht übertragen.
Nur so behältst du die Data-Ownership über deine Daten.
Der Einfachheit-halber stellen wir aber einen Schritt-für-Schritt Guide zur Verfügung. ✅
Setup data.-Subdomain
Die Konfiguration der Subdomain kannst ebenfalls nur du – oder dein Webmaster / deine IT – übernehmen.
Wir erstellen den Google Site Verfication Code für dich und bestätigen die Domain für dich. ✅
Den Rest erledigen wir:
- Setup Server GTM
- Verknüpfung Server GTM mit dem Web GTM
- Setup Google Cloud Run für Google Analytics
- Setup Google Cloud Run für Google Ads (bei Bedarf)
- Setup Google Cloud Run für Facebook (bei Bedarf)
- Setup Google Cloud Alerts
- Monitoring der Server Instanzen bis zur optimalen Einstellung
- Mögliche Setup-Verbesserungen da sich die Technologie seitens Google (noch) laufend ändert
- Support
Vorteile
- Done-for-you (aber gemeinsam)
- Monitoring der Server Instanzen bis zur optimalen Einstellung
- Mögliche Setup-Verbesserungen da sich die Technologie seitens Google (noch) laufend ändert
- Support
- Niedrige laufende Kosten
Nachteile
- Initiale Setup-Kosten
Klingt gut? >> Dann freuen wir uns über deine Anfrage. 🙃
Alternative #2: Stape.io
Eine zweite mögliche Alternative zum manuellen Google Cloud Setup ist Stape – ein serverseitiger Tracking Anbieter aus der USA.
Mit Stape verwendest du ebenfalls einen serverseitigen Google Tag Manager Container. Diesen musst du weiterhin selber konfigurieren. Das Cloud-Setup übernimmt Stape und wird mit wenigen Schritten direkt in der Benutzeroberlfäche von Stape vorgenommen.
Als EU-Cloud verwendet Stape Scaleway statt der Google Cloud. Die Lösung ist daher datenschutzkonform.
Für bis zu 10.000 Requests (= sehr, sehr kleine Websites) ist Stape kostenlos.
Bis zu 500.000 Requests kostet Stape 20€/Monat. Danach wird es deutlich mehr, siehe Pricing.
Vorteile
- Schnelles, sehr einfaches Cloud-Setup
- Keine Setup-Gebühren
Nachteil
- Setup- und Wartung Server-GTM
- Höhere laufende Kosten
Passt für dich, dann geht es mit den Details weiter:
Setup im Schnelldurchlauf
Der Setup-Prozess funktioniert wie folgt:
- Server GTM Container bei Google anlegen, siehe Setup weiter oben
- Bei Stape.io registrieren
- Neuen Stape-Container anlegen
- Server GTM Container Configuration ID eintragen
- Server Location auswählen:
Info: Als Server Location stehen Belgien, Finnland, Deutschland, Amsterdam, Paris und Warschau zur Verfügung. Im besten Fall wählst du jenen Standort, der für dich am Nähesten ist.
- Tracking-Subdomain hinzufügen:
Info: Anders als bei Google muss bei Stape nur ein einziger A-Record im DNS hinzugefügt werden.
- Optional den Custom Loader (das Web-GTM Snippet) und den Anonymizer aktivieren:
- Stape-Snippet auf der Website implementieren
Wichtig: Das GTM Snippet sieht ein wenig anders aus, deswegen muss der Code bspw. bei WordPress manuell statt über das GTM-Plugin hinzugefügt werden.
- Fertig✅
Daten-Check: Bessere Daten dank serverside Tracking
Wie sieht man jetzt das der ganze Hokus-Pokus funktioniert hat? 🤓
Das ist super mega wichtig und der eigentliche Grund, warum wir das alles überhaupt machen.
Zuerst musst du jedoch ein bis zwei Monate serverseitig-getrackte Daten erfassen.
Anschließend siehst du folgende Auswirkungen:
Weniger neue Nutzer in Google Analytics
Du solltest in erster Linie weniger neue Nutzer in Google Analytics 4 sehen, da Nutzer über das serverseitig gesetzte First-Party Cookie besser und länger wiedererkannt werden.
Clientseitiges Tracking:
Serverseitiges Tracking:
Die ANALYTICSkiste verzeichnet ca. -11% weniger Nutzer und -16% weniger neue Nutzer mit meiner serverseitigen Implementierung – das ist gut so!
Es bedeutet, dass User über einen längeren Zeitraum (> 7 Tage / 24h) besser wiedererkannt werden.
Die quantitative Metriken sollten sinken – die qualitative Metriken steigen. ✅
Längere Conversion Pfade in Google Analytics
Eine bessere Wiedererkennung der Nutzer bedeutet automatisch auch längere Conversion Pfade, d.h. du kannst nun viel besser analysieren, wieviele Touchpoints und Kanäle deine User benötigen, bevor sie konvertieren.
Mehr Daten, weil Adblocker umgangen
Positiver Nebeneffekt vom serverseitigen Tracking ist, dass Adblocker umgangen werden. Dadurch solltest du mehr Daten in Google Ads, Facebook und all deinen eingesetzten Werbetools sehen.
Für Google Analytics gilt das nur bedingt, da Adblocker häufig keinen Einfluss auf Google Analytics Cookies haben.
Wenn du also nicht “mehr” Daten in Google Analytics siehst, dann liegt es daran, dass bisher wenige Daten durch Ad- oder Cookieblocker blockiert wurden.
Manchmal macht der Umstieg auf das serverseitige Tracking aber einen deutlichen Anstieg an Daten.
Es ist vermutlich Branchen und Unternehmens-abhängig wie sehr dieser Punkt auf dich zutrifft.
Zusammengefasst
Zusammengefasst solltest du durch den Umstieg auf das serverseitige Tracking in Google Analytics folgende, verbesserte Daten feststellen:
- Weniger neue Nutzer
- Quantitative Metriken sinken – qualitative steigen
- Längere Conversion Pfade
- Mehr Daten, weil Ad- und Cookieblocker umgangen
Das ist mega! 🙌
Fragen?
Du hast eine Frage zum serverseitigen Tracking die dich Nachts nicht schlafen lässt?
👉 Schreibe sie einfach in die Kommentare. Ich helfe, wo ich kann.
Happy Analyzing
Deine Michaela
Mehr über Google Analytics 4 erfahren?
Komm in meine exklusive Analytics Community:
Liebe Michaela,
in dem Abschnitt, wo du die Anpassung des Basiscodes des Tagmanagers meinst, sprichst du vom Basiscode des WEB-Containers, richtig?
Bei mir ist es nämlich so, dass der Web Container in der Konfiguration mit der data-Subdomain nicht funktioniert und auf die Anfrage nach dem Script nur mit HTTPS 400 antwortet.
Der Container ist online und data.subdomain.de/healthy funktioniert auch einwandfrei.
Ich denke mal, dass das daran liegt, dass der WEB Container gar nicht über die data Subdomain zu erreichen ist, weil das nicht explizit konfiguriert ist. Könnte das daran liegen? Ich hab einen bereits vorher existierenden WEB Container genommen, der früher von jemand anderem für die Website eingerichtet wurde.
Oder habe ich einfach einen wichtigen Schritt vergessen? Ich wäre dir über einen Tipp sehr dankbar!
Hallo Malte,
korrekt, du musst den WEB-GTM und den SERVER-GTM noch miteinander verknüpfen, sonst „wissen sie nichts voneinander“ sozusagen.
Dazu musst du im WEB-GTM beim GA4 Config-Tag „Send to server container“ anhakeln und deine Tracking-Subdomain angeben. Dann sollte es funktionieren.
Ganz liebe Grüße
Michaela
Hi Malte,
in dem Fall musst du im Server GTM noch den Client „GTM Web Container“ hinzufügen und die Web GTM Container ID angeben.
Erst dann lässt der SGTM das Laden des Web GTM zu.
Ich ergänze das im Artikel noch, danke für den Hinweis!
Matthias
Hallo,
ich möchte nochmal an die og. Diskussion anknüpfen – da ich ein ähnliches Ergebnis habe.
/healty zeigt „ok“
der Vorschaumodus vom server-Container zeigt aber 404
im Web-Container werden die Daten vom GoogleTag zur benutzerdefinierten URL weitergegeben.
im Server Container ist die ID vom web-Container drin (siehe oben)
Warum zeigt der Server kann keine Ergebnisse im Vorschau-Modus?
Hallo Michael,
hier dürfte der Vorschau-Cloud-Run-Service nicht korrekt mit dem Live-Cloud-Run-Service verknüpft sein. Bitte kontrolliere die Konfiguration „PREVIEW_SERVER_URL in der Cloud Run config“.
Ebenfalls ist es wichtig, dass bei beiden Services die Authentifizierung deaktiviert ist, d.h. „Nicht authentifizierte Zugriffe zulassen“.
Dann sollte es klappen.
Ganz liebe Grüße
Michaela
Hallo Michaela,
vielen Dank für deine Rückmeldung. ich habe mich exakt an Eure Anleitung gehalten
1.) Server-Container erstellt.
2.) Containerkonfiguration ( langer string) gespeichert
3.) Subdomain mit den DNS-Settings erstellt
4.) Cloud Run Konto eingerichtet.
5.) Dienst ssgtm-preview erstellt. Einstellungen:
Image-URL gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
CONTAINER_CONFIG: die containerkonfiguration vom Server-Container
RUN_AS_PREVIEW_SERVER auf true gesetzt.
die URL vom dienst gespeichert.
6.) Dienst ssgtm erstellt. Einstellungen:
Image-URL gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
PREVIEW_SERVER_URL : Die URL von ssgtm-preview
CONTAINER_CONFIG: die containerkonfiguration vom Server-Container
autoscaling: 1- 10
Beide Dienste laufen auf europe-west1 und „nicht authentifiziert zulassen“.
7.) Benutzerdefinierte URL bei cloud-run hinterlegt und mit ssgtm verknüpft.
9.) healthy-> führt zu „ok“.
10.) preview vom Server-Container: error 400
Dich habe Eure Doku mehrfach durchgelesen und konnte keinen Punkt finden, welchen ich übersehen habe. Aber vermutlich ist da doch was, oder?
Hi Michael,
das sieht zwar alles gut aus, wenn es dennoch nicht funktioniert, muss man einmal gemeinsam über das Setup drüber. Das ist ferndiagnostisch leider sehr, sehr schwierig.
Hier kann ich nur anbieten, dass wir das Setup in Form einer Support-Stunde gemeinsam fertigstellen. Bei Bedarf melde dich gerne an: matthias@webkiste.at
Ganz liebe Grüße
Michaela
Guten Morgen,
das gleiche Problem hatte ich auch. Ich habe dann die DNS-Einträge von Google zur Authentifizierung genommen, die bereitgestellt werden, wenn man eine benutzerdefinierte Domain hinzufügt. 24h Stunden warten und dann müsste es gehen.
@Michaela vielen Dank für den tollen Beitrag, der sehr weitergeholfen hat. Könnt ihr den Beitrag vielleicht auf den neuesten Stand bringen? Es gibt ja jetzt nur noch den Google Tag und da ist das Setup ein bisschen anders.
Grüße aus D
Hallo Robert,
vielen Dank fürs weiterhelfen und Blogartikel ist nun wieder auf den neuesten Stand gebracht. 👍
Ganz liebe Grüße
Michaela
Hallo Robert, wo genau hast du welche DNS Einträge zur Authentifizierung genommen? Habe auch das 400-Problem.
Danke vorab
Andreas
Hi Andreas,
wenn du einen 400er Error bekommst, wenn du die SGTM Preview nutzen willst, dann ist den Preview Server nicht richtig aufgesetzt.
Kontrolliere doch nochmal, ob sich bei den Parameter (CONTAINER_CONFIG und RUN_AS_PREVIEW_SERVER) nicht irgendwo ein Tippfehler oder ein zusätzliches Leerzeichen durch copy/paste eingeschlichen hat.
Wenn du die Domain bereits hinzugefügt hast in Cloud Run, dann brauchst du die Domain nicht mehr authentifizieren. Das wäre nur notwendig, wenn sie in Cloud Run nicht angezeigt wird.
lg Matthias
Ich habe es eben noch einmal probiert, leider mit dem selben Ergebnis. Hmm
Es laufen ja trotzdem Daten ein im Analytics. Funktioniert denn das Tracking serverseitig trotzdem? Bitte kontaktiert mich doch per Email, damit ich mit euch einmal zusammen darauf schauen kann. Danke vorab
Andreas
Wenn Daten einlaufen, scheint der Produktiv-Server zu funktionieren. Dann liegt es wirklich nur am Preview-Server, spannend.
Lass uns das gerne gemeinsam prüfen, ich schreib dir.
Hallo Michaela,
mal eine Frage an die Analytics-Experten hier:
Nach deinen tollen Artikel hier habe ich mich auch einmal mit SST auseinandergesetzt, aber da der Cloud Dienst von Google irgendwie rumzickt
(In Ihrem Kontingent sind noch 10 projects offen. Fordern Sie eine Erhöhung an oder löschen Sie Projekte) und ich diese Projekte auch schon gefühlt 30 mal versucht habe zu beenden habe ich mir dann den Dienst taggrs.io angeschaut und dort auch einen kostenlosen Testaccount angelegt und eingerichtet.
Mit diesen Account habe ich dann entsprechend Webcontainer / Servercontainer und Subdomain eingerichtet.
Wenn ich dann entsprechend über den Tagmanager die Vorschau für den Web- und Servercontainer aufrufe sehe ich dort auch, dass die Tags ausgelöst werden und im Servercontainer auch Daten ankommen.
Allerdings kommen im Analytics-Konto anscheinend keine Daten mehr an.
Wenn ich auf das SST verzichte, kommen dort unter der Ansicht „Echtzeit“ Daten an, wenn ich auf SST umstelle kommen dort keine Daten mehr an.
Wir betreiben einen Webshop, dort ist eigentlich immer Betrieb, sodass dort eigentlich Dtaen ankommen müssten.
Habt ihr eine Idee, woran das liegen könnte?
Viele Grüße, Michael
Hallo Michael,
hmm… Ferndiagnose ist leider immer schwierig aber ich probiere es mal. :-))
In der SGTM Preview kann man sich die ausgelösten Tags anschauen und dort auch den Request sehen, der an GA4 geschickt wird.
Werden die Tags ausgelöst?
Wie sieht der Request aus? War er erfolgreich (HTTP Status 200)?
Ganz liebe Grüße
Michaela
Hallo Michaela,
sorry für die späte Rückmeldung, ich hatte Deine Antwort nicht gesehen.
Im GA4 Client werden die Tags ausgelöst, das passt alles.
Wenn ich das SST deaktiviere habe ich in Analytics auch Daten.
Aktiviere ich das SST werden die Tags im GA4 Client ebenfalls ausgelöst.
Im GA4 Servercontainer sind im Reiter „Tags“ keine Tags zu sehen, ausser der Ads Conversion Linker.
Allerdings ist ganz links unter „Summary“ jede Menge an „collect?v=2&tid“ und darunter dann der ausgelöste Tag zu sehen, falls Du das meinst.
Unter dem Tab Request ist einmal ein Outgoing HTTP request, der den Status Code 302 bekommt, der Incoming HTTP Request bekommt den Status 200.
Unter dem Tab Event Data finde ich auch die entsprechend ausgelösten bzw. gesendeten Daten pageview / add to cart.
Dort kann ich dann auch die entsprechenden Artikel sehen.
Nach meinem Verständnis soweit erst einmal alles gut.
Die Request, die ich im TagManager im Previem Mode machen, werden auch als Requests bei Taggrs angezeigt bzw. erfasst,
die monatlich verfügbaren Requests werden weniger.
Allerdings kommen (zumindest anscheinend) keine Daten in Analytics an. Wenn ich den Bericht „Echtzeit“ aufrufe sind ohne SST immer Nutzer zu sehen, nach aktivieren von SST gehen die Nutzer unter Echtzeit auf 0 zurück.
Bin mit meinem Latein irgendwie am Ende, ich bin zwar technisch nicht völlig unbegabt, aber da hab ich irgendwie keinen Ansatz mehr.
Viele Grüße,
Michael
Hallo Michael,
dann haben wir das Problem gefunden: Du brauchst einen GA4 Tag im Server Container der deinen ankommenden Request auch an GA4 weiterleitet.
Der Outgoing-Request den du siehst ist nur von Google Ads, aber der Request zu Google Analytics fehlt dir.
Füge einen GA4 Tag hinzu und verwende als Trigger „Custom“ (bzw. „Benutzerdefiniert“) ohne weitere Einstellungen, das reicht dann schon.
Screenshots dazu siehst du hier: https://www.analyticskiste.blog/analytics/serverseitiges-tracking-mit-google/#Server_GTM_erstellen
lg Matthias
Hallo Matthias,
Asche auf mein Haupt, das habe ich tatsächlich überlesen, dass man noch einen GA4 Tag mit Trigger benötigt.
Ich werde das in den nächsten Tagen noch einmal entsprechend anpassen und dann noch einmal schauen.
Ich danke Dir auf jeden Fall schon einmal ganz herzlich und wünsche Euch ein paar schöne Ostertage!
Viele Grüße,
Michael
Hallo Matthias,
hat etwas länger gedauert, bis ich das ausprobieren konnte, aber nun hatte ich Zeit dafür.
Danke für Deinen Tipp, genau daran lag es.
Vielen Dank für Deine Hilfe!
Viele Grüße,
Michael
Hey, ich habe mir den Artikel genau durchgearbeitet. Allerdings verzweifle ich gerade ein wenig bei der Zuordnung der Subdomain. Nach dem Artikel soll diese als A/AAAA Zuordnung erfolgen, allerdings lässt Cloud Run-Domainzuordnung nur einen CNAME Eintrag zu. Hier fehlt, aus meiner Sicht, ein Schritt in der Beschreibung der Cloud Run Einrichtung.
Hallo Daniel,
wichtig ist, dass die Subdomain in der Search Console bestätigt wird und diese als Domain bei Cloud Run ausgewählt wird.
Wenn nur die Hauptdomain in der SC bestätigt ist und die Subdomain erst in Cloud Run angibt, schlägt Google einen CNAME vor. Aber auch das sollte funktionieren, weil man trotzdem die IPs statt den CNAME hinterlegen kann.
Ganz liebe Grüße
Michaela
Hallo , vielen Dank für den ausführlichen Artikel. Wenn wir den GTM Web Client aktivieren, brauchen wir also immer noch den GA4 Client korrekt?
Hallo Karter,
ja, korrekt: Der Client „GTM Web Container“ ist nur für die Auslieferung der Javascript Libraries zuständig, die fürs Tracking am Client benötigt werden (gtm.js, gtag etc.). Die eigentlichen Tracking Events empfängt der GA4 Client am Server.
Ganz liebe Grüße
Michaela
Hallo Michaela, ich habe alles auf serverseitiges Tracking umgestellt und habe nun festgestellt, dass in GA4 keinerlei Informationen mehr im Berichtsbereich „Nutzer“ ankommen – ich habe keine Detailinfos zu Browser oder auch Region der Nutzer. Der Standardwert lautet „not set“. Wie finde ich die Ursache?
Hallo Christina,
die geographische Region wird nicht erhoben, wenn du die IP-Adresse am Server rauslöscht.
Der Browser sollte allerdings immer getrackt werden, unabhängig von der IP.
Woran das liegt, müsste man im Detail überprüfen.
Es könnte ein Konfigurations-Fehler sein. Es könnte aber auch eine andere Ursache haben. Das ist auf die Schnelle leider nicht Beantwortbar.
Schreib mir gerne eine Email auf michaela@webkiste.at und ggfs. können wir uns das im Rahmen einer Buddy-Call-Stunde ansehen.
Ganz liebe Grüße
Michaela