user_id (ang. User-ID) to własny, trwały identyfikator zalogowanego użytkownika (np. zaszyfrowany numer klienta z CRM), który serwis przekazuje do Google Analytics 4 razem ze zdarzeniami, aby GA4 mogło połączyć sesje z różnych urządzeń i przeglądarek w jednego użytkownika. Dla marketera to podstawa wiarygodnego liczenia użytkowników i ścieżek konwersji w sytuacji, gdy klient zaczyna zakupy na telefonie, a kończy na laptopie. Bez user_id GA4 widzi dwie „osoby”, z user_id — jedną.
Jak działa user_id w GA4?
Domyślnie GA4 rozpoznaje użytkownika po identyfikatorze urządzenia: w sieci jest to client_id zapisany w pliku cookie, w aplikacji — app_instance_id. Ten identyfikator ginie po zmianie przeglądarki lub wyczyszczeniu cookies. user_id jest niezależny od urządzenia, bo pochodzi z Twojego systemu — nadajesz go w momencie logowania i wysyłasz z każdym zdarzeniem, dopóki użytkownik jest zidentyfikowany.
O tym, jak GA4 wykorzysta user_id w raportach, decyduje ustawienie Tożsamość na potrzeby raportowania (Administracja → Wyświetlanie danych). W trybie „Mieszana” i „Obserwowana” user_id jest źródłem o najwyższym priorytecie, przed Google Signals i identyfikatorem urządzenia. W trybie „Na podstawie urządzenia” user_id jest ignorowany w raportach, ale nadal zapisuje się w eksporcie do BigQuery.
| Identyfikator | Źródło | Łączy urządzenia? | Wymaga logowania? |
|---|---|---|---|
| client_id / app_instance_id | cookie lub instancja aplikacji (GA4) | nie | nie |
| Google Signals | zalogowane konto Google użytkownika | tak, tylko z aktywną personalizacją reklam | nie (po stronie serwisu) |
| user_id | system serwisu (CRM, baza kont) | tak, na wszystkich urządzeniach | tak |
Jak wdrożyć user_id?
- Wybierz identyfikator: stabilny, unikalny, niebędący daną osobową w jawnej postaci. Google zabrania przekazywania PII (adresu e-mail, imienia, numeru telefonu), dlatego najczęściej używa się wewnętrznego ID klienta lub jego hasha. Limit długości to 256 znaków.
- Po zalogowaniu wypchnij wartość do warstwy danych (dataLayer), np. jako
user_id. Zrób to na każdej stronie, na której użytkownik jest zalogowany — nie tylko na stronie logowania. - W Google Tag Managerze utwórz zmienną warstwy danych i podaj ją w polu User ID tagu konfiguracji Google (lub w konfiguracji gtag). Dzięki temu identyfikator trafi z każdym zdarzeniem, także page_view.
- Ustaw Tożsamość na potrzeby raportowania na „Mieszana” lub „Obserwowana”.
- Sprawdź w DebugView, czy zdarzenia zawierają user_id, i skontroluj zgodność wdrożenia z RODO — identyfikator użytkownika to dane osobowe w rozumieniu przepisów, więc jego przekazywanie powinno być objęte zgodą i opisane w polityce prywatności.
Szczegóły techniczne opisuje dokumentacja Google Analytics.
Kiedy warto, a kiedy nie?
user_id ma sens wszędzie tam, gdzie znacząca część ruchu jest zalogowana: e-commerce z kontami klientów, aplikacje SaaS, bankowość, portale subskrypcyjne, serwisy z programem lojalnościowym. Dodatkową korzyścią jest możliwość importu konwersji offline (np. podpisana umowa, odbiór zamówienia w sklepie) przez Measurement Protocol — wystarczy, że zdarzenie offline zawiera ten sam user_id.
Nie ma sensu wdrażać user_id w serwisie bez logowania — GA4 nie ma wtedy skąd wziąć identyfikatora. Nie należy też sztucznie „udawać” user_id, wpisując tam client_id: nic to nie zmienia w łączeniu urządzeń, a komplikuje wdrożenie.
Najczęstsze błędy
- Wysyłanie user_id tylko przy zdarzeniu login — kolejne zdarzenia idą już bez identyfikatora i nie łączą się z użytkownikiem.
- Przekazywanie e-maila lub numeru telefonu w jawnej postaci — naruszenie warunków Google i ryzyko wobec RODO.
- Zmienny identyfikator (np. token sesji) — każde logowanie tworzy w GA4 nowego użytkownika.
- Różne formaty w sieci i aplikacji (np. liczba vs. string z prefiksem) — dane z web i app nie łączą się.
- Pozostawienie tożsamości raportowania na „Na podstawie urządzenia” i zdziwienie, że liczba użytkowników się nie zmieniła.
user_id w praktyce ICBM
W audytach GA4 najczęściej spotykamy wdrożenia, w których user_id jest technicznie ustawiony, ale pojawia się tylko na części zdarzeń albo różni się między platformami. Dlatego podczas wdrożenia GA4 zaczynamy od mapy stanów użytkownika (niezalogowany, zalogowany, wylogowany), projektujemy warstwę danych tak, by identyfikator był dostępny na każdej stronie, a na koniec weryfikujemy w BigQuery, jaki odsetek zdarzeń faktycznie ma wypełnione pole user_id. To prosta metryka jakości, która mówi więcej niż sam fakt „mamy User-ID”.
Najczęściej zadawane pytania
Czy user_id może być adresem e-mail?
Nie. Warunki korzystania z Google Analytics zabraniają wysyłania danych umożliwiających bezpośrednią identyfikację osoby, a e-mail do nich należy. Użyj wewnętrznego ID klienta albo jego zaszyfrowanej (hashowanej) wersji.
Czy user_id łączy zdarzenia sprzed zalogowania?
Zdarzenia wysłane bez user_id są przypisane wyłącznie do identyfikatora urządzenia i nie należy zakładać, że GA4 połączy je wstecz z użytkownikiem. Dlatego identyfikator warto ustawiać najwcześniej, jak to możliwe — od pierwszego zdarzenia po zalogowaniu.
Czy user_id wystarczy do importu konwersji offline?
Tak — Measurement Protocol pozwala wysłać zdarzenie z user_id, a GA4 przypisze je do właściwego użytkownika, o ile identyfikator jest identyczny z tym używanym w serwisie. Trzeba jednak pamiętać o ograniczeniach protokołu, np. braku pełnej atrybucji do źródła ruchu dla zdarzeń bez client_id.
