{"id":9749,"date":"2026-08-16T15:00:54","date_gmt":"2026-08-16T13:00:54","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9749"},"modified":"2026-08-13T14:30:56","modified_gmt":"2026-08-13T12:30:56","slug":"gtagset-in-der-praxis-eine-user-id-an-ein-bereits-geladenes-google-tag-ubergeben","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/gtagset-in-der-praxis-eine-user-id-an-ein-bereits-geladenes-google-tag-ubergeben\/","title":{"rendered":"gtag(‘set’) in der Praxis: eine User ID an ein bereits geladenes Google Tag \u00fcbergeben"},"content":{"rendered":"

Eine Webanwendung mit Anmeldung erf\u00e4hrt in der Regel einen Moment zu sp\u00e4t, wer die besuchende Person ist. Die Seite l\u00e4dt, das Google Tag initialisiert sich, der config<\/code>-Befehl sendet seinen page_view<\/code> \u2014 und erst danach liefert das Login-Formular eine Session zur\u00fcck oder die Single-Page-Application ermittelt das Konto \u00fcber einen API-Aufruf. Wenn die User ID existiert, hat der erste Hit den Browser bereits verlassen.<\/p>\n

Der Reflex in dieser Lage besteht darin, das Tag ein zweites Mal zu konfigurieren, diesmal mit angeh\u00e4ngter Kennung. Dieser Reflex ist teuer und unn\u00f6tig. Ein bereits geladenes Google Tag muss nicht neu geladen oder neu initialisiert werden, nur weil ein Wert versp\u00e4tet eintrifft: Ein einzelner set<\/code>-Befehl \u00fcbergibt den Wert, und jedes danach auf dieser Seite gesendete Event tr\u00e4gt ihn.<\/p>\n

\n\"Zwei
Derselbe Zeitpunkt, zwei Wege: Ein erneutes Ausl\u00f6sen des Google Tags initialisiert ihn noch einmal und schreibt einen zweiten page_view in die Sitzung, w\u00e4hrend ein einziger set-Befehl die User ID an den laufenden Tag \u00fcbergibt und jedes folgende Ereignis sie tr\u00e4gt.<\/figcaption><\/figure>\n

Die f\u00fcnf gtag-Befehle und wie ihre Geltungsbereiche zusammenwirken<\/h2>\n

Die gtag.js-API kennt genau f\u00fcnf Befehle, und ihre Arbeitsteilung ist es, die die sp\u00e4te \u00dcbergabe m\u00f6glich macht.<\/p>\n\n\n\n\n\n\n\n\n\n
Befehl<\/th>\nSignatur<\/th>\nZweck<\/th>\nReichweite<\/th>\n<\/tr>\n<\/thead>\n
config<\/code><\/td>\ngtag('config', '<TARGET_ID>', {\u2026})<\/code><\/td>\nErg\u00e4nzt Konfigurationsinformationen f\u00fcr ein Ziel; die TARGET_ID entscheidet, wohin gtag.js Ereignisdaten sendet, ein weiterer Aufruf erg\u00e4nzt ein weiteres Ziel.<\/td>\nAlle Events an diese eine TARGET_ID.<\/td>\n<\/tr>\n
set<\/code><\/td>\ngtag('set', {\u2026})<\/code><\/td>\nDefiniert Parameter, die jedem nachfolgenden Event auf der Seite zugeordnet werden. Es existiert auch eine benannte Gruppenform, etwa gtag('set', 'campaign', {\u2026})<\/code>.<\/td>\nGlobal, ab dem Aufruf, nur f\u00fcr die aktuelle Seite.<\/td>\n<\/tr>\n
event<\/code><\/td>\ngtag('event', '<event_name>', {\u2026})<\/code><\/td>\nSendet Ereignisdaten, entweder ein empfohlenes Event oder ein eigenes.<\/td>\nDieses eine Event.<\/td>\n<\/tr>\n
get<\/code><\/td>\ngtag('get', '<target>', '<field>', callback)<\/code><\/td>\nLiest Werte aus gtag.js zur\u00fcck, darunter mit set<\/code> zugewiesene Werte: client_id<\/code>, session_id<\/code>, session_number<\/code>, gclid<\/code>.<\/td>\nLesezugriff; der Callback erh\u00e4lt das Feld oder undefined<\/code>.<\/td>\n<\/tr>\n
consent<\/code><\/td>\ngtag('consent', 'default'|'update', {\u2026})<\/code><\/td>\nSetzt den initialen Consent-Zustand oder aktualisiert ihn, sobald eine Entscheidung vorliegt.<\/td>\nConsent-Signale f\u00fcr die Seite.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Es existieren damit drei Geltungsbereiche: einzelne Events, alle Events an eine bestimmte TARGET_ID und global alle Events. Wird derselbe Parameter in mehreren davon zugewiesen, kommt bei der Verarbeitung eines Events nur ein einziger Wert zum Tragen, und die Reihenfolge lautet Event vor config vor set<\/strong>. Das entscheidende Detail steht eine Zeile weiter unten in der Referenz: Vorrang ist kein \u00dcberschreiben.<\/p>\n

\n

Parameter values set in one scope don’t modify the values set for the same parameter in a different scope.<\/p>\n<\/blockquote>\n

Im dokumentierten Beispiel wird campaign_id<\/code> global als '1234'<\/code> und anschlie\u00dfend in einem config<\/code>-Aufruf als 'ABCD'<\/code> zugewiesen; danach lautet der globale Wert weiterhin '1234'<\/code>. Die Geltungsbereiche halten ihre Werte nebeneinander, und die Rangfolge entscheidet erst zum Verarbeitungszeitpunkt, welcher gilt. Aus der Kombination beider Regeln folgt eine Konsequenz, die die Dokumentation nicht ausformuliert: Ein nach config<\/code> abgesetzter set<\/code>-Aufruf verdr\u00e4ngt keinen Wert, den config<\/code> f\u00fcr dieses Ziel bereits belegt, und wirkt f\u00fcr die Parameter, die config<\/code> unber\u00fchrt gelassen hat.<\/p>\n

Zur Wiederholung \u00e4u\u00dfert sich die Dokumentation eindeutig: config<\/code> ist einmal pro Google Tag aufzurufen, jeder weitere Aufruf sollte set<\/code> verwenden. Die Dokumentation empfiehlt au\u00dferdem, wo m\u00f6glich config<\/code> oder event<\/code> gegen\u00fcber set<\/code> vorzuziehen, was insbesondere eigene Event-Parameter betrifft, weil set<\/code> sie m\u00f6glicherweise nicht zuverl\u00e4ssig an alle Google-Analytics-Datenstr\u00f6me weitergibt. F\u00fcr dokumentierte globale Parameter wie user_id<\/code>, page_title<\/code> oder currency<\/code> ist set<\/code> das vorgesehene Instrument.<\/p>\n

Der Fall im Detail: die User ID versp\u00e4tet \u00fcbergeben<\/h2>\n

User IDs sind selbst vergebene Kennungen f\u00fcr einzelne Nutzer; sie konsistent zu vergeben, ist Sache des Betreibers, \u00fcblicherweise beim Login. Ist die Kennung schon zum Rendering-Zeitpunkt bekannt, kann sie im config<\/code>-Aufruf mitreisen. Wird sie erst nach dem Laden der Seite bekannt, ist gtag('set')<\/code> der dokumentierte Weg. Das Snippet auf der Seite bleibt genau so, wie es installiert wurde.<\/p>\n

<script async src=\"https:\/\/www.googletagmanager.com\/gtag\/js?id=G-XXXXXXXXXX\"><\/script>\n<script>\n  window.dataLayer = window.dataLayer || [];\n  function gtag(){dataLayer.push(arguments);}\n  gtag('js', new Date());\n  gtag('config', 'G-XXXXXXXXXX');\n<\/script><\/code><\/pre>\n
Sobald die Login-Antwort eintrifft, gen\u00fcgt ein Befehl. Kein zweites config<\/code>, kein zweites Snippet, kein Reload.<\/p>\n
fetch('\/api\/session')\n  .then(function (response) { return response.json(); })\n  .then(function (session) {\n    if (session.analyticsId) {\n      gtag('set', { 'user_id': session.analyticsId });\n    }\n    gtag('event', 'login', { 'method': 'password' });\n  });<\/code><\/pre>\n
Was danach geschieht, teilt sich zwischen Browser und Verarbeitungsseite auf. Im Browser setzt die Wirkung im Moment des Aufrufs ein und reicht bis zum Ende der Seite. Jedes nach dem set<\/code>-Befehl abgesetzte Event tr\u00e4gt user_id<\/code>, jedes davor abgesetzte nicht. Die Formulierung in der Referenz \u2014 Parameter, die jedem nachfolgenden Event auf der Seite zugeordnet werden \u2014 begrenzt die Wirkung zeitlich nach vorn und auf das aktuelle Dokument. Eine klassische Multi-Page-Website setzt den Befehl deshalb bei jedem Seitenaufruf erneut ab, eine Single-Page-Application einmal f\u00fcr die Lebensdauer des Dokuments.<\/p>\n
Auf der Verarbeitungsseite gehen die fr\u00fcheren Events nicht verloren. Analytics ordnet Events, die vor dem Setzen der User ID ausgel\u00f6st wurden, dieser User ID zu. Das dokumentierte Beispiel f\u00fchrt durch eine Sitzung, die abgemeldet beginnt: Event 1 und Event 2 tragen keine Kennung, der Nutzer meldet sich an, Event 3 folgt \u2014 und anschlie\u00dfend sind Event 1, 2 und 3 s\u00e4mtlich der ID dieses Nutzers zugeordnet. Zwei Grenzen gelten. Die Zuordnung wird innerhalb einer Sitzung beschrieben, und sie reicht nicht in Daten zur\u00fcck, die vor dem Bestehen der Implementierung erhoben wurden; solche Daten werden nicht erneut verarbeitet. Ob sie fr\u00fchere, bereits abgeschlossene Sitzungen auf demselben Ger\u00e4t umfasst, geht aus den Prim\u00e4rquellen nicht hervor.<\/p>\n
Die Abmeldung ist das Spiegelbild. Der Wert wird auf null<\/code> gesetzt \u2014 nicht auf einen leeren String, nicht auf ein Leerzeichen, nicht auf die Zeichenkette \"null\"<\/code>.<\/p>\n
gtag('set', { 'user_id': null });<\/code><\/pre>\n
Analytics ordnet nachfolgende Events dieser User ID daraufhin nicht mehr zu: Im dokumentierten Beispiel bleiben die Events 1 bis 3 zugeordnet, Event 4 nicht. Eine erneute Anmeldung mit derselben Kennung innerhalb derselben Sitzung nimmt die Zuordnung wieder auf.<\/p>\n
Der update-Parameter: zusammenf\u00fchren statt neu initialisieren<\/h2>\n
Der set<\/code>-Befehl beantwortet eine Frage: welcher Wert soll ab
\njetzt mit allem mitreisen, was die Seite sendet. Ein zweites, enger gefasstes
\nMittel beantwortet eine andere: wie sich eine bestehende Konfiguration \u00e4ndern
\nl\u00e4sst, ohne die Nebenwirkungen eines frischen config<\/code>-Aufrufs. Dieses
\nMittel ist der update<\/code>-Parameter, \u00fcbergeben innerhalb von
\nconfig<\/code> selbst.<\/p>\n
\n
Auf true<\/code> gesetzt, f\u00fchrt der update<\/code>-Parameter neue oder ge\u00e4nderte Parameter in die bestehende Google-Tag-Konfiguration zusammen, sendet f\u00fcr diese Aktualisierung aber kein page_view<\/code>-Ereignis. \u00dcblich ist das in Single-Page-Anwendungen, um Parameter zu aktualisieren, ohne den Tag neu zu initialisieren.<\/p>\n<\/blockquote>\n
Das Feld ist ein Wahrheitswert und steht standardm\u00e4\u00dfig auf
\nfalse<\/code>. Genau diese Vorbelegung erkl\u00e4rt den doppelten Treffer aus
\ndem vorigen Abschnitt: ohne update<\/code> gilt der Aufruf als frische
\nKonfiguration, und eine frische Konfiguration sendet einen
\npage_view<\/code>.<\/p>\n
gtag('config', 'G-XXXXXXXXXX', {\n  'update': true,\n  'page_location': 'https:\/\/example.com\/new-page'\n});<\/code><\/pre>\n
Zwei Unterschiede trennen das von set<\/code>. Der erste ist die
\nReichweite: update<\/code> f\u00fchrt in die Konfiguration des einen genannten
\nZiels zusammen, w\u00e4hrend set<\/code> global f\u00fcr jedes folgende Ereignis und
\njedes Ziel zuweist. Der zweite ist die Absicht: update<\/code> \u00fcberarbeitet,
\nwas der Tag bereits h\u00e4lt, w\u00e4hrend set<\/code> einen Wert obendrauf legt,
\nohne anzutasten, was config<\/code> besetzt.<\/p>\n
Damit ist die Wahl einigerma\u00dfen klar. Eine nach der Anmeldung eintreffende
\nUser ID geh\u00f6rt in set<\/code> \u2014 sie ist eine globale Eigenschaft von allem,
\nwas folgt. Ein Seitenwechsel in einer Single-Page-Anwendung geh\u00f6rt in
\nconfig<\/code> mit update<\/code> auf true<\/code>, denn
\npage_location<\/code> und page_title<\/code> sind Konfiguration dieses
\neinen Streams, und der zugeh\u00f6rige page_view<\/code> wird besser bewusst
\ngesendet als beil\u00e4ufig erzeugt.<\/p>\n
Der Weg \u00fcber den Google Tag Manager<\/h2>\n
Tag Manager und gtag.js teilen sich ein einziges globales window.dataLayer<\/code>; pro Seite wird nur ein solches Objekt unterst\u00fctzt, und gtag()<\/code> ist ein Wrapper, der seine Argumente hineinschiebt. Ein \u00fcber GTM ausgespieltes Google Tag verarbeitet zus\u00e4tzlich zu den in der Oberfl\u00e4che konfigurierten Einstellungen auch gtag()<\/code>-Befehle auf der Seite. F\u00fcr gemeinsamen Kontext \u00fcber mehrere Google Tags hinweg nennt die GTM-Hilfeseite gtag.js auf der Website selbst \u2014 mit dem Hinweis, dass globale Parameter von allen Google Tags der Website gelesen werden und nur unkritische Daten enthalten sollten.<\/p>\n
Was die GTM-Oberfl\u00e4che nicht bietet, ist ein fertiger Tag-Typ f\u00fcr ein sp\u00e4tes set<\/code>. Die Variable Konfigurationseinstellungen<\/em> setzt Parameter, die beim Laden des Google Tags geladen werden \u2014 ein Mechanismus zur Ladezeit; die Variable Ereigniseinstellungen<\/em> erg\u00e4nzt Parameter pro Event. Keine der beiden aktualisiert ein bereits laufendes Google Tag. Das containerseitige \u00c4quivalent liegt eine Ebene unter der Oberfl\u00e4che, in der Custom-Templates-API: gtagSet(object)<\/code> schiebt einen gtag-set-Befehl in den Data Layer, der verarbeitet wird, sobald das aktuelle Event und die davon ausgel\u00f6sten Tags abgeschlossen sind, und die Referenz garantiert, dass diese Aktualisierung im Container vor allen bereits im Data Layer wartenden Eintr\u00e4gen behandelt wird. Der Weg ist damit dokumentiert; es fehlt lediglich ein vorkonfigurierter Tag-Typ daf\u00fcr, sodass die Aktualisierung \u00fcber ein eigenes Template l\u00e4uft. Ein fertiges Tag mit diesem Verhalten wird in der hier gesichteten Dokumentation nicht beschrieben, was ein negativer Befund ist und kein ausdr\u00fccklicher Ausschluss durch Google.<\/p>\n
Die Warteschlange trennt die beiden Wege. Tag Manager verarbeitet Nachrichten nach dem First-in-first-out-Prinzip, eine nach der anderen in der Reihenfolge des Eingangs. Ein gtag()<\/code>– oder dataLayer.push()<\/code>-Aufruf aus dem Seitencode oder aus einem Custom-HTML-Tag reiht sich hinter allen ausstehenden Nachrichten ein, und die aktualisierten Werte stehen f\u00fcr das n\u00e4chste Event nicht garantiert zur Verf\u00fcgung; dasselbe gilt f\u00fcr einen generischen Data-Layer-Push aus Template-Code. Die beiden dedizierten Template-APIs sind die dokumentierte Ausnahme: gtagSet<\/code> und das verwandte updateConsentState<\/code> werden garantiert im Container vor allem verarbeitet, was in der Data-Layer-Warteschlange wartet. Die Einschr\u00e4nkung liegt also nicht am Container als solchem, sondern am darin gew\u00e4hlten Weg \u2014 ein roher Push gibt keine Reihenfolgegarantie, die Template-API schon.<\/p>\n
Das Google Tag erneut auszul\u00f6sen, um die Kennung einzuschleusen, ist aus einem zweiten Grund der falsche Hebel. Der config<\/code>-Befehl st\u00f6\u00dft in manchen Produkten ein Pageview-Event an, in Google Analytics sendet er beim Laden des Tags page_view<\/code>, und dasselbe Google Tag zweimal auf einer Seite zu konfigurieren, kann doppelte Daten oder vermischte Einstellungen verursachen. Dass ein zweites Ausl\u00f6sen des GTM-Google-Tags einen zweiten page_view<\/code> erzeugt, ist eine naheliegende Schlussfolgerung aus diesen Bausteinen und keine Aussage, die Google f\u00fcr diesen Tag-Typ trifft. Eine Unterdr\u00fcckung ist mit send_page_view: false<\/code> m\u00f6glich \u2014 im Snippet, global \u00fcber set<\/code> oder in der Variablen Konfigurationseinstellungen \u2014, diese Einstellung tr\u00e4gt jedoch nicht \u00fcber Seiten hinweg.<\/p>\n
Eine Ank\u00fcndigung vom 20. Mai 2026 geh\u00f6rt ins Bild: Neue Bereitstellungs-Snippets werden einheitlich sein und den gtag<\/code>-config-Befehl entfallen lassen, wobei die Initialisierung \u00fcber einen gtm init<\/em>-Trigger konfiguriert wird, der auch auf den config-Befehl warten kann, um ein bestehendes Altsetup zu erhalten. Automatisch \u00e4ndert sich nichts, das Verhalten auf der Seite wird als unver\u00e4ndert beschrieben, und das Installationsbeispiel in der Entwicklerdokumentation zeigt weiterhin gtag('config', 'TAG_ID');<\/code>.<\/p>\n
Der verwandte Fall: Consent Mode<\/h2>\n
Consent Mode folgt derselben Form \u2014 ein Wert, der beim Laden des Tags unbekannt ist und sp\u00e4ter ohne Neuladen \u00fcbergeben wird \u2014 mit anderem Ziel und strengerer Reihenfolge. Standardm\u00e4\u00dfig sind keine Consent-Mode-Werte gesetzt. Der default<\/code>-Befehl muss auf jeder Seite vor jedem Befehl laufen, der Messdaten sendet; in falscher Reihenfolge aufgerufen, wirken die Voreinstellungen nicht.<\/p>\n
gtag('consent', 'default', {\n  'ad_storage': 'denied',\n  'ad_user_data': 'denied',\n  'ad_personalization': 'denied',\n  'analytics_storage': 'denied',\n  'wait_for_update': 500\n});<\/code><\/pre>\n
Der Wert wait_for_update<\/code> in Millisekunden steuert, wie lange das Tag wartet, bevor es Daten sendet, was f\u00fcr asynchron ladende Consent-L\u00f6sungen von Bedeutung ist; sind Netzwerkanfragen im Spiel, werden mindestens 500 Millisekunden nahegelegt. Voreinstellungen lassen sich nach Region gem\u00e4\u00df ISO 3166-2 differenzieren, wobei die spezifischere Region den Vorrang hat.<\/p>\n
Das Update geschieht auf der Seite, auf der die Entscheidung f\u00e4llt, vor jedem Seitenwechsel, denn Consent Mode speichert die Auswahl nicht selbst.<\/p>\n
gtag('consent', 'update', {\n  'ad_storage': 'granted',\n  'ad_user_data': 'granted',\n  'ad_personalization': 'granted',\n  'analytics_storage': 'granted'\n});<\/code><\/pre>\n
Ein Reload ist nicht erforderlich, und der Zustandswechsel erzeugt selbst ein Signal: Consent-State-Pings werden von jeder Seite gesendet, auf der Consent Mode aktiviert ist, und werden f\u00fcr einige Tags zus\u00e4tzlich ausgel\u00f6st, wenn der Zustand von denied auf granted wechselt. In der erweiterten Implementierung laden die Tags sofort und senden, solange die Einwilligung verweigert ist, Messungen ohne Cookies. Innerhalb von Tag-Manager-Templates ist der gtag-consent-Befehl ausdr\u00fccklich nicht zu verwenden \u2014 die API updateConsentState<\/code> existiert, damit Consent-Updates vor wartenden Data-Layer-Eintr\u00e4gen verarbeitet werden, dieselbe Reihenfolgegarantie, die gtagSet<\/code> f\u00fcr Parameter mitbringt.<\/p>\n
Fallstricke und Pr\u00fcfungen<\/h2>\n