Client ID i Session ID w GTM: zmienne wbudowane zamiast parsowania cookies

6 października 2026 · 7 min czytania

Zapytaj trzech analityków, jak wyciągnąć client ID z GA4 do Google Tag Managera, a dostaniesz trzy różne zmienne JavaScript. Każda parsuje jakiś plik cookie i składa wartość, której Google nigdy nie obiecał trzymać w takim kształcie. Gdy format się zmienił, zmienne nadal coś zwracały. Tylko nie to, co trzeba.

11 grudnia 2025 Google udostępnił wspieraną ścieżkę: trzy zmienne wbudowane w kategorii Utilities (Analytics Client ID, Analytics Session ID, Analytics Session Number) oraz typ zmiennej Analytics Storage dla kontenerów, które potrzebują konkretnego identyfikatora pomiaru albo własnego prefiksu pliku cookie.

Co zwracają trzy zmienne wbudowane

Brzmienie dokumentacji ma znaczenie, bo trzy zmienne nie są symetryczne. Analytics Client ID zwraca identyfikator klienta z domyślnego pliku cookie identyfikatora klienta, czyli z pliku _ga przy standardowym wdrożeniu. Analytics Session ID zwraca identyfikatory sesji ze wszystkich domyślnie prefiksowanych plików cookie sesji Google Analytics. Analytics Session Number zwraca z tych samych plików cookie numery sesji.

Przeczytaj definicję sesji jeszcze raz. Jeśli w przeglądarce jest więcej niż jeden plik cookie sesji, zmienna zwraca wartość tekstową ze wszystkimi istotnymi identyfikatorami naraz. Nie ten, który chciałeś. Wszystkie, sklejone w jedną wartość.

Dwa pliki cookie sesji zdarzają się częściej, niż się zakłada: tag Google obok cookie zarządzanego przez kontener, dwie usługi GA4 na jednej domenie albo stary plik cookie po migracji. Wtedy zmienna oddaje wartość złożoną, a taka wartość nie łączy się czysto z niczym po stronie odbiorcy.

Włączenie zajmuje minutę

Wejdź w Zmienne, potem Konfiguruj obok pola Zmienne wbudowane, następnie kategoria Utilities. Client ID, Session ID i Session Number stoją tam razem z Container ID, Event Name i Random Number. Zaznaczasz pola i tyle. Bez kodu i bez parsowania do utrzymania.

Interfejs nie powie ci, które własne zmienne JavaScript robiły tę samą robotę. Każda jest teraz duplikatem, a żadna nie zawiedzie, gdy Google znowu zmieni format. Zanim je usuniesz, sprawdź, które tagi je czytają: zmienna zasilająca tag debugowania może zniknąć, zmienna podająca wartość do konwersji offline wymaga podmiany.

Jak wyglądała stara, ręczna zmienna

Wzorzec dla client ID był łagodniejszy. Dopasowywał plik cookie i wyciągał parę liczb:

function () {
  var match = document.cookie.match(/_ga=GA\d\.\d\.(\d+\.\d+)/);
  return match ? match[1] : undefined;
}

Działa, dopóki Google nie doda segmentu do pliku cookie. Wtedy dostajesz pusty tekst przy każdym trafieniu i żaden błąd się nie pojawia. Z identyfikatorami sesji było gorzej, bo nazwa pliku cookie sesji zawiera identyfikator pomiaru, więc kontener z dwiema usługami potrzebował tabeli wyszukiwania i notatki dla następnej osoby.

Kiedy wartość wbudowana nie wystarcza

Typ Analytics Storage istnieje dla kontenerów, gdzie jedna wartość musi odpowiadać jednej usłudze. Daje trzy pola danych i dwie opcjonalne pozycje w sekcji More Settings.

Pole danych Identyfikator pomiaru Prefiks cookie Co zwraca
Client ID Nie dotyczy Opcjonalny Pseudonimowy identyfikator przeglądarki i urządzenia, filtrowany do jednego prefiksu cookie po ustawieniu.
Session ID Opcjonalny Opcjonalny Z identyfikatorem pomiaru pojedynczy identyfikator sesji dla tej usługi. Bez niego złożony łańcuch identyfikatorów ze wszystkich istotnych plików cookie sesji.
Session Number Opcjonalny Opcjonalny To samo zachowanie. Pojedynczy numer sesji przy ustawionym identyfikatorze pomiaru, złożony łańcuch bez niego.

Dla kontenera z jedną usługą wystarczą zmienne wbudowane. Dla kontenera agencji pole identyfikatora pomiaru decyduje o tym, czy dostajesz wartość nadającą się do połączenia, czy wartość do parsowania. Wkładanie wartości złożonej z powrotem do własnej zmiennej JavaScript mija się z celem.

Prefiks cookie obsługuje pliki cookie o zmienionej nazwie: w tagowaniu server-side, w niektórych menedżerach zgody i na stronach po migracji. Zostaw pole puste na stronie, która go potrzebuje, a zmienna zwróci pustą wartość, tag nadal odpali, a parametr dojedzie pusty.

Zgoda rozstrzyga, czy wartość w ogóle istnieje

Każda z tych zmiennych czyta plik cookie. W trybie Consent Mode v2 z odmową dla składowania analitycznego Google Analytics tych plików nie zapisuje, więc nie ma czego czytać. Zmienna zwraca pustą wartość, a tag, który miał scalić zdarzenie server-side z sesją w przeglądarce, nie wysyła niczego do scalenia.

Z tego wynika kolejność działań widoczna w danych, a nie w podglądzie. Tag odpalający na zdarzeniu gtm.js czyta plik cookie, zanim baner zgody zdążył cokolwiek rozstrzygnąć, więc zbiera puste wartości dla osób, które zgodę dadzą za chwilę. Przy drugim trafieniu ten sam użytkownik ma już identyfikator i łączy się poprawnie. Zostaje luka między liczbą odwiedzających, których sugeruje współczynnik zgody, a liczbą tych, których naprawdę potrafisz zmierzyć.

W praktyce te wartości czyta się tam, gdzie są potrzebne i gdzie decyzja o zgodzie została już zapisana: przy wysłaniu formularza, przy kroku zamówienia albo przy kliknięciu, które ma znaczenie.

Client ID to nie user ID

Client ID to pseudonimowy identyfikator przeglądarki i urządzenia. Zmienia się po wyczyszczeniu plików cookie, różni się między telefonem a laptopem tej samej osoby i nie ma związku z identyfikatorem kontaktu w CRM, dopóki sam go nie utworzysz. Identyfikator sesji zmienia się po przekroczeniu limitu czasu sesji, a numer sesji mówi, na którym miejscu w sekwencji wizyt stoi zdarzenie.

Wysłanie client ID do Google przez Measurement Protocol wiąże zdarzenie offline z pseudonimowym urządzeniem, a nie z osobą. W połączeniu z innymi informacjami w twoich systemach to dane osobowe w rozumieniu RODO, a podstawa prawna przetwarzania zdarzenia offline jest po twojej stronie. Odczyt pliku cookie nie jest zgodą i jej nie zastępuje.

Do czego używa się tego w praktyce

Import konwersji offline to najczystszy przypadek. Lead, który domyka się trzy tygodnie po wysłaniu formularza, musi dotrzeć do Google z client ID albo identyfikatorem transakcji, żeby Ads zaliczyło właściwą kampanię. Client ID trzeba przechwycić przy wysłaniu i zapisać obok leada. Wspierana zmienna zamiast parsowanego pliku cookie sprawia, że to przechwycenie przetrwa kolejną zmianę formatu.

Drugi przypadek to łączenie GA4 z CRM albo hurtownią danych. Client ID i identyfikator sesji są kluczami łączącymi dane z GA4 z systemem, który trzyma rekord leada: eksportem do BigQuery, CRM albo arkuszem prowadzonym ręcznie. Wartości złożone psują te połączenia bez błędu.

Co sprawdzić w kontenerze w tym tygodniu

  1. Sprawdź w Zmiennych, które z trzech zmiennych wbudowanych są włączone, i włącz brakujące.
  2. Przeszukaj kontener pod kątem własnych zmiennych JavaScript czytających _ga albo plik cookie sesji.
  3. Przy kilku usługach GA4 utwórz po jednej zmiennej Analytics Storage na usługę, z ustawionym identyfikatorem pomiaru.
  4. Przetestuj w podglądzie ze zgodą udzieloną i z odmową. Pusta wartość przy udzielonej zgodzie to błąd, zwykle brakujący prefiks cookie albo zbyt wczesny trigger.
  5. Zapisz, która zmienna zasila który tag.

Czego to nie naprawia

Wersja zamyka problem parsowania. Nie otwiera bramki zgody, nie zamienia client ID w osobę i nie łączy sesji między urządzeniami. Decyzja o tym, które identyfikatory wychodzą z przeglądarki i gdzie są przechowywane, należy do planu pomiaru, nie do kontenera.

Różnica jest w tym, że identyfikator pochodzi ze wspieranej zmiennej o udokumentowanym zachowaniu, więc pomyłka jest błędem konfiguracji, a nie przepisaniem od zera.

North Digital przegląda kontenery GTM pod kątem logiki identyfikatorów, bramki zgody i połączeń między GA4 a systemami, w których trzymasz leady. Dostajesz pisemną listę tego, co naprawić i ile to jest warte. Zamów przegląd pomiaru.