{"id":10135,"date":"2026-09-13T12:37:00","date_gmt":"2026-09-13T10:37:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10135"},"modified":"2026-09-09T13:23:41","modified_gmt":"2026-09-09T11:23:41","slug":"tutorial-e-commerce-analytics-von-client-side-auf-server-side-gtm-migrieren","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/tutorials-de\/tutorial-e-commerce-analytics-von-client-side-auf-server-side-gtm-migrieren\/","title":{"rendered":"Tutorial: E-Commerce-Analytics von Client-Side auf Server-Side GTM migrieren"},"content":{"rendered":"

Jeder Shop mit clientseitigem Tracking meldet weniger K\u00e4ufe, als er abwickelt. Diese L\u00fccke ist kein aufzusp\u00fcrender Fehler: Anfragen an bekannte Analytics-Hostnamen stehen auf Filterlisten, der Tracking-Schutz verk\u00fcrzt die Lebensdauer des identifizierenden Cookies, und wer den Tab schlie\u00dft, bevor die Best\u00e4tigungsseite fertig gerendert ist, sendet das Event gar nicht erst. Ein serverseitiger Container \u00e4ndert, wohin die Daten laufen, und deckt damit einen Teil davon ab \u2013 das Kauf-Event aus dem Browser zu holen deckt den Rest ab.<\/p>\n

Die folgende Anleitung behandelt das als Migration und nicht als Neubau: Das bestehende clientseitige Setup bleibt durchgehend aktiv, beide laufen lange genug parallel, um verglichen zu werden, und umgeschaltet wird erst, wenn die Zahlen es rechtfertigen.<\/p>\n

\n\"Drei
Der Umzug des Containers macht die Daten steuerbar; der Umzug des Kaufs weg vom Browser macht sie vollständig.<\/figcaption><\/figure>\n

Schritt 1: Beides laufen lassen, sp\u00e4ter umschalten<\/h2>\n

Die sicherste Reihenfolge sendet Daten an den Server-Container, w\u00e4hrend das clientseitige Setup weiter in dieselbe oder eine parallele Property meldet. Nichts wird gel\u00f6scht, keine Tags werden pausiert, und der Vergleich l\u00e4uft auf echtem Traffic statt im Vorschaumodus.<\/p>\n

Eine zweite GA4-Property als Migrationsziel h\u00e4lt die Produktionszahlen w\u00e4hrend der \u00dcberlappung sauber \u2013 ein doppelter Datenbestand in der Live-Property ist hinterher schwerer zu entwirren, als eine tempor\u00e4re zweite Property wegzuwerfen ist. Zwei bis vier Wochen \u00dcberlappung decken Wochentags- und Wochenendmuster sowie mindestens einen vollst\u00e4ndigen Kaufzyklus ab.<\/p>\n

Schritt 2: Den Tagging-Server bereitstellen<\/h2>\n

In der GTM-Oberfl\u00e4che entsteht ein Server-Container als eigener Containertyp, und seine Einstellungen bieten die automatische Bereitstellung in Google Cloud Run an. Der automatische Weg ist bequem und erzeugt ein funktionierendes Deployment; eine manuelle Bereitstellung desselben \u00f6ffentlichen Images gibt mehr Kontrolle \u00fcber Region und Skalierung:<\/p>\n

gcloud run deploy sgtm \\\n  --image=gcr.io\/cloud-tagging-10302018\/gtm-cloud-image:stable \\\n  --region=europe-central2 \\\n  --platform=managed \\\n  --allow-unauthenticated \\\n  --set-env-vars=CONTAINER_CONFIG='<Config-String aus den Containereinstellungen>'<\/code><\/pre>\n
Die voreingestellten Werte sind auf Tests und nicht auf Produktionsvolumen ausgelegt; die Instanz- und Speicher-Flags sind der Teil, den es bei echtem Volumen erneut anzusehen lohnt. Jede Container-Laufzeitumgebung funktioniert gleicherma\u00dfen \u2013 Cloud Run ist der dokumentierte Standard, keine Voraussetzung.<\/p>\n
Nicht optional ist der Hostname. Ein Tagging-Server, der nur unter seiner generierten Cloud-Adresse erreichbar ist, ist ein Drittanbieter-Host wie jeder andere; der Vorteil des First-Party-Kontexts entsteht erst, wenn er auf einer Subdomain der eigenen Shop-Domain antwortet, etwa sgtm.shop.example.com<\/code>, mit passendem DNS-Eintrag und zugeordnetem Zertifikat.<\/p>\n
Schritt 3: Der GA4-Client<\/h2>\n
Ein Server-Container tut nichts, solange kein Client die eingehenden Anfragen annimmt. Der eingebaute GA4-Client lauscht auf den Pfaden, die ein Google-Tag verwendet, zerlegt den eingehenden Hit und macht daraus ein Event, das serverseitige Tags lesen k\u00f6nnen \u2013 ohne ihn nimmt der Container Anfragen entgegen und verwirft sie.<\/p>\n
Zwei Einstellungen verdienen eine Entscheidung statt einer Voreinstellung. Der Client kann die Ausgabe des identifizierenden Cookies \u00fcbernehmen, statt sie JavaScript zu \u00fcberlassen \u2013 das ist es, was das Cookie gegen\u00fcber Browser-Beschr\u00e4nkungen dauerhaft macht. Ihn ohne die zugeh\u00f6rige Migrationsoption einzuschalten setzt die Identit\u00e4t jedes wiederkehrenden Besuchers zur\u00fcck; das geh\u00f6rt daher in eine eigene \u00c4nderung mit eigener Pr\u00fcfung. Die zweite betrifft die Pfade: Die Standardpfade unver\u00e4ndert zu lassen ist das, was dem Web-Container erlaubt, Hits ohne eigene Endpunkt-Konfiguration zu senden.<\/p>\n
Schritt 4: Den Web-Container auf den Server richten<\/h2>\n
Auf Browserseite leitet ein einziges Feld den Verkehr um. In einem Google-Tag im Web-Container wird die Server-Container-URL als Konfigurationsparameter gesetzt; in einer reinen gtag.js-Implementierung ist das Gegenst\u00fcck transport_url<\/code>:<\/p>\n
\/\/ Konfigurationsparameter im Google-Tag (Web-Container)\nserver_container_url: 'https:\/\/sgtm.shop.example.com'\n\n\/\/ Entsprechung in einer reinen gtag.js-Implementierung\ngtag('config', 'G-XXXXXXXXXX', {\n  server_container_url: 'https:\/\/sgtm.shop.example.com'\n});<\/code><\/pre>\n
Ab diesem Punkt adressiert der Browser die eigene Subdomain des Shops, und der Server-Container leitet an GA4 weiter. Der Server-Container hat einen eigenen Vorschaumodus, der die eingehende Anfrage zeigt, den Client, der sie angenommen hat, und jedes daraus ausgel\u00f6ste Tag \u2013 die Stelle, an der ein falsch geleiteter Hit sofort sichtbar wird statt einen Tag sp\u00e4ter im Bericht.<\/p>\n
Schritt 5: Den Kauf aus dem Browser holen<\/h2>\n
Die Leitung \u00fcber eine eigene Subdomain verringert das Blockieren; sie beendet es nicht, und gegen den Besucher, der die Best\u00e4tigungsseite nie erreicht, hilft sie gar nicht. Erst ein Event, das das Backend nach der Bestellbest\u00e4tigung im Shopsystem sendet, ist vollst\u00e4ndig unabh\u00e4ngig vom Browser.<\/p>\n
Diese Anfrage braucht die Kennungen, die im Browser liegen. Die Client-ID aus dem Analytics-Cookie muss im Checkout ausgelesen und zusammen mit der Sitzungs-ID am Auftrag gespeichert werden, sonst kommt der Kauf ohne zugeh\u00f6rige Sitzung an und landet im Bericht als Traffic ohne Quelle:<\/p>\n
POST https:\/\/sgtm.shop.example.com\/g\/collect\n\nv=2\n&tid=G-XXXXXXXXXX\n&cid=1234567890.1690000000     \/\/ im Checkout aus dem Analytics-Cookie gelesen\n&sid=1789000000                \/\/ die Sitzungs-ID desselben Besuchs\n&en=purchase\n&ep.transaction_id=ORD-10432\n&epn.value=149.00\n&ep.currency=PLN<\/code><\/pre>\n
Wird derselbe Kauf sowohl aus dem Browser als auch aus dem Backend gesendet, muss die Transaktionskennung \u00fcbereinstimmen, damit sich das Duplikat nachgelagert erkennen und entfernen l\u00e4sst \u2013 die Alternative ist ein Shop, dessen Umsatzzahlen genau um die Events aufgebl\u00e4ht sind, die die Migration zur\u00fcckholen sollte.<\/p>\n
Schritt 6: Vergleichen, bevor etwas abgeschaltet wird<\/h2>\n
Der Vergleich, der \u00fcber die Umschaltung entscheidet, lautet nicht clientseitig gegen serverseitig, sondern beide jeweils gegen die Bestellanzahl des Shops. Ein serverseitiges Setup, das mehr K\u00e4ufe meldet als zuvor, ist nur dann eine Verbesserung, wenn die zus\u00e4tzlichen K\u00e4ufe echten Bestellungen entsprechen \u2013 und die Bestelltabelle ist die Referenz, die das kl\u00e4rt.<\/p>\n
Typische Befunde w\u00e4hrend der \u00dcberlappung: Die Kaufzahlen steigen um eine Spanne, die stark von Publikum und Ger\u00e4temix abh\u00e4ngt, Sitzungen gewinnen an Dauer, weil das identifizierende Cookie l\u00e4nger \u00fcberlebt, und einige Tags erweisen sich als abh\u00e4ngig von Browser-Variablen, die der Server-Container nicht hat. Diese Tags sind die eigentliche Migrationsarbeit; der Container selbst ist der leichte Teil.<\/p>\n
Innerhalb der Leitplanken bleiben<\/h2>\n
Ein serverseitiger Container verlagert die Verarbeitung, nicht die Pflicht. Der Consent-Status muss mit der Anfrage reisen und ausgewertet werden, bevor irgendein Tag ausl\u00f6st, und er muss am Auftrag gespeichert sein, damit auch das Backend-Event ihn pr\u00fcfen kann \u2013 eine vom Server gesendete Anfrage ist nicht befreit, weil der Browser nicht mehr beteiligt ist. Der Container wird au\u00dferdem zu einem System mit laufenden Kosten und einer Verf\u00fcgbarkeit, von der das Reporting nun abh\u00e4ngt, und das von ihm ausgegebene identifizierende Cookie bleibt personenbezogenes Datum nach denselben Regeln wie zuvor, nur von anderer Stelle gesetzt.<\/p>\n
\n
Quellen<\/h2>\n