gtag(’set’) w praktyce: przekazanie User ID do już załadowanego Google Tag

User ID może stać się dostępny dopiero po udanym logowaniu. Instrukcja Google Analytics wyraźnie zaleca gtag('set', {user_id: ...}) do ustawiania lub aktualizacji identyfikatora po inicjalizacji. Ponowne ładowanie biblioteki nie jest potrzebne. Artykuł opisuje już zainstalowany samodzielny Google tag; kontener GTM wymaga odpowiedniej obsługiwanej konfiguracji kontenera.

Zakres i obsługa parametru to osobne kwestie

Ogólne pierwszeństwo parametrów wynosi event > config > set. Przypisanie w jednym zakresie nie usuwa przypisania w innym. Ta reguła nie oznacza jednak, że każdy parametr jest poprawny w każdym zakresie: Google definiuje user_id jako zastrzeżony parametr konfiguracji i wyraźnie zabrania przekazywania jako parametru zdarzenia lub własnej właściwości użytkownika. Niedopuszczalna jest również rejestracja jako wymiaru niestandardowego.

Spójna implementacja unika konkurencyjnych przypisań tożsamości. Identyfikator zapisany na stałe w początkowym config nie musi zniknąć po samej zmianie wartości globalnej. Testy zmiany konta i wylogowania muszą obejmować rzeczywiste żądania wychodzące. Pozostające przypisanie o wyższym priorytecie wymaga poprawienia konfiguracji. Dodawanie user_id do każdego zdarzenia nie jest rozwiązaniem.

Pięć poleceń, różne zadania

• config inicjalizuje lub konfiguruje Google tag. Jeden tag może mieć wiele powiązanych identyfikatorów i odbiorców; kolejne wywołanie nie musi tworzyć osobnego odbiorcy. Instrukcja zaleca jedno wywołanie na Google tag.
• set zmienia obsługiwane parametry globalne dla kolejnych zdarzeń w bieżącym dokumencie.
• event wysyła nazwane zdarzenie z obsługiwanymi parametrami i opcjonalnym kierowaniem przez send_to.
• get asynchronicznie odczytuje obsługiwane pole. Dostępność zależy od odbiorcy; gclid nie jest uniwersalnym polem GA4.
• consent przekazuje domyślne lub zaktualizowane sygnały zgody. Zmiana parametru nie ustanawia zgody.

Odtworzenie sesji a rzeczywiste logowanie

Przykład zakłada zainicjalizowany samodzielny tag, istniejącą obsługę zgody i uwierzytelniony stan konta aplikacji. Nie dodaje skryptu ładującego ani wywołania config. Uwierzytelniona aplikacja musi dostarczyć identyfikator przydzielony do tego celu analitycznego. Jego znaki nie mogą bezpośrednio ujawniać danych osobowych, takich jak nazwisko lub adres e-mail. Adres e-mail, numer telefonu, ciasteczko sesyjne i token bearer nie nadają się do tego celu.

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
  });
}

Dopuszczalna długość 16–128 znaków i ich zestaw są regułami tego przykładu, a nie pełną specyfikacją Google; Google dopuszcza do 256 znaków. Pasujący ciąg nie dowodzi uprawnienia ani anonimowości. permitted musi wynikać z aktualnej zatwierdzonej polityki pomiaru tożsamości w aplikacji, a nie bezpośrednio z niezaufanego żądania.

Odtwarzanie sesji wywołuje tylko syncAnalyticsIdentity. Potwierdzone aktualne przejście do stanu zalogowania może jednokrotnie wywołać recordConfirmedLogin z rzeczywistą metodą. Aplikacja musi odrzucać nieaktualne odpowiedzi uwierzytelniania i zapobiegać powielonym powiadomieniom o przejściu. Przykładowy identyfikator pomiaru wymaga zastąpienia. Nazwy metod stanowią jawną listę dozwolonych wartości aplikacji.

Wylogowanie, zmiana konta i wycofanie zgody wymagają natychmiastowej synchronizacji. syncAnalyticsIdentity(null, false) usuwa to przypisanie globalne, ale nie wycofuje zgody, nie usuwa konkurencyjnych wartości konfiguracji ani zebranych wcześniej danych. Obsługa zgody i pomiarów musi osobno zatrzymać niedozwolone zbieranie danych. Pierwsza wizyta bez identyfikatora nie wymaga wysyłania fikcyjnej ID.

Żądania przeglądarki i raporty Analytics

Globalna aktualizacja działa w bieżącym dokumencie. Pełna nawigacja wymaga ponownego przekazania aktualnego stanu tożsamości; SPA wymaga aktualizacji po zmianie stanu konta. Wysłane żądania nie są przepisywane. Przykład raportowania Google wiąże wcześniejsze zdarzenia bez identyfikatora w tej samej sesji z późniejszym User ID, a po wylogowaniu kończy powiązanie kolejnych zdarzeń. Nie oznacza to gwarancji wstecznego przepisywania surowych eksportów ani danych historycznych sprzed implementacji.

Blended lub Observed uwzględniają User-ID w tożsamości raportowania; Device-based korzysta w raportach z tożsamości urządzenia. Zmiana ustawienia raportowego nie naprawia błędnie zebranego identyfikatora.

GTM i zmiany z października 2026

Informacje o wydaniu z 8 października opisują inicjalizację kontenera podczas ładowania i widoczne zdarzenia przetwarzania gtag.config. Takie zdarzenia mogą pasować do szerokich reguł Custom Event, ale nie dowodzą wysłania odsłony GA4. Opcjonalna optymalizacja wprowadzona 12 października wysyła pomiary Google bezpośrednio z GTM, bez dodatkowej biblioteki Google tag. Konfiguracja nadal zależy od sposobu instalacji.

Ustawienia GTM i bieżące zmienne należą do obsługiwanej konfiguracji kontenera. Drugi samodzielny skrypt ładujący wyłącznie do aktualizacji tożsamości grozi podwójną instalacją. Kontekst globalny może docierać do wielu Google tagów; instrukcja Google ogranicza tę opcję do danych niewrażliwych.

We własnych szablonach gtagSet zapewnia udokumentowaną kolejność w bieżącym kontenerze: po aktualnym zdarzeniu i uruchomionych tagach albo po upływie limitu przetwarzania, lecz przed oczekującymi elementami data layer. API wymaga prawa zapisu wskazanych kluczy. Nie oznacza to natychmiastowej zmiany już wykonywanych tagów ani obsługi każdego przypadku tożsamości. Nadal obowiązują reguły odbiorcy, zgoda i zakres tożsamości. Szablony zgody korzystają z setDefaultConsentState i updateConsentState.

Zgoda i odsłony SPA

Domyślne stany zgody w samodzielnym gtag.js muszą poprzedzać polecenia pomiarowe. Późniejsza aktualizacja powinna odzwierciedlać rzeczywisty wybór dla każdego typu zgody; logowanie nie oznacza zgody na wszystkie cele reklamowe. wait_for_update: 500 to ograniczone opóźnienie dla asynchronicznej obsługi zgody, a nie oczekiwanie aż do akceptacji. Basic Mode blokuje tagi Google do uzyskania zgody; Advanced Mode może wcześniej wysyłać ograniczone pingi bez cookies. CMP musi przechowywać i odtwarzać decyzję.

Świadomie sterowana ścieżka pomiaru SPA wysyła jeden page_view na zamierzoną zmianę trasy z aktualnymi parametrami strony i wyklucza konkurencyjny automatyczny pomiar historii. Pozostałe zdarzenia również wymagają poprawnego kontekstu strony. Powtarzanie config z update: true nie jest ogólnie udokumentowanym zamiennikiem.