gtag(‘set’) in der Praxis: eine User ID an ein bereits geladenes Google Tag übergeben

Eine User ID kann erst nach erfolgreicher Anmeldung verfügbar werden. Die Google-Analytics-Anleitung empfiehlt ausdrücklich gtag('set', {user_id: ...}), um die Kennung nach der Initialisierung zu setzen oder zu aktualisieren. Ein erneutes Laden der Bibliothek ist unnötig. Dieser Artikel beschreibt ein bereits installiertes eigenständiges Google Tag; ein GTM-Container benötigt die passende unterstützte Containerkonfiguration.

Geltungsbereich und Parameterunterstützung unterscheiden

Der allgemeine Parametervorrang lautet event > config > set. Eine Zuweisung löscht keine Zuweisung in einem anderen Bereich. Daraus folgt jedoch nicht, dass jeder Parameter in jedem Bereich zulässig ist: Google definiert user_id als reservierten Konfigurationsparameter und untersagt ausdrücklich die Übergabe als Ereignisparameter oder benutzerdefinierte Nutzereigenschaft. Auch eine Registrierung als benutzerdefinierte Dimension ist ausgeschlossen.

Eine konsistente Implementierung vermeidet konkurrierende Identitätszuweisungen. Eine fest im initialen config hinterlegte Kennung verschwindet nicht verlässlich durch die bloße Änderung eines globalen Werts. Tests für Kontowechsel und Abmeldung müssen tatsächliche ausgehende Anfragen prüfen. Bleibt eine höher priorisierte Zuweisung bestehen, braucht der Konfigurationsweg eine Korrektur. Die Übergabe von user_id an jedem Ereignis ist keine Lösung.

Fünf Befehle mit unterschiedlichen Aufgaben

• config initialisiert beziehungsweise konfiguriert ein Google Tag. Ein Tag kann mehrere zugehörige IDs und Ziele haben; ein weiterer Aufruf erzeugt nicht zwangsläufig ein zusätzliches Ziel. Die Konfigurationsanleitung empfiehlt einen Aufruf je Google Tag.
• set ändert unterstützte globale Parameter für folgende Ereignisse im aktuellen Dokument.
• event sendet ein benanntes Ereignis mit unterstützten Ereignisparametern und optionaler Zielsteuerung über send_to.
• get fragt ein unterstütztes Feld asynchron ab. Die Verfügbarkeit hängt vom Ziel ab; gclid ist kein universelles GA4-Feld.
• consent liefert voreingestellte oder aktualisierte Einwilligungssignale. Eine Parameteränderung erzeugt keine Einwilligung.

Sitzungswiederherstellung von echter Anmeldung trennen

Das Beispiel setzt ein bereits initialisiertes eigenständiges Tag, bestehende Einwilligungssteuerung und einen authentifizierten Kontozustand der Anwendung voraus. Ein Ladeskript oder config-Aufruf kommt nicht hinzu. Die angemeldete Anwendung muss eine eigens für diesen Analysezweck vergebene Kennung liefern. Aus deren Zeichen dürfen persönliche Angaben wie Name oder E-Mail-Adresse nicht direkt hervorgehen. E-Mail-Adresse, Telefonnummer, Sitzungscookie oder Bearer-Token sind dafür ungeeignet.

function syncAnalyticsIdentity(analyticsId, permitted) {
  const valid = typeof analyticsId === 'string' &&
    /^[A-Za-z0-9_-]{16,128}$/.test(analyticsId);
  const nextId = permitted === true && valid ? analyticsId : null;
  gtag('set', { user_id: nextId });
  return nextId !== null;
}

function recordConfirmedLogin(analyticsId, method, permitted) {
  const attached = syncAnalyticsIdentity(analyticsId, permitted);
  if (!attached || !['password', 'sso', 'passkey'].includes(method)) return;
  gtag('event', 'login', {
    send_to: 'G-XXXXXXXXXX',
    method: method
  });
}

Die erlaubte Länge von 16–128 Zeichen und die Zeichenwahl sind Regeln dieses Beispiels, nicht Googles vollständige Kennungsspezifikation; Google erlaubt bis zu 256 Zeichen. Eine passende Zeichenfolge beweist weder Berechtigung noch Anonymität. permitted muss aus der aktuellen freigegebenen Identitätsmessung der Anwendung stammen, nicht direkt aus einer ungeprüften Anfrage.

Die Wiederherstellung einer Sitzung ruft nur syncAnalyticsIdentity auf. Ein bestätigter aktueller Anmeldeübergang kann einmalig recordConfirmedLogin mit der tatsächlichen Methode aufrufen. Die Anwendung muss veraltete Authentifizierungsantworten verwerfen und doppelte Übergangsmeldungen verhindern. Die Platzhalter-Mess-ID ist zu ersetzen. Die Methodennamen bilden eine ausdrückliche Werteliste der Beispielanwendung.

Abmeldung, Kontowechsel und Widerruf erfordern sofortige Synchronisierung. syncAnalyticsIdentity(null, false) leert diese globale Zuweisung, widerruft aber keine Einwilligung, entfernt keine konkurrierenden Konfigurationswerte und löscht keine bereits erhobenen Daten. Die Einwilligungs- und Messsteuerung muss unzulässige Erhebung gesondert stoppen. Ein erster Besuch ohne Kennung benötigt keine erfundene ID.

Browseranfragen und Analytics-Berichte

Ein globales Update gilt im aktuellen Dokument. Eine vollständige Navigation benötigt den aktuellen Identitätszustand erneut; eine SPA bei Kontozustandsänderungen. Bereits übertragene Anfragen werden nicht umgeschrieben. Googles Berichtsbeispiel ordnet frühere Ereignisse ohne Kennung innerhalb derselben Sitzung einer späteren User ID zu und beendet die Zuordnung nachfolgender Ereignisse nach der Abmeldung. Daraus folgt keine Zusage rückwirkend geänderter Rohdatenexporte oder historischer Daten vor der Implementierung.

Blended oder Observed berücksichtigen User-ID als Berichtsidentität; Device-based verwendet Geräteidentität für Berichte. Ein Wechsel dieser Berichtseinstellung repariert keine falsch erhobene Kennung.

GTM und die Oktoberänderungen 2026

Die Versionshinweise vom 8. Oktober beschreiben Containerinitialisierung beim Laden und sichtbare gtag.config-Verarbeitungsereignisse. Solche Ereignisse können breite Custom-Event-Trigger treffen, belegen aber keinen versendeten GA4-Seitenaufruf. Die am 12. Oktober eingeführte optionale Optimierung sendet Google-Messungen direkt aus GTM ohne zusätzliche Google-Tag-Bibliothek. Die Konfiguration bleibt vom Installationsweg abhängig.

GTM-Einstellungen und aktuelle Variablen gehören in die unterstützte Containerkonfiguration. Ein zweites eigenständiges Ladeskript allein für Identitätsupdates riskiert eine doppelte Installation. Globaler Kontext kann mehrere Google Tags erreichen; Googles Anleitung beschränkt diese Möglichkeit auf nicht sensible Daten.

Für eigene Templates garantiert gtagSet innerhalb des aktuellen Containers eine bestimmte Reihenfolge: Verarbeitung nach dem laufenden Ereignis und dessen Tags beziehungsweise deren Zeitlimit, aber vor bereits wartenden Data-Layer-Einträgen. Die API benötigt Schreibrechte für die angegebenen Schlüssel. Das bedeutet weder sofortige Änderung bereits laufender Tags noch allgemeine Unterstützung jedes Identitätsfalls. Zielregeln, Einwilligung und Identitätsbereich gelten weiterhin. Einwilligungs-Templates verwenden setDefaultConsentState und updateConsentState.

Einwilligung und SPA-Seitenaufrufe

Einwilligungsvoreinstellungen gehören bei eigenständigem gtag.js vor Messbefehle. Ein späteres Update muss die tatsächliche Auswahl für jeden Einwilligungstyp abbilden; eine Anmeldung erlaubt keine pauschale Werbeeinwilligung. wait_for_update: 500 ist eine begrenzte Verzögerung für asynchrone Einwilligungssteuerung, keine Wartegarantie bis zur Zustimmung. Basic Mode blockiert Google Tags bis zur Einwilligung; Advanced Mode kann davor eingeschränkte Pings ohne Cookies senden. Die CMP muss die Entscheidung speichern und wiederherstellen.

Ein bewusst gesteuerter SPA-Messweg sendet einen page_view je beabsichtigtem Routenwechsel mit aktuellen Seitenparametern und schließt konkurrierende automatische Verlaufsmessung aus. Auch andere Ereignisse benötigen passenden Seitenkontext. Wiederholtes config mit update: true ist kein allgemein dokumentierter Ersatz.