Panel pokazuje dane przetworzone, nie zdarzenia

Punkt wyjścia jest taki: interfejs GA4 nie liczy niczego od zera przy każdym otwarciu raportu. Sięga do wcześniej przygotowanych tabel zagregowanych, w których zdarzenia zostały już zsumowane wzdłuż konkretnych wymiarów. Dlatego raport otwiera się w sekundę, mimo że stoi za nim wiele milionów zdarzeń.

Ta agregacja ma cenę i to ona jest źródłem większości pytań, które dostaję. Po drodze GA4 obcina ogony rozkładów, przybliża część liczników i ukrywa dane, które mogłyby pozwolić zidentyfikować pojedynczą osobę. Eksport do BigQuery pomija cały ten etap i zapisuje zdarzenia w postaci, w jakiej dotarły do serwerów Google.

Warto od razu rozdzielić dwie rzeczy, które w rozmowach zlewają się w jedno. Raporty standardowe w GA4 nie są próbkowane — one są zagregowane, co jest zupełnie innym problemem. Próbkowanie dotyczy eksploracji i pojawia się dopiero przy dużych zapytaniach. Kiedy więc ktoś mówi „mam próbkowanie w GA4″, w większości przypadków po sprawdzeniu okazuje się, że ma kardynalność albo progi danych.

Próbkowanie: kiedy GA4 liczy na wycinku

Próbkowanie w GA4 działa tak, jak podpowiada nazwa. Zamiast przeliczyć wszystkie zdarzenia mieszczące się w zakresie zapytania, system bierze ich reprezentatywny podzbiór, liczy wynik na nim i skaluje go proporcjonalnie w górę.

Dla właściwości standardowej granicą jest 10 milionów zdarzeń na jedno zapytanie. Poniżej tej liczby eksploracja pracuje na pełnym zbiorze. Powyżej — na próbce. Właściwości 360 mają ten limit ustawiony znacznie wyżej, w skali miliarda zdarzeń, więc przy tych samych danych w wersji płatnej próbkowania po prostu nie zobaczysz.

GA4 nie ukrywa tego przed użytkownikiem. Przy tytule raportu i w prawym górnym rogu eksploracji jest wskaźnik jakości danych, a po jego rozwinięciu widać, na jakim odsetku zdarzeń oparto wynik. To pierwsza rzecz, którą sprawdzam, kiedy ktoś przysyła mi zrzut ekranu z pytaniem o dziwną liczbę.

Kluczowa konsekwencja: im rzadsze zjawisko, tym bardziej próbkowanie je przekłamuje. Sumaryczna liczba sesji na próbce wypada zwykle blisko prawdy, bo skalowanie działa na dużych liczbach. Ale lej z czterema krokami, w którym do ostatniego dochodzi wąska grupa, albo segment użytkowników z konkretnego miasta i konkretnego urządzenia to już liczby, przy których skalowanie potrafi rozjechać wynik w sposób trudny do przewidzenia. Najgorsze jest to, że wynik nadal wygląda wiarygodnie.

Najprostsze obejście nie wymaga BigQuery: skracam zakres dat, żeby zmieścić się pod limitem, i sprawdzam, czy wskaźnik wrócił do pełnych danych. Jeśli pytanie wymaga długiego okresu i jednocześnie precyzji, idę do tabel.

Kardynalność i wiersz „(inne)"

To mechanizm, który w praktyce spotykam najczęściej, a który z próbkowaniem nie ma nic wspólnego.

Każdy wymiar w tabelach zagregowanych ma ograniczoną liczbę wierszy. Kiedy wymiar przyjmuje w ciągu jednego dnia więcej niż 500 unikalnych wartości, GA4 uznaje go za wymiar o wysokiej kardynalności. Zatrzymuje wtedy najmocniejsze wiersze, a całą resztę zwija w jedną pozycję opisaną jako „(inne)”.

Wymiary, na których widzę to najczęściej, są dokładnie tymi, których używa się na co dzień:

• adres strony i tytuł strony — w sklepie z rozbudowaną filtracją każdy zestaw parametrów w adresie to osobna wartość, więc granicę przekracza się w jeden dzień;

• identyfikatory sesji i transakcji — unikalne z definicji, w raportach standardowych nie mają sensu i nie należy ich tam wciągać;

• parametry własne o dużej zmienności — fraza z wyszukiwarki wewnętrznej, identyfikator produktu, nazwa wariantu.

Skutek jest paskudny, bo asymetryczny. Suma na górze raportu zostaje prawidłowa, ale rozbicie na wymiar już nie — brakującej części nie da się odzyskać, bo ona nigdy nie została zapisana w tej tabeli osobno. Nie pomoże zmiana zakresu dat ani filtr, bo zwinięcie nastąpiło na etapie przetwarzania, a nie wyświetlania.

W BigQuery ten problem nie istnieje w ogóle. Jeden wiersz to jedno zdarzenie z pełną wartością parametru, więc rozbicie po adresie strony czy identyfikatorze produktu jest kwestią napisania zapytania. Kiedy klient pyta mnie, po co mu eksport, tłumaczę to właśnie na wierszu „(inne)” — to najbardziej dotykalny argument.

Progi danych: liczby, których GA4 nie pokaże

Trzeci mechanizm nie jest błędem ani uproszczeniem obliczeń. To ochrona prywatności i działa celowo.

Jeśli we właściwości włączone są sygnały Google, a raport dotyka danych demograficznych, zainteresowań albo bardzo wąskiego wycinka użytkowników, GA4 potrafi całkowicie ukryć wiersz, żeby nie dało się z niego wywnioskować, o kogo chodzi. Nie zobaczysz wtedy zera i nie zobaczysz komunikatu na środku ekranu — wiersz po prostu nie występuje, a suma raportu jest niższa niż powinna.

To najbardziej podstępna z rozbieżności, bo pojawia się i znika w zależności od doboru wymiarów. Ten sam okres, ten sam segment, dorzucona jedna kolumna z wiekiem — i liczba konwersji spada. Wskaźnik jakości danych to sygnalizuje, ale trzeba tam zajrzeć.

W tabelach BigQuery progów nie ma, bo eksport dostaje zdarzenia przed tym etapem. Jest natomiast druga strona medalu, o której trzeba wiedzieć: eksport nie zawiera danych z sygnałów Google. Wiek, płeć i zainteresowania, które w panelu widzisz właśnie dzięki nim, w tabelach nie występują. Podobnie nie ma tam danych modelowanych — jeśli witryna działa w trybie zgody i GA4 uzupełnia brakujące zachowania modelem, to uzupełnienie żyje wyłącznie w panelu. Surowe zdarzenia są surowe także w tym sensie, że nikt nie dołożył do nich tego, czego nie zmierzono.

Przybliżone liczniki użytkowników i sesji

Zostaje różnica najbardziej subtelna, która zwykle wychodzi na końcu, gdy wszystkie poprzednie już się wykluczy.

Liczby unikalnych użytkowników w GA4 są przybliżeniem, nie zliczeniem. Policzenie dokładnej liczby unikalnych identyfikatorów w wielomilionowym zbiorze jest kosztowne, dlatego Google używa algorytmu szacującego liczność zbioru z niewielkim, znanym błędem. Efekt widać przy dodawaniu: liczba użytkowników z siedmiu dni nie jest sumą siedmiu dni i nie musi się idealnie zgadzać z tym, co wyjdzie z tabel.

Do tego dochodzą definicje, które w BigQuery trzeba odtworzyć samodzielnie. Sesja w GA4 kończy się po trzydziestu minutach bezczynności, ma własne reguły przy zmianie źródła i przy przejściu przez północ. W tabelach dostajesz identyfikator sesji w parametrach zdarzenia i musisz zdecydować, czy liczysz sesje jako unikalne pary identyfikatora przeglądarki i sesji, czy jako liczbę zdarzeń rozpoczęcia sesji. Te dwie definicje dają różne wyniki, a żadna z nich nie jest z góry tą, którą pokazuje panel.

Podobnie z sesjami angażującymi, z przypisaniem konwersji do kanału i z użytkownikami aktywnymi. To wszystko są metryki policzone przez GA4 według reguł, których w eksporcie nie ma — są tylko składniki. Zanim ogłoszę, że panel kłamie, sprawdzam więc, czy nie porównuję dwóch różnych definicji tego samego słowa.

Której liczbie wierzyć i jak z tym pracować

Nie mam jednej odpowiedzi i nie sądzę, żeby była uczciwa. Mam podział zastosowań, który u mnie się sprawdza.

Do raportowania okresowego, porównań między miesiącami i pilnowania trendu wystarcza panel. Zagregowane liczby są spójne same ze sobą, a klient dostaje to samo, co widzi u siebie po zalogowaniu — to niedoceniana wartość, bo raport, którego nie da się odtworzyć w interfejsie, zawsze kończy się dyskusją o rzetelności.

Do wszystkiego, co wymaga rozbicia na wymiar o dużej liczbie wartości, do lejów na wąskich grupach i do rozliczeń, w których liczba ma być dokładna, idę do BigQuery. Przy okazji trzymam się jednej zasady: nie mieszam obu źródeł w jednym raporcie. Wykres z panelu obok wykresu z tabel, na tej samej stronie, z inną liczbą sesji, to najkrótsza droga do utraty zaufania do całego zestawienia.

Trzecia rzecz, praktyczna. Kiedy różnica jest duża i nie wiem, skąd się bierze, przechodzę tę listę po kolei: najpierw wskaźnik jakości danych i próbkowanie, potem wiersz „(inne)” w rozbiciu, potem progi danych i sygnały Google, na końcu definicje metryk. W tej kolejności, bo tak układa się częstotliwość przypadków, które widzę na kontach. Prawie zawsze zatrzymuję się przed ostatnim punktem — i prawie nigdy winą nie okazuje się eksport.

Ostatnia uwaga, może najważniejsza. Żaden z tych mechanizmów nie jest usterką do naprawienia. Wszystkie są świadomymi decyzjami projektowymi: szybkość interfejsu, ochrona prywatności, koszt obliczeń. Rozumienie ich to nie ciekawostka techniczna, a warunek sensownego mówienia o danych. Zdanie „GA4 pokazuje coś innego niż BigQuery” bez wskazania mechanizmu nie jest diagnozą, tylko opisem samopoczucia.