{"id":9748,"date":"2026-08-16T12:58:48","date_gmt":"2026-08-16T10:58:48","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9748"},"modified":"2026-08-13T14:30:55","modified_gmt":"2026-08-13T12:30:55","slug":"gtagset-in-practice-handing-a-user-id-to-a-google-tag-that-has-already-loaded","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-analytics\/gtagset-in-practice-handing-a-user-id-to-a-google-tag-that-has-already-loaded\/","title":{"rendered":"gtag(‘set’) in practice: handing a User ID to a Google tag that has already loaded"},"content":{"rendered":"

A signed-in web application usually learns who the visitor is a moment too late. The page loads, the Google tag initialises, the config<\/code> command sends its page_view<\/code> \u2014 and only afterwards does the login form return a session, or the single-page application resolve the account from an API call. By the time the User ID exists, the first hit has already left the browser.<\/p>\n

The reflex in that situation is to configure the tag a second time with the identifier attached. That reflex is expensive and unnecessary. An already loaded Google tag does not have to be reloaded or re-initialised because one value arrived late: a single set<\/code> command hands the value over, and every event sent afterwards on that page carries it.<\/p>\n

\n\"Two
The same moment, two routes: firing the Google tag again re-initialises it and writes a second page_view into the session, while one set command hands the User ID to the tag that is already running and every following event carries it.<\/figcaption><\/figure>\n

The five gtag commands and how their scopes interact<\/h2>\n

The gtag.js API knows exactly five commands, and their division of labour is what makes the late hand-over possible.<\/p>\n\n\n\n\n\n\n\n\n\n
Command<\/th>\nSignature<\/th>\nPurpose<\/th>\nReach<\/th>\n<\/tr>\n<\/thead>\n
config<\/code><\/td>\ngtag('config', '<TARGET_ID>', {\u2026})<\/code><\/td>\nAdds configuration information to a target; the TARGET_ID decides where gtag.js sends event data, and a further call adds a further destination.<\/td>\nAll events to that one TARGET_ID.<\/td>\n<\/tr>\n
set<\/code><\/td>\ngtag('set', {\u2026})<\/code><\/td>\nDefines parameters associated with every subsequent event on the page. A named group form exists too, for example gtag('set', 'campaign', {\u2026})<\/code>.<\/td>\nGlobal, from the call onwards, current page only.<\/td>\n<\/tr>\n
event<\/code><\/td>\ngtag('event', '<event_name>', {\u2026})<\/code><\/td>\nSends event data, either a recommended event or a custom one.<\/td>\nThat single event.<\/td>\n<\/tr>\n
get<\/code><\/td>\ngtag('get', '<target>', '<field>', callback)<\/code><\/td>\nReads values back out of gtag.js, including values assigned with set<\/code>: client_id<\/code>, session_id<\/code>, session_number<\/code>, gclid<\/code>.<\/td>\nRead access; the callback receives the field or undefined<\/code>.<\/td>\n<\/tr>\n
consent<\/code><\/td>\ngtag('consent', 'default'|'update', {\u2026})<\/code><\/td>\nSets the initial consent state, or updates it once a decision exists.<\/td>\nConsent signals for the page.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Three scopes therefore exist: individual events, all events to a specific TARGET_ID, and globally all events. Where the same parameter is assigned in more than one of them, only a single value is used when an event is processed, and the order is event before config before set<\/strong>. The decisive detail sits one line further down in the reference: precedence is not overwriting.<\/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

In the documented example campaign_id<\/code> is assigned globally as '1234'<\/code> and then as 'ABCD'<\/code> in a config<\/code> call; afterwards the global value is still '1234'<\/code>. The scopes keep their values side by side, and the ranking decides only at processing time which applies. Combining the two rules yields a consequence the documentation does not spell out: a set<\/code> call issued after config<\/code> does not displace a value config<\/code> already occupies for that target, and takes effect for the parameters config<\/code> left untouched.<\/p>\n

On repetition the documentation is explicit: config<\/code> is to be called once per Google tag, every subsequent call should use set<\/code>. It also recommends config<\/code> or event<\/code> over set<\/code> wherever possible, which concerns custom event parameters in particular, because set<\/code> may not propagate them reliably to all Google Analytics measurement streams. For documented global parameters such as user_id<\/code>, page_title<\/code> or currency<\/code>, set<\/code> is the intended instrument.<\/p>\n

The case in detail: handing over the User ID late<\/h2>\n

User IDs are self-assigned identifiers for individual users; assigning them consistently is the operator’s business, normally at login. Where the identifier is already known at render time, it can travel inside the config<\/code> call. Where it becomes known only after the page has loaded, gtag('set')<\/code> is the documented route. The page snippet stays exactly as installed.<\/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
Once the login response arrives, one command is enough. No second config<\/code>, no second snippet, no 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
What happens next is split between the browser and the processing side. In the browser, the effect starts at the moment of the call and runs to the end of the page. Every event dispatched after the set<\/code> command carries user_id<\/code>; every event dispatched before it does not. The phrase in the reference \u2014 parameters associated with every subsequent event on the page \u2014 limits the effect forwards in time and to the current document. A classic multi-page site therefore re-issues the command on each page load; a single-page application issues it once for the lifetime of the document.<\/p>\n
On the processing side, the earlier events are not lost. Analytics associates events that fired before the User ID was set with that User ID. The documented example runs through a session that starts signed out: event 1 and event 2 carry no identifier, the user signs in, event 3 follows \u2014 and afterwards events 1, 2 and 3 are all associated with that user’s ID. Two boundaries apply. The association is described within a session, and it does not reach back into data collected before the implementation existed; such data is not reprocessed. Whether it extends to earlier, already closed sessions on the same device is not stated in the primary sources.<\/p>\n
Sign-out is the mirror image. The value is set to null<\/code> \u2014 not an empty string, not a space, not the string \"null\"<\/code>.<\/p>\n
gtag('set', { 'user_id': null });<\/code><\/pre>\n
Analytics then stops associating subsequent events with that User ID: in the documented example, events 1 to 3 remain associated and event 4 does not. A renewed sign-in with the same identifier within the same session resumes the association.<\/p>\n
The update parameter: merging instead of re-initialising<\/h2>\n
The set<\/code> command answers one question: which value should travel
\nwith everything the page sends from now on. A second, narrower instrument
\nanswers a different one: how an existing configuration is changed without the
\nside effects of a fresh config<\/code> call. That instrument is the
\nupdate<\/code> parameter, passed inside config<\/code> itself.<\/p>\n
\n
If set to true<\/code>, the update<\/code> parameter merges new or updated parameters into the existing Google tag configuration but does not send a page_view<\/code> event for that update. This is typically used in single-page applications to update parameters without re-initializing the tag.<\/p>\n<\/blockquote>\n
The field is a boolean and defaults to false<\/code>. That default is
\nprecisely why a repeated config<\/code> call produces the duplicate hit
\ndescribed above: without update<\/code>, the call is treated as a fresh
\nconfiguration, and a fresh configuration sends a page_view<\/code>.<\/p>\n
gtag('config', 'G-XXXXXXXXXX', {\n  'update': true,\n  'page_location': 'https:\/\/example.com\/new-page'\n});<\/code><\/pre>\n
Two differences separate this from set<\/code>. The first is reach:
\nupdate<\/code> merges into the configuration of the one target it names,
\nwhile set<\/code> assigns globally for every subsequent event and every
\ndestination. The second is intent: update<\/code> revises what the tag
\nalready holds, whereas set<\/code> adds a value on top without touching
\nwhat config<\/code> occupies.<\/p>\n
That makes the choice reasonably clear. A User ID arriving after login
\nbelongs in set<\/code> \u2014 it is a global property of everything that
\nfollows. A route change in a single-page application belongs in
\nconfig<\/code> with update<\/code> set to true<\/code>, because
\npage_location<\/code> and page_title<\/code> are configuration of that
\none stream, and the accompanying page_view<\/code> is better sent
\ndeliberately than as a by-product.<\/p>\n
The Google Tag Manager route<\/h2>\n
Tag Manager and gtag.js share a single global window.dataLayer<\/code>; only one such object is supported per page, and gtag()<\/code> is a wrapper that pushes its arguments into it. A Google tag deployed through GTM also processes on-page gtag()<\/code> commands in addition to the settings configured in the interface. For common context across several Google tags, the GTM help page names gtag.js on the website itself \u2014 with the caveat that global parameters are read by all Google tags on the site and should carry non-sensitive data only.<\/p>\n
What the GTM interface does not offer is a ready-made tag type for a late set<\/code>. The Configuration settings<\/em> variable sets parameters loaded when the Google tag loads \u2014 a load-time mechanism; the Event settings<\/em> variable adds parameters per event. Neither of the two updates a Google tag that is already running. The container-side equivalent sits one level below the interface, in the Custom Templates API: gtagSet(object)<\/code> pushes a gtag set command into the data layer, to be processed as soon as the current event and the tags it triggered have finished, and the reference guarantees that this update is handled in the container before any items already queued in the data layer. The route is therefore documented; what is missing is only a preconfigured tag type for it, so the update runs through a template of one’s own. A packaged tag with that behaviour is not described in the documentation reviewed here, which is a negative finding rather than an explicit exclusion by Google.<\/p>\n
The queue is what separates the two paths. Tag Manager processes messages first in, first out, one at a time in the order received. A gtag()<\/code> or dataLayer.push()<\/code> call from page code or from a Custom HTML tag is queued behind all pending messages, and the updated values are not guaranteed to be available for the next event; the same applies to a generic data layer push out of template code. The two dedicated template APIs are the documented exception: gtagSet<\/code> and its sibling updateConsentState<\/code> are guaranteed to be processed in the container ahead of anything waiting in the data layer queue. The constraint is thus not the container as such but the path chosen through it \u2014 a raw push carries no ordering guarantee, the template API does.<\/p>\n
Re-firing the Google tag to inject the identifier is the wrong lever for a second reason. The config<\/code> command initiates a pageview event in some products, in Google Analytics it sends page_view<\/code> when the tag loads, and configuring the same Google tag twice on one page may cause duplicate data or mixed settings. That a second firing of the GTM Google tag produces a second page_view<\/code> is a reasonable inference from these pieces, not a statement Google makes for that tag type. Suppression is possible with send_page_view: false<\/code> \u2014 in the snippet, globally via set<\/code>, or in the Configuration settings variable \u2014 but that setting does not carry across pages.<\/p>\n
An announcement dated 20 May 2026 belongs in the picture: new deployment snippets will be uniform and will drop the gtag<\/code> config command, with initialisation configured through a gtm init<\/em> trigger that can also wait for the config command to preserve a legacy setup. Nothing changes automatically, in-page behaviour is described as unaffected, and the install example in the developer documentation still shows gtag('config', 'TAG_ID');<\/code>.<\/p>\n
The sibling case: Consent Mode<\/h2>\n
Consent Mode follows the same shape \u2014 a value unknown when the tag loads, handed over later without reloading anything \u2014 with a different target and stricter ordering. By default no consent mode values are set. The default<\/code> command must run on every page before any command that sends measurement data; called out of order, the defaults do not work.<\/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
The wait_for_update<\/code> value in milliseconds controls how long the tag waits before sending data, which matters for consent solutions that load asynchronously; where network requests are involved, at least 500 milliseconds is suggested. Defaults can be differentiated by region per ISO 3166-2, the more specific region winning.<\/p>\n
The update happens on the page where the decision is made, before any page transition, because Consent Mode does not store the choice itself.<\/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
No reload is required, and the state change itself produces a signal: consent state pings are sent from each page where consent mode is enabled and are additionally triggered for some tags when the state changes from denied to granted. In the advanced implementation the tags load immediately and, while consent is denied, send measurements without cookies. Inside Tag Manager templates the gtag consent command is explicitly not to be used \u2014 the updateConsentState<\/code> API exists so that consent updates are processed ahead of queued data layer items, the same ordering guarantee gtagSet<\/code> carries for parameters.<\/p>\n
Pitfalls and checks<\/h2>\n