Tożsamość raportowania w GA4: dlaczego liczby użytkowników się nie zgadzają

Raport pokazuje czterdzieści tysięcy użytkowników, a w CRM jest dwadzieścia pięć tysięcy kont. Nikt nie ruszał tagów, nikt nie zmieniał kontenera, a różnica rośnie z miesiąca na miesiąc. W GA4 to zwykle nie jest awaria zbierania danych, tylko skutek tego, jak usługa skleja zachowania w użytkowników.

GA4 ma trzy przestrzenie tożsamości: User-ID, identyfikator urządzenia i modelowanie. To, którą z nich wybierzesz do raportowania, decyduje o liczbie użytkowników, o przypisaniu kanałów i o tym, czy wiersz w raporcie w ogóle się pokaże.

Trzy przestrzenie tożsamości

Ta sama osoba rano przegląda ofertę na tablecie, w pracy wraca do niej na laptopie, a wieczorem kupuje z telefonu. Każde z tych wejść to osobna sesja, a bez wspólnego identyfikatora także osobny użytkownik.

User-ID to identyfikator, który tworzysz sam dla zalogowanej osoby. Jest najdokładniejszy, bo opiera się na danych, które zebrałeś, a nie na urządzeniu. W witrynie identyfikator urządzenia pochodzi z identyfikatora klienta, w aplikacji z identyfikatora instancji aplikacji. Modelowanie wchodzi tam, gdzie użytkownik odmówił zgody: Analytics szacuje jego zachowanie na podstawie podobnych użytkowników, którzy zgodę dali.

Trzy opcje w ustawieniach

Ścieżka to Administracja, sekcja Wyświetlanie danych, pozycja Tożsamość na potrzeby raportowania. Do wyboru są trzy warianty.

Mieszana sprawdza po kolei: User-ID, potem identyfikator urządzenia, a na końcu modelowanie. Jeśli użytkownik jest zalogowany, Analytics użyje Twojego identyfikatora. Jeśli go nie ma, sięgnie po identyfikator urządzenia. Jeśli brakuje obu, wchodzi modelowanie. Obserwowane kategorie to tylko User-ID i identyfikator urządzenia, bez danych szacowanych. Zależnie od urządzenia korzysta wyłącznie z identyfikatora urządzenia i ignoruje wszystkie pozostałe, także User-ID.

Jedno zdanie z dokumentacji warto zapamiętać: wybrana opcja nie ma wpływu na gromadzenie ani przetwarzanie danych. Przełączanie jej nie zmienia historii i nie wymaga ponownego wdrożenia. Zmienia tylko sposób, w jaki raporty liczą użytkowników.

Kto może zmienić ustawienie

Potrzebna jest rola Edytujący lub wyższa. Tu trafia się na niespójność w dokumentacji Google: strona o tożsamości raportowania mówi o poziomie konta, a strona o modelowaniu i strona o User-ID o poziomie usługi. Jeśli nadajesz uprawnienia od zera, nadaj je na poziomie konta, wtedy oba warianty są pokryte.

User-ID w praktyce

Identyfikator musi być unikalny dla każdego użytkownika i przypisany przy każdym wejściu, zwykle przy logowaniu. Limit to 256 znaków. Nie wkładaj tam danych osobowych. Adres e-mail, numer telefonu czy PESEL w polu User-ID to naruszenie warunków korzystania z usługi, a przy kontroli organu nadzorczego problem, którego nie da się cofnąć, bo dane zdążyły trafić do eksportu.

Skutki kolizji widać najlepiej na przykładzie z dokumentacji. Jan loguje się na laptopie, ogląda produkt A i dodaje go do koszyka. Maria loguje się na telefonie z tym samym identyfikatorem UserID123, ogląda produkt B i kupuje. W raporcie jest jeden użytkownik, który oglądał oba produkty i kupił raz. Wniosek o zainteresowaniach będzie błędny, bo dane dotyczą dwóch osób.

Pusty albo fikcyjny identyfikator wypada gorzej: wielokrotne ustawianie takiej wartości może trwale uszkodzić dane. Ciągi tekstowe "undefined" i "null" są interpretowane jak zwyczajne identyfikatory użytkownika. Po wylogowaniu jedyną dopuszczalną wartością jest null, nie pusty ciąg znaków. Zdarzenia wywołane przed zalogowaniem trafiają do identyfikatora po fakcie, w ramach tej samej sesji.

Modelowanie: cztery warunki naraz

Modelowanie behawioralne nie włącza się na życzenie. Google wymaga jednocześnie czterech rzeczy.

• Tryb uzyskiwania zgody włączony na wszystkich stronach witryny lub ekranach aplikacji.
• Implementacja zaawansowana, czyli tagi ładują się przed banerem i w każdym przypadku, nie tylko po zgodzie.
• Co najmniej 1000 zdarzeń dziennie z parametrem analytics_storage ustawionym na denied przez co najmniej 7 dni.
• Co najmniej 1000 użytkowników dziennie wysyłających zdarzenia z analytics_storage ustawionym na granted przez co najmniej 7 z ostatnich 28 dni.

Spełnienie progów nie gwarantuje modelu. Google sprawdza dodatkowo jakość, między innymi stosunek nowych użytkowników do powracających i liczbę sesji na użytkownika. Modelowanie włącza się samo, kiedy usługa spełnia warunki. W rzadkich przypadkach, gdy przestaje je spełniać, dane szacowane znikają, a po powrocie do progów wracają dopiero od dnia, w którym warunek został osiągnięty ponownie. Dlatego raport z tego samego zakresu dat potrafi zmienić się bez żadnej zmiany w kodzie.

Czego modelowanie nie obejmuje

Lista jest krótka i tłumaczy większość pytań o brakujące dane. Dane szacowane nie są używane w Odbiorcach, w eksploracjach kohorty, eksploratora zachowania użytkownika i cyklu życia użytkownika, w segmentach z sekwencją, w raportach retencji, w danych prognozowanych ani w eksporcie danych, na przykład w BigQuery Export.

Ostatni punkt jest najważniejszy w praktyce. Hurtownia nie dostanie wierszy szacowanych. Kto porównuje liczbę z interfejsu z liczbą z BigQuery, zobaczy różnicę wynikającą z modelowania, a nie z błędu potoku danych.

Progi danych chowają resztę

Ani User-ID, ani modelowanie nie usuwają progów danych. Raporty oparte na danych sygnałowych Google muszą ukryć część wyniku, gdy grupa jest zbyt mała. Wiersz z niewielką liczbą użytkowników pokaże się jako (other) albo zniknie, a suma w tabeli będzie mniejsza niż po podziale na wymiary.

Tego nie da się obejść ustawieniem tożsamości. Można tylko wiedzieć, że to nie jest błąd.

BigQuery i polskie RODO

Identyfikatory użytkowników są eksportowane do BigQuery niezależnie od stanu zgody użytkowników. To zdanie z dokumentacji User-ID dotyczy eksportu, o którym często zapomina dział marketingu, i warto je przeczytać dwa razy przed włączeniem funkcji.

Po polsku dochodzą dwie warstwy. Przechowywanie identyfikatorów i odczytywanie informacji z urządzenia regulują art. 399 i 400 Prawa komunikacji elektronicznej, a przetwarzanie danych w RODO art. 6 ust. 1. Podstawa prawna, informacja w polityce prywatności i zakres danych w eksporcie muszą się zgadzać, zanim User-ID zostanie wdrożony.

Jak sprawdzić, że to działa

Pierwszy dowód jest w wymiarze Zalogowano za pomocą identyfikatora użytkownika. Pozwala on porównać zachowanie osób zalogowanych i anonimowych w tym samym raporcie, bez budowania osobnego strumienia danych.

Drugi to ikona jakości danych obok tabeli. Po kliknięciu widać, czy raport zawiera dane modelowane, czy tylko obserwowane. Jeśli ikona milczy o modelowaniu, a oczekujesz danych szacowanych, problem jest w warunkach wstępnych, nie w ustawieniu tożsamości.

Trzeci to eksport. W BigQuery identyfikator leży w kolumnie user_id, obok user_pseudo_id, który powstaje niezależnie od logowania. Kto szuka w hurtowni tylko pseudoidentyfikatora, dojdzie do wniosku, że User-ID nie działa, choć dane są w sąsiedniej kolumnie.

Czwarty to porównanie przed i po. Przełączenie opcji nie zmienia historii, więc ten sam zakres dat policzony po zmianie pokaże inną liczbę użytkowników przy tych samych zdarzeniach. To jest oczekiwany efekt, a nie rozjazd danych.

Kolejność wdrożenia

• Ustal, czy User-ID jest w ogóle potrzebny. Jeśli użytkownicy się nie logują, nie ma czego wysyłać.
• Wysyłaj identyfikator przy każdym wejściu, nie tylko przy pierwszym logowaniu.
• Po wylogowaniu ustawiaj null, nigdy pusty ciąg znaków ani wartość tymczasową.
• Sprawdź, czy w sekcji Wyświetlanie danych wybrana jest Mieszana, jeśli chcesz korzystać z danych szacowanych.
• Zweryfikuj implementację zaawansowaną, bo bez niej modelowanie nie ruszy.
• Osobno sprawdź, co realnie trafia do BigQuery i czy zakres danych zgadza się z polityką prywatności.