{"id":9750,"date":"2026-08-16T16:58:29","date_gmt":"2026-08-16T14:58:29","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=9750"},"modified":"2026-08-13T14:30:57","modified_gmt":"2026-08-13T12:30:57","slug":"gtagset-w-praktyce-przekazanie-user-id-do-juz-zaladowanego-google-tag","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/gtagset-w-praktyce-przekazanie-user-id-do-juz-zaladowanego-google-tag\/","title":{"rendered":"gtag(‘set’) w praktyce: przekazanie User ID do ju\u017c za\u0142adowanego Google Tag"},"content":{"rendered":"

Aplikacja webowa z logowaniem zwykle dowiaduje si\u0119, kim jest odwiedzaj\u0105cy, o chwil\u0119 za p\u00f3\u017ano. Strona si\u0119 \u0142aduje, Google Tag si\u0119 inicjalizuje, polecenie config<\/code> wysy\u0142a sw\u00f3j page_view<\/code> \u2014 a dopiero potem formularz logowania zwraca sesj\u0119 albo aplikacja single-page ustala konto na podstawie wywo\u0142ania API. Zanim User ID zaistnieje, pierwszy hit ju\u017c opu\u015bci\u0142 przegl\u0105dark\u0119.<\/p>\n

Odruchem w takiej sytuacji jest ponowne skonfigurowanie tagu z do\u0142\u0105czonym identyfikatorem. Ten odruch jest kosztowny i zb\u0119dny. Ju\u017c za\u0142adowany Google Tag nie musi by\u0107 prze\u0142adowywany ani ponownie inicjalizowany tylko dlatego, \u017ce jedna warto\u015b\u0107 dotar\u0142a z op\u00f3\u017anieniem: pojedyncze polecenie set<\/code> przekazuje t\u0119 warto\u015b\u0107, a ka\u017cde zdarzenie wys\u0142ane p\u00f3\u017aniej na tej stronie j\u0105 niesie.<\/p>\n

\n\"Dwie
Ten sam moment, dwie drogi: ponowne uruchomienie Google Tag inicjalizuje go jeszcze raz i zapisuje drugi page_view w sesji, natomiast jedno polecenie set przekazuje User ID do dzia\u0142aj\u0105cego tagu, a ka\u017cde kolejne zdarzenie je niesie.<\/figcaption><\/figure>\n

Pi\u0119\u0107 polece\u0144 gtag i wzajemne oddzia\u0142ywanie ich zakres\u00f3w<\/h2>\n

API gtag.js zna dok\u0142adnie pi\u0119\u0107 polece\u0144, a podzia\u0142 zada\u0144 mi\u0119dzy nimi jest tym, co umo\u017cliwia p\u00f3\u017ane przekazanie warto\u015bci.<\/p>\n\n\n\n\n\n\n\n\n\n
Polecenie<\/th>\nSygnatura<\/th>\nCel<\/th>\nZasi\u0119g<\/th>\n<\/tr>\n<\/thead>\n
config<\/code><\/td>\ngtag('config', '<TARGET_ID>', {\u2026})<\/code><\/td>\nDodaje informacje konfiguracyjne do celu; TARGET_ID decyduje, dok\u0105d gtag.js wysy\u0142a dane zdarze\u0144, a kolejne wywo\u0142anie dodaje kolejny cel.<\/td>\nWszystkie zdarzenia do tego jednego TARGET_ID.<\/td>\n<\/tr>\n
set<\/code><\/td>\ngtag('set', {\u2026})<\/code><\/td>\nDefiniuje parametry powi\u0105zane z ka\u017cdym kolejnym zdarzeniem na stronie. Istnieje te\u017c forma z nazwan\u0105 grup\u0105, na przyk\u0142ad gtag('set', 'campaign', {\u2026})<\/code>.<\/td>\nGlobalny, od momentu wywo\u0142ania, wy\u0142\u0105cznie bie\u017c\u0105ca strona.<\/td>\n<\/tr>\n
event<\/code><\/td>\ngtag('event', '<event_name>', {\u2026})<\/code><\/td>\nWysy\u0142a dane zdarzenia, zar\u00f3wno zdarzenia rekomendowanego, jak i w\u0142asnego.<\/td>\nTo jedno zdarzenie.<\/td>\n<\/tr>\n
get<\/code><\/td>\ngtag('get', '<target>', '<field>', callback)<\/code><\/td>\nOdczytuje warto\u015bci z gtag.js, w tym warto\u015bci przypisane poleceniem set<\/code>: client_id<\/code>, session_id<\/code>, session_number<\/code>, gclid<\/code>.<\/td>\nDost\u0119p do odczytu; callback otrzymuje pole albo undefined<\/code>.<\/td>\n<\/tr>\n
consent<\/code><\/td>\ngtag('consent', 'default'|'update', {\u2026})<\/code><\/td>\nUstawia pocz\u0105tkowy stan zgody albo aktualizuje go, gdy decyzja ju\u017c istnieje.<\/td>\nSygna\u0142y zgody dla strony.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Istniej\u0105 zatem trzy zakresy: pojedyncze zdarzenia, wszystkie zdarzenia do okre\u015blonego TARGET_ID oraz globalnie wszystkie zdarzenia. Gdy ten sam parametr zostaje przypisany w wi\u0119cej ni\u017c jednym z nich, przy przetwarzaniu zdarzenia u\u017cywana jest tylko jedna warto\u015b\u0107, a kolejno\u015b\u0107 brzmi: event przed config przed set<\/strong>. Rozstrzygaj\u0105cy szczeg\u00f3\u0142 znajduje si\u0119 wiersz ni\u017cej w dokumentacji referencyjnej: pierwsze\u0144stwo to nie nadpisanie.<\/p>\n

\n

Warto\u015bci parametr\u00f3w ustawione w jednym zakresie nie zmieniaj\u0105 warto\u015bci ustawionych dla tego samego parametru w innym zakresie.<\/p>\n<\/blockquote>\n

W udokumentowanym przyk\u0142adzie campaign_id<\/code> zostaje przypisany globalnie jako '1234'<\/code>, a nast\u0119pnie jako 'ABCD'<\/code> w wywo\u0142aniu config<\/code>; potem warto\u015b\u0107 globalna nadal wynosi '1234'<\/code>. Zakresy zachowuj\u0105 swoje warto\u015bci obok siebie, a hierarchia rozstrzyga dopiero w momencie przetwarzania, kt\u00f3ra z nich obowi\u0105zuje. Po\u0142\u0105czenie obu regu\u0142 prowadzi do konsekwencji, kt\u00f3rej dokumentacja nie wypowiada wprost: wywo\u0142anie set<\/code> wydane po config<\/code> nie wypiera warto\u015bci, jak\u0105 config<\/code> ju\u017c zajmuje dla danego celu, i dzia\u0142a dla parametr\u00f3w pozostawionych przez config<\/code> nietkni\u0119tymi.<\/p>\n

W kwestii powt\u00f3rze\u0144 dokumentacja jest jednoznaczna: config<\/code> nale\u017cy wywo\u0142ywa\u0107 raz na Google Tag, a ka\u017cde kolejne wywo\u0142anie powinno korzysta\u0107 z set<\/code>. Zaleca te\u017c config<\/code> lub event<\/code> zamiast set<\/code> wsz\u0119dzie, gdzie to mo\u017cliwe, co dotyczy zw\u0142aszcza w\u0142asnych parametr\u00f3w zdarze\u0144, poniewa\u017c set<\/code> mo\u017ce nie przekazywa\u0107 ich niezawodnie do wszystkich strumieni pomiarowych Google Analytics. Dla udokumentowanych parametr\u00f3w globalnych, takich jak user_id<\/code>, page_title<\/code> czy currency<\/code>, set<\/code> jest narz\u0119dziem przewidzianym.<\/p>\n

Przypadek szczeg\u00f3\u0142owo: p\u00f3\u017ane przekazanie User ID<\/h2>\n

User ID to samodzielnie przydzielane identyfikatory poszczeg\u00f3lnych u\u017cytkownik\u00f3w; konsekwentne ich przypisywanie nale\u017cy do operatora, zwykle przy logowaniu. Tam, gdzie identyfikator jest znany ju\u017c w momencie renderowania, mo\u017ce podr\u00f3\u017cowa\u0107 wewn\u0105trz wywo\u0142ania config<\/code>. Tam, gdzie staje si\u0119 znany dopiero po za\u0142adowaniu strony, gtag('set')<\/code> jest drog\u0105 udokumentowan\u0105. Snippet na stronie pozostaje dok\u0142adnie taki, jak zosta\u0142 zainstalowany.<\/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
Po nadej\u015bciu odpowiedzi logowania wystarczy jedno polecenie. Bez drugiego config<\/code>, bez drugiego snippetu, bez prze\u0142adowania.<\/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
To, co dzieje si\u0119 dalej, rozdziela si\u0119 mi\u0119dzy przegl\u0105dark\u0119 a stron\u0119 przetwarzania. W przegl\u0105darce efekt zaczyna si\u0119 w momencie wywo\u0142ania i trwa do ko\u0144ca strony. Ka\u017cde zdarzenie wys\u0142ane po poleceniu set<\/code> niesie user_id<\/code>; \u017cadne zdarzenie wys\u0142ane wcze\u015bniej go nie niesie. Sformu\u0142owanie z dokumentacji \u2014 parametry powi\u0105zane z ka\u017cdym kolejnym zdarzeniem na stronie \u2014 ogranicza efekt do przodu w czasie oraz do bie\u017c\u0105cego dokumentu. Klasyczna witryna wielostronicowa wydaje wi\u0119c to polecenie ponownie przy ka\u017cdym za\u0142adowaniu strony; aplikacja single-page wydaje je raz na czas \u017cycia dokumentu.<\/p>\n
Po stronie przetwarzania wcze\u015bniejsze zdarzenia nie przepadaj\u0105. Analytics wi\u0105\u017ce zdarzenia wys\u0142ane przed ustawieniem User ID z tym User ID. Udokumentowany przyk\u0142ad prowadzi przez sesj\u0119 rozpocz\u0119t\u0105 bez zalogowania: zdarzenie 1 i zdarzenie 2 nie nios\u0105 identyfikatora, u\u017cytkownik si\u0119 loguje, nast\u0119puje zdarzenie 3 \u2014 a potem zdarzenia 1, 2 i 3 s\u0105 powi\u0105zane z identyfikatorem tego u\u017cytkownika. Obowi\u0105zuj\u0105 dwie granice. Powi\u0105zanie opisano w obr\u0119bie sesji i nie si\u0119ga ono wstecz do danych zebranych, zanim implementacja istnia\u0142a; takie dane nie s\u0105 przetwarzane ponownie. Czy obejmuje ono wcze\u015bniejsze, ju\u017c zamkni\u0119te sesje na tym samym urz\u0105dzeniu, nie zosta\u0142o podane w \u017ar\u00f3d\u0142ach pierwotnych.<\/p>\n
Wylogowanie jest odbiciem lustrzanym. Warto\u015b\u0107 zostaje ustawiona na null<\/code> \u2014 nie na pusty ci\u0105g, nie na spacj\u0119, nie na ci\u0105g \"null\"<\/code>.<\/p>\n
gtag('set', { 'user_id': null });<\/code><\/pre>\n
Analytics przestaje wtedy wi\u0105za\u0107 kolejne zdarzenia z tym User ID: w udokumentowanym przyk\u0142adzie zdarzenia od 1 do 3 pozostaj\u0105 powi\u0105zane, a zdarzenie 4 nie. Ponowne zalogowanie tym samym identyfikatorem w obr\u0119bie tej samej sesji wznawia powi\u0105zanie.<\/p>\n
Parametr update: scalanie zamiast ponownej inicjalizacji<\/h2>\n
Polecenie set<\/code> odpowiada na jedno pytanie: kt\u00f3ra warto\u015b\u0107 ma odt\u0105d
\ntowarzyszy\u0107 wszystkiemu, co strona wysy\u0142a. Drugie, w\u0119\u017csze narz\u0119dzie odpowiada na
\ninne: jak zmieni\u0107 istniej\u0105c\u0105 konfiguracj\u0119 bez skutk\u00f3w ubocznych \u015bwie\u017cego
\nwywo\u0142ania config<\/code>. Tym narz\u0119dziem jest parametr update<\/code>,
\nprzekazywany wewn\u0105trz samego config<\/code>.<\/p>\n
\n
Ustawiony na true<\/code> parametr update<\/code> scala nowe lub zmienione parametry z istniej\u0105c\u0105 konfiguracj\u0105 Google tag, ale nie wysy\u0142a dla tej aktualizacji zdarzenia page_view<\/code>. Stosuje si\u0119 to zwykle w aplikacjach jednostronicowych, aby aktualizowa\u0107 parametry bez ponownej inicjalizacji tagu.<\/p>\n<\/blockquote>\n
Pole jest warto\u015bci\u0105 logiczn\u0105 i domy\u015blnie ma false<\/code>. W\u0142a\u015bnie ta
\nwarto\u015b\u0107 domy\u015blna t\u0142umaczy zdublowane trafienie z poprzedniej sekcji: bez
\nupdate<\/code> wywo\u0142anie liczy si\u0119 jako \u015bwie\u017ca konfiguracja, a \u015bwie\u017ca
\nkonfiguracja wysy\u0142a page_view<\/code>.<\/p>\n
gtag('config', 'G-XXXXXXXXXX', {\n  'update': true,\n  'page_location': 'https:\/\/example.com\/new-page'\n});<\/code><\/pre>\n
Od set<\/code> odr\u00f3\u017cniaj\u0105 to dwie rzeczy. Pierwsza to zasi\u0119g:
\nupdate<\/code> scala z konfiguracj\u0105 jednego wskazanego celu, podczas gdy
\nset<\/code> przypisuje globalnie dla ka\u017cdego kolejnego zdarzenia i ka\u017cdego
\ncelu. Druga to zamiar: update<\/code> poprawia to, co tag ju\u017c przechowuje,
\nnatomiast set<\/code> dok\u0142ada warto\u015b\u0107 obok, nie naruszaj\u0105c tego, co zajmuje
\nconfig<\/code>.<\/p>\n
Wyb\u00f3r jest zatem do\u015b\u0107 jasny. User ID przychodz\u0105ce po zalogowaniu nale\u017cy do
\nset<\/code> \u2014 jest globaln\u0105 w\u0142a\u015bciwo\u015bci\u0105 wszystkiego, co nast\u0119puje. Zmiana
\ntrasy w aplikacji jednostronicowej nale\u017cy do config<\/code> z
\nupdate<\/code> ustawionym na true<\/code>, poniewa\u017c
\npage_location<\/code> i page_title<\/code> s\u0105 konfiguracj\u0105 tego jednego
\nstrumienia, a towarzysz\u0105cy im page_view<\/code> lepiej wys\u0142a\u0107 \u015bwiadomie ni\u017c
\nmimochodem.<\/p>\n
Droga przez Google Tag Manager<\/h2>\n
Tag Manager i gtag.js dziel\u0105 jeden globalny obiekt window.dataLayer<\/code>; na stron\u0119 obs\u0142ugiwany jest tylko jeden taki obiekt, a gtag()<\/code> jest wrapperem, kt\u00f3ry wpycha do niego swoje argumenty. Google Tag wdro\u017cony przez GTM przetwarza r\u00f3wnie\u017c polecenia gtag()<\/code> ze strony, obok ustawie\u0144 skonfigurowanych w interfejsie. Dla wsp\u00f3lnego kontekstu kilku Google Tags strona pomocy GTM wskazuje gtag.js w samej witrynie \u2014 z zastrze\u017ceniem, \u017ce parametry globalne s\u0105 odczytywane przez wszystkie Google Tags w witrynie i powinny nie\u015b\u0107 wy\u0142\u0105cznie dane niewra\u017cliwe.<\/p>\n
Czego interfejs GTM nie oferuje, to gotowego typu tagu dla p\u00f3\u017anego set<\/code>. Zmienna Configuration settings<\/em> ustawia parametry \u0142adowane wraz z Google Tag \u2014 mechanizm z czasu \u0142adowania; zmienna Event settings<\/em> dodaje parametry per zdarzenie. \u017badna z nich nie aktualizuje Google Tag, kt\u00f3ry ju\u017c dzia\u0142a. Odpowiednik po stronie kontenera le\u017cy o poziom ni\u017cej ni\u017c interfejs, w Custom Templates API: gtagSet(object)<\/code> wpycha polecenie gtag set do data layer, do przetworzenia, gdy tylko bie\u017c\u0105ce zdarzenie i wywo\u0142ane przez nie tagi si\u0119 zako\u0144cz\u0105, a dokumentacja gwarantuje, \u017ce ta aktualizacja zostanie obs\u0142u\u017cona w kontenerze przed elementami ju\u017c oczekuj\u0105cymi w data layer. Droga jest zatem udokumentowana; brakuje jedynie wst\u0119pnie skonfigurowanego typu tagu, wobec czego aktualizacja przebiega przez w\u0142asny szablon. Spakowany tag o takim zachowaniu nie jest opisany w przejrzanej tu dokumentacji, co stanowi ustalenie negatywne, a nie wyra\u017ane wykluczenie ze strony Google.<\/p>\n
Kolejka jest tym, co dzieli obie \u015bcie\u017cki. Tag Manager przetwarza komunikaty first in, first out, po jednym naraz, w kolejno\u015bci otrzymania. Wywo\u0142anie gtag()<\/code> lub dataLayer.push()<\/code> z kodu strony albo z tagu Custom HTML trafia do kolejki za wszystkimi oczekuj\u0105cymi komunikatami, a dost\u0119pno\u015b\u0107 zaktualizowanych warto\u015bci dla nast\u0119pnego zdarzenia nie jest gwarantowana; to samo dotyczy zwyk\u0142ego pushu do data layer z kodu szablonu. Dwa dedykowane API szablon\u00f3w stanowi\u0105 udokumentowany wyj\u0105tek: gtagSet<\/code> i pokrewne updateConsentState<\/code> maj\u0105 gwarancj\u0119 przetworzenia w kontenerze przed czymkolwiek, co czeka w kolejce data layer. Ograniczeniem nie jest wi\u0119c kontener jako taki, lecz wybrana przez niego droga \u2014 surowy push nie niesie gwarancji kolejno\u015bci, API szablon\u00f3w tak.<\/p>\n
Ponowne uruchomienie Google Tag w celu wstrzykni\u0119cia identyfikatora jest niew\u0142a\u015bciw\u0105 d\u017awigni\u0105 r\u00f3wnie\u017c z drugiego powodu. Polecenie config<\/code> inicjuje w niekt\u00f3rych produktach zdarzenie pageview, w Google Analytics wysy\u0142a page_view<\/code> przy \u0142adowaniu tagu, a dwukrotne skonfigurowanie tego samego Google Tag na jednej stronie mo\u017ce prowadzi\u0107 do zduplikowanych danych albo pomieszanych ustawie\u0144. To, \u017ce drugie uruchomienie Google Tag z GTM wytwarza drugi page_view<\/code>, jest uzasadnionym wnioskiem z tych element\u00f3w, a nie stwierdzeniem Google dla tego typu tagu. T\u0142umienie jest mo\u017cliwe przez send_page_view: false<\/code> \u2014 w snippecie, globalnie przez set<\/code> albo w zmiennej Configuration settings \u2014 ale to ustawienie nie przenosi si\u0119 mi\u0119dzy stronami.<\/p>\n
W obraz wpisuje si\u0119 zapowied\u017a datowana na 20 maja 2026: nowe snippety wdro\u017ceniowe maj\u0105 by\u0107 jednolite i zrezygnuj\u0105 z polecenia gtag<\/code> config, a inicjalizacja b\u0119dzie konfigurowana przez regu\u0142\u0119 gtm init<\/em>, kt\u00f3ra mo\u017ce te\u017c zaczeka\u0107 na polecenie config, aby zachowa\u0107 starsz\u0105 konfiguracj\u0119. Nic nie zmienia si\u0119 automatycznie, zachowanie na stronie opisano jako nienaruszone, a przyk\u0142ad instalacji w dokumentacji dla programist\u00f3w nadal pokazuje gtag('config', 'TAG_ID');<\/code>.<\/p>\n
Przypadek pokrewny: Consent Mode<\/h2>\n
Consent Mode ma ten sam kszta\u0142t \u2014 warto\u015b\u0107 nieznana w chwili \u0142adowania tagu, przekazana p\u00f3\u017aniej bez prze\u0142adowywania czegokolwiek \u2014 z innym celem i ostrzejszym porz\u0105dkiem. Domy\u015blnie \u017cadne warto\u015bci consent mode nie s\u0105 ustawione. Polecenie default<\/code> musi wykona\u0107 si\u0119 na ka\u017cdej stronie przed jakimkolwiek poleceniem wysy\u0142aj\u0105cym dane pomiarowe; wywo\u0142ane poza kolejno\u015bci\u0105, warto\u015bci domy\u015blne nie dzia\u0142aj\u0105.<\/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
Warto\u015b\u0107 wait_for_update<\/code> w milisekundach steruje tym, jak d\u0142ugo tag czeka przed wys\u0142aniem danych, co ma znaczenie dla rozwi\u0105za\u0144 zgody \u0142adowanych asynchronicznie; tam, gdzie w gr\u0119 wchodz\u0105 \u017c\u0105dania sieciowe, sugerowane jest co najmniej 500 milisekund. Warto\u015bci domy\u015blne mo\u017cna r\u00f3\u017cnicowa\u0107 regionalnie zgodnie z ISO 3166-2, przy czym wygrywa region bardziej szczeg\u00f3\u0142owy.<\/p>\n
Aktualizacja nast\u0119puje na stronie, na kt\u00f3rej zapada decyzja, przed jakimkolwiek przej\u015bciem na inn\u0105 stron\u0119, poniewa\u017c Consent Mode sam nie przechowuje wyboru.<\/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
Prze\u0142adowanie nie jest wymagane, a sama zmiana stanu wytwarza sygna\u0142: consent state pings s\u0105 wysy\u0142ane z ka\u017cdej strony, na kt\u00f3rej consent mode jest w\u0142\u0105czony, a dla cz\u0119\u015bci tag\u00f3w s\u0105 dodatkowo wyzwalane, gdy stan zmienia si\u0119 z denied na granted. W implementacji zaawansowanej tagi \u0142aduj\u0105 si\u0119 natychmiast i przy braku zgody wysy\u0142aj\u0105 pomiary bez cookies. Wewn\u0105trz szablon\u00f3w Tag Managera polecenia gtag consent wyra\u017anie nie nale\u017cy u\u017cywa\u0107 \u2014 API updateConsentState<\/code> istnieje po to, aby aktualizacje zgody by\u0142y przetwarzane przed elementami czekaj\u0105cymi w data layer, czyli z t\u0105 sam\u0105 gwarancj\u0105 kolejno\u015bci, jak\u0105 gtagSet<\/code> niesie dla parametr\u00f3w.<\/p>\n
Pu\u0142apki i kontrole<\/h2>\n