English
Deutsch
PolskiGA4 & Server-Side GTM: Die “Migrate from JavaScript Managed Client ID” Funktion in GA4 erklärt
Teil 2 von 5 der Reihe Vom Pixel zum Server: Tracking, das hält
Inhalt
Der GA4-Client im serverseitigen Google Tag Manager nimmt Messanfragen entgegen und bereitet Ereignisse für Server-Tags auf. Die Wahl der Client-ID bestimmt, welche Browserkennung in den ausgehenden GA4-Daten steht. Eine Änderung dieser Kennung kann Nutzerzahlen, Sitzungszuordnung und längerfristige Auswertungen verändern.
Zwei Einstellungen auseinanderhalten
JavaScript Managed verwendet die vom Browser übermittelte Client-ID. Das übliche _ga-Cookie enthält diese Kennung zusammen mit weiteren Formatbestandteilen: GA1.1.123456789.1680000000 ist ein Cookiewert, während 123456789.1680000000 die darin enthaltene Client-ID darstellt. Eine Client-ID ist keine verlässliche Identität einer Person.
Server Managed verwendet eine serverseitig verwaltete Kennung, typischerweise im Cookie FPID. Dieses Cookie wird durch eine HTTP-Antwort gesetzt und weiterhin im Browser gespeichert. Die zusätzliche Option Migrate from JavaScript Managed Client ID betrifft den Übergang von vorhandenen Browserkennungen; das Kontrollkästchen ist nicht selbst der Schalter zwischen beiden Verwaltungsarten.
Was die Migration leisten soll
Bei einer bestehenden Messung soll die Migrationsoption einen abrupten Wechsel vorhandener Client-IDs vermeiden. Das ist keine rückwirkende Zusammenführung sämtlicher Kennungen und keine Garantie unveränderter Attribution. Bereits gelöschte oder abgelaufene Kennungen lassen sich damit nicht wiederherstellen.
Eine vereinfachte Beschreibung als „Umwandlung des alten Cookies in FPID bei dauerhaft identischer GA4-Kennung“ reicht nicht aus. Maßgeblich ist die tatsächlich weitergeleitete client_id. Vor einer Umstellung muss deshalb ein Vergleich der eingehenden und ausgehenden Kennungen in der eingesetzten Client-Version zeigen, wie bestehende Kennungen, neue Profile und bereits vorhandene FPID-Cookies behandelt werden.
HttpOnly verbessert einen Teil des Schutzes
HttpOnly verhindert das direkte Lesen des Cookies durch Seiten-JavaScript, etwa über document.cookie. Dadurch wird das einfache Auslesen bei bestimmten XSS-Angriffen erschwert. Eine Website wird dadurch nicht immun gegen XSS: Schadcode kann weiterhin Seiteninhalte verändern oder Anfragen auslösen. Ein Analyse-Identifier ist außerdem kein Anmeldecookie.
Keine garantierten zwei Jahre in Safari
Ein konfiguriertes Ablaufdatum garantiert keine tatsächliche Speicherdauer. WebKit begrenzt unter bestimmten Bedingungen auch Cookies aus HTTP-Antworten: Bei erkanntem Drittanbieter-CNAME- oder IP-Cloaking gilt eine Sieben-Tage-Grenze. Private Sitzungen, Cookie-Löschung und weitere Browsereinstellungen können die Verfügbarkeit zusätzlich begrenzen. FPID ist deshalb kein allgemeiner ITP-Bypass.
Die First-Party-Konfiguration des Endpunkts, Cookie-Domain, Pfad, HTTPS und tatsächliche Browserantworten gehören zur Prüfung. Die Einwilligungsvorgaben gelten weiterhin für Speicherung und Nutzung der Kennung.
Eine Umstellung kontrolliert prüfen
- Aktuelle Containerfassung und Einstellungen sichern. Zunächst mit einer getrennten Testmessung arbeiten.
- Ein Testprofil mit vorhandener Client-ID und ein frisches Profil verwenden. Eingehende Client-ID, gesetzte Cookies und ausgehende GA4-Client-ID vergleichen.
- Weitere Seitenaufrufe, vorhandenes FPID, abgelaufene oder entfernte Kennungen sowie Ablehnung und Widerruf getrennt prüfen.
- Alle Ereigniswege berücksichtigen: Browserereignisse, serverseitige Käufe, gegebenenfalls Measurement Protocol und mehrere Domains. Unterschiedliche Kennungen können dieselbe Nutzerreise aufteilen.
- Nach kontrollierter Veröffentlichung Nutzerzahlen, Sitzungen und Kampagnenzuordnung nach Browser beobachten. Änderungen mit dem tatsächlichen Rolloutzeitpunkt vergleichen.
Ein Kennungswechsel kann die Verbindung zur Vergangenheit beeinträchtigen. Daraus folgt jedoch weder, dass ausnahmslos alle Besuche neue Nutzer erzeugen, noch dass jede Konversion automatisch „Direct / None“ wird. Weitere Identitätssignale, Kampagnenparameter und die Berichtskonfiguration beeinflussen das Ergebnis.
Fragen und Antworten
Ist die Migrationsoption immer erforderlich?
Bei fortgeführter JavaScript-Verwaltung ist keine FPID-Migration nötig. Bei einer bestehenden Messung mit geplantem Wechsel auf Server Managed verdient die Übergangsoption eine gezielte Prüfung. Für eine neue Messung ohne vorhandene Kennungen fehlt dieser Altbestand.
Bleibt die Kennung nach dem Löschen aller Cookies erhalten?
Das gelöschte FPID-Cookie steht dem Server nicht mehr zur Verfügung. Eine Wiedererkennung über andere zulässige Signale ist eine getrennte Frage; FPID allein stellt die gelöschte Kennung nicht wieder her.
Ist der interne Migrationsalgorithmus damit vollständig belegt?
Nein. Die öffentlichen Google-Grundlagen erklären serverseitige Cookies und Datenverarbeitung, dokumentieren aber nicht jeden internen Übergangsfall. Deshalb gehört ein Test der konkret eingesetzten GA4-Client-Version zur Umstellung.
Vom Pixel zum Server: Tracking, das hält
- Die Evolution des Web-Trackings: Von Logfiles zur serverseitigen Zukunft
- GA4 & Server-Side GTM: Die “Migrate from JavaScript Managed Client ID” Funktion in GA4 erklärt
- Server-Side GTM auf GCP Cloud Run: Architektur, Auto-Scaling und Kostenoptimierung
- GA4 Measurement Protocol: Serverseitige CRM-Offline-Conversion-Integration
- Meta Conversions API: Maximierung der Event Match Quality (EMQ) und Deduplizierung
Passend dazu
