LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Blog-Übersicht /Digital Analytics / GA4 & Server-Side GTM: Die “Migrate from...
Diesen Artikel in anderen Sprachen lesen:

GA4 & 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

GA4 & Server-Side GTM: Die "Migrate from JavaScript Managed Client ID" Funktion in GA4 erklärt
Inhalt
  1. Zwei Einstellungen auseinanderhalten
  2. Was die Migration leisten soll
  3. HttpOnly verbessert einen Teil des Schutzes
  4. Keine garantierten zwei Jahre in Safari
  5. Eine Umstellung kontrolliert prüfen
  6. Fragen und Antworten
  7. Quellen

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.

Gegenüberstellung des per JavaScript verwalteten _ga-Cookies und der serverseitig gesetzten FPID, mit der Abbildung im Server-Side GTM
JavaScript Managed und Server Managed sind Verwaltungsarten. Die zusätzliche Migrationsoption betrifft den Übergang; die ausgehende Client-ID muss geprüft werden.

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

  1. Aktuelle Containerfassung und Einstellungen sichern. Zunächst mit einer getrennten Testmessung arbeiten.
  2. Ein Testprofil mit vorhandener Client-ID und ein frisches Profil verwenden. Eingehende Client-ID, gesetzte Cookies und ausgehende GA4-Client-ID vergleichen.
  3. Weitere Seitenaufrufe, vorhandenes FPID, abgelaufene oder entfernte Kennungen sowie Ablehnung und Widerruf getrennt prüfen.
  4. Alle Ereigniswege berücksichtigen: Browserereignisse, serverseitige Käufe, gegebenenfalls Measurement Protocol und mehrere Domains. Unterschiedliche Kennungen können dieselbe Nutzerreise aufteilen.
  5. 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

  1. Die Evolution des Web-Trackings: Von Logfiles zur serverseitigen Zukunft
  2. GA4 & Server-Side GTM: Die “Migrate from JavaScript Managed Client ID” Funktion in GA4 erklärt
  3. Server-Side GTM auf GCP Cloud Run: Architektur, Auto-Scaling und Kostenoptimierung
  4. GA4 Measurement Protocol: Serverseitige CRM-Offline-Conversion-Integration
  5. Meta Conversions API: Maximierung der Event Match Quality (EMQ) und Deduplizierung
Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Eine Frage oder eine Idee für ein Webprojekt? Schreib mir kurz, worum es geht. Das Formular nutzt reCAPTCHA zum Schutz vor Spam.

Kommentar schreiben

Abweichende Zahlen aus anderen Konten und Rückfragen zur Einrichtung sind hier willkommen.

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.