GA4 & Server-Side GTM: Die “Migrate from JavaScript Managed Client ID” Funktion in GA4 erklärt
Bei der Umstellung des Google Analytics 4 (GA4) Trackings auf den Server-Side Google Tag Manager (ssGTM) eröffnet sich ein neues Maß an Datenkontrolle, Datenschutz und Cookie-Langlebigkeit. Eine der mächtigsten – und am häufigsten missverstandenen – Funktionen in der GA4-Client-Konfiguration ist die Einstellung “Migrate from JavaScript Managed Client ID” (Von JavaScript-verwalteter Client-ID migrieren).
Um zu verstehen, warum dieses unscheinbare Häkchen so wichtig ist, muss zunächst begriffen werden, wie GA4 Nutzer identifiziert und was der grundlegende Wechsel von clientseitigen zu serverseitigen Cookies bedeutet.
Der Cookie-Kampf: _ga vs. FPID
In der Vergangenheit basierte die Standard-Webanalyse auf JavaScript. Wenn ein Nutzer eine Website besucht, erstellt das GA4-Skript ein Cookie namens _ga. Dieses Cookie enthält die Client-ID (z. B. GA1.1.123456789.1680000000), die den Browser identifiziert. Da dieses Cookie von JavaScript im Browser generiert wird, ist es extrem anfällig für Mechanismen wie Intelligent Tracking Prevention (ITP) in Safari und Firefox. Diese begrenzen die Lebensdauer des Cookies künstlich (manchmal auf nur 7 Tage oder gar 24 Stunden).
Server-Side GTM bietet eine Lösung: Server Managed Client IDs (Serverseitig verwaltete Client-IDs). Anstatt dem Browser die Generierung des _ga-Cookies zu überlassen, erzeugt der ssGTM-Server ein sicheres HTTP-only Cookie namens FPID (First Party Identifier).
- Sicherheit: Auf HTTP-only-Cookies kann nicht von clientseitigem JavaScript zugegriffen werden, was sie immun gegen Cross-Site-Scripting-Angriffe (XSS) macht.
- Langlebigkeit: Da sie direkt durch die HTTP-Antwort des Servers gesetzt werden, behandeln Browser wie Safari sie als echte First-Party-Daten. ITP-Beschränkungen werden umgangen und die Identität des Nutzers bleibt deutlich länger erhalten (bis zu 2 Jahre).
Was genau bewirkt “Migrate from JavaScript Managed Client ID”?
Bei der Entscheidung, vom Standard-_ga-Cookie auf das HTTP-only-FPID-Cookie in den GA4-Client-Einstellungen zu wechseln, entsteht ein Übergangsproblem.
Wird die Option “Migrate from JavaScript Managed Client ID” aktiviert, führt der ssGTM-Server einen intelligenten Handshake durch. Besucht ein wiederkehrender Nutzer die Website, prüft der Server, ob bereits ein altes _ga-Cookie vorhanden ist. Ist dies der Fall, wird die bestehende Client-ID aus dem _ga-Cookie ausgelesen, in das neue FPID-Format übersetzt und als neues HTTP-only-FPID-Cookie gesetzt.
Von diesem Moment an erkennt GA4 den Nutzer über die FPID, aber die zugrundeliegende Identität bleibt dieselbe wie unter dem alten _ga-Cookie.
Die “Reset”-Apokalypse: Was passiert, wenn nicht migriert wird?
Erfolgt der Umstieg auf das FPID-Cookie (Server Managed), ohne die Migrationsoption zu aktivieren, wird eine Analyse-Katastrophe ausgelöst.
Ohne Migration ignoriert der Server alle existierenden _ga-Cookies. Wenn ein treuer, wiederkehrender Kunde die Website besucht, registriert der Server das Fehlen eines FPID-Cookies und ignoriert das alte _ga-Cookie. In der Folge wird sofort eine brandneue FPID generiert.
Die Konsequenzen in den GA4-Berichten:
- Massiver Anstieg “Neuer Nutzer”: Jeder einzelne wiederkehrende Nutzer wird als “Neuer Nutzer” klassifiziert.
- Zerstörte Attribution: Wurde gestern auf eine Google Ads-Kampagne geklickt (verfolgt über
_ga) und heute gekauft (verfolgt über die neu erzwungeneFPID), kann GA4 die beiden Sitzungen nicht miteinander verbinden. Die Conversion wird als “Direct / None” ausgewiesen, und Werbekampagnen verlieren den zugeschriebenen ROI. - Fragmentierte User Journeys: Die historischen Daten der Nutzer werden komplett von deren zukünftigen Aktionen abgeschnitten.
Wann sollte diese Option aktiviert werden und wann nicht?
Wann eine AKTIVIERUNG sinnvoll ist (Enable):
- Fast immer. Wenn eine Website bereits live ist und ein bestehendes GA4-Setup auf Server-Side GTM umgestellt wird, um das
FPID-Cookie zu nutzen. Eine Migration ist zwingend erforderlich, um die Nutzerkontinuität, die Attribution und die Zielgruppen (Audiences) zu erhalten.
Wann eine DEAKTIVIERUNG sinnvoll ist (Disable):
- Brandneue Websites: Wenn eine Website von Grund auf neu gestartet wird und noch keinerlei historischer Traffic existiert, gibt es keine
_ga-Cookies, die migriert werden könnten. - Strenge Compliance-Vorgaben: In extrem seltenen Ausnahmefällen könnte eine Rechtsabteilung vorschreiben, dass der Wechsel zu einer neuen Tracking-Infrastruktur das “Vergessen” alter Identifikatoren erfordert, um einen harten Reset der Nutzerprofilierung zu erzwingen.
- Wenn FPID NICHT genutzt wird: Ist der GA4-Client in ssGTM so konfiguriert, dass weiterhin die JavaScript-verwaltete Client-ID genutzt wird (das
_ga-Cookie wird einfach durch den Server durchgeleitet) und die server-verwaltete FPID-Funktion überhaupt nicht zum Einsatz kommt, ist diese Einstellung irrelevant.
