Raport w GA4 pokazuje 42 000 sesji, ale kiedy zsumujesz wiersze w tabeli, wychodzi 38 500. Ten sam kanał w eksploracji ma jeszcze inną liczbę, a połowa źródeł ruchu schowała się pod jednym wierszem „(other)”. To nie jest błąd wdrożenia ani zepsuty tag. Za rozbieżnościami niemal zawsze stoi jeden z trzech mechanizmów, które Google celowo wbudował w platformę: próbkowanie, limit liczności wymiarów i progi prywatności.
Każdy z nich działa inaczej i wymaga innego obejścia. Poniżej pokazujemy, po czym je rozpoznać w interfejsie i kiedy różnica jest realnym problemem.
Sampling: kiedy się włącza i jak go rozpoznać
Sampling, czyli próbkowanie, oznacza, że GA4 nie policzył wszystkich zdarzeń, tylko ich podzbiór, a wynik przemnożył, żeby oszacować całość. Kluczowa rzecz, o której wiele osób zapomina: standardowe raporty w GA4 nie są próbkowane. Są budowane z tabel zagregowanych wcześniej, więc liczba, którą tam widzisz, jest liczbą pełną (choć, jak zobaczysz w kolejnej sekcji, może być zwinięta do wiersza zbiorczego).
Próbkowanie pojawia się dopiero tam, gdzie GA4 musi policzyć coś na żywo, czyli w eksploracjach i w zapytaniach do Data API z niestandardową kombinacją wymiarów. W usłudze standardowej limit to około 10 milionów zdarzeń na zapytanie. Jeśli wybrany zakres dat i filtry obejmują więcej, silnik bierze próbkę. W Analytics 360 ten próg jest o kilka rzędów wielkości wyższy, dlatego zespoły na wersji płatnej rzadko widzą ten problem.
Gdzie to sprawdzić
W prawym górnym rogu eksploracji znajduje się ikona jakości danych. Zielony znacznik oznacza, że raport powstał ze 100% dostępnych danych. Żółta lub pomarańczowa ikona sygnalizuje próbkowanie, a po najechaniu kursorem zobaczysz konkretny procent, na przykład „ten raport bazuje na 34% dostępnych danych”. To jedyny wiarygodny wskaźnik, bo sama liczba w tabeli niczego nie zdradza.
Im niższy procent, tym mniej wiarygodne są małe wartości. Przy próbce 30% kanał z 2 000 sesji nadal będzie oszacowany rozsądnie, ale segment z 12 konwersjami może mieć ich w rzeczywistości 4 albo 25. Decyzji budżetowych nie podejmuj więc na próbkowanym długim ogonie.
Cardinality i wiersz „(other)” w raportach
Cardinality, czyli liczność, to liczba unikalnych wartości, jakie przyjmuje dany wymiar. Ścieżka strony na blogu z 300 wpisami ma niską liczność. Ta sama ścieżka z doklejonymi parametrami UTM, identyfikatorami sesji i filtrami produktowymi potrafi mieć setki tysięcy unikalnych wartości dziennie. I wtedy zaczynają się schody.
GA4 buduje dzienne tabele zagregowane o ograniczonej liczbie wierszy (w usłudze standardowej mówi się o rzędzie 500 000 wierszy na tabelę dziennie). Kiedy kombinacja wymiarów przekroczy ten limit, najrzadsze wartości zostają zsumowane w jeden wiersz o nazwie (other). Dane nie znikają, sumy zbiorcze pozostają poprawne, ale tracisz możliwość rozbicia ich na szczegóły. I ten proces jest nieodwracalny: raz zwiniętego wiersza nie da się rozpakować, nawet jeśli później zawęzisz zakres dat.
Typowi winowajcy wysokiej liczności
- Adresy stron z parametrami zapytań, które nie zostały wykluczone w ustawieniach usługi.
- Identyfikatory transakcji, użytkownika lub sesji wysyłane jako wymiar niestandardowy o zakresie zdarzenia.
- Pełne treści zapytań z wyszukiwarki wewnętrznej sklepu.
- Niestandardowe wymiary zawierające znaczniki czasu albo losowe identyfikatory testów A/B.
- Źródła i medium generowane dynamicznie, na przykład przez narzędzia do skracania linków.
Warto też pamiętać, że rozpoznawanie nowych źródeł ruchu potrafi rozsadzić ten wymiar, zwłaszcza gdy ręcznie wydzielasz odwiedziny z asystentów AI. Jeśli budujesz taką segmentację, zrób to na czystych regułach, a nie na surowych wartościach referrera, bo inaczej sam zwiększysz liczność wymiaru. Opisaliśmy to szerzej w tekście o tym, jak poprawnie wyodrębnić ruch z ChatGPT w GA4.
Thresholding, czyli progi prywatności
Trzeci mechanizm jest inny w naturze niż dwa poprzednie: nie chodzi w nim o wydajność, tylko o ochronę tożsamości użytkowników. Kiedy raport zawiera dane, które przy małej liczbie osób mogłyby pozwolić na identyfikację konkretnego użytkownika, GA4 po prostu ukrywa te wiersze. Nie oznacza ich, nie sumuje w osobnej kategorii, tylko usuwa z widoku.
Progi włączają się przede wszystkim wtedy, gdy w usłudze aktywne są sygnały Google (Google Signals), a raport dotyka danych demograficznych, zainteresowań lub tożsamości opartej na zalogowanym koncie. Google świadomie nie publikuje dokładnych wartości progowych, żeby nie dało się ich obejść przez odwrotną inżynierię. Wiadomo natomiast, że mechanizm reaguje na małe liczebności, więc im węższy segment i krótszy zakres dat, tym częściej coś zniknie.
Rozpoznasz to po ikonie w interfejsie z komunikatem o zastosowaniu progów oraz po charakterystycznym objawie: suma wierszy jest wyraźnie mniejsza od wartości całkowitej, a brakuje głównie małych, niszowych pozycji. Najprostsze obejście polega na zmianie tożsamości raportowania na opartą wyłącznie na urządzeniu, co dla wielu raportów wyłącza progi kosztem utraty danych demograficznych i deduplikacji użytkowników między urządzeniami.
Jak te trzy mechanizmy się nakładają
Najbardziej mylące sytuacje powstają wtedy, gdy dwa albo trzy mechanizmy działają jednocześnie. Eksploracja na 60 dni w dużym sklepie potrafi być próbkowana, mieć zwinięte rzadkie ścieżki do wiersza zbiorczego i dodatkowo ukryte segmenty demograficzne. Trzy różne przyczyny, jeden efekt: liczby się nie zgadzają.
| Mechanizm | Gdzie występuje | Objaw | Odwracalny |
|---|---|---|---|
| Sampling | Eksploracje, Data API | Ikona jakości danych poniżej 100% | Tak, po zawężeniu zakresu |
| Cardinality | Raporty standardowe i eksploracje | Wiersz (other) z dużą wartością | Nie, dla danych już zebranych |
| Thresholding | Raporty z sygnałami Google | Brakujące wiersze, suma mniejsza od całości | Częściowo, po zmianie tożsamości raportowania |
Diagnozę prowadź w kolejności: najpierw ikona jakości danych (sampling), potem wiersz zbiorczy w tabeli (cardinality), na końcu porównanie sumy wierszy z wartością całkowitą (thresholding). Ta sekwencja rozstrzyga większość przypadków w dwie minuty i oszczędza godzin szukania błędu w tagach, którego tam nie ma.
Obejścia: eksploracje, BigQuery, zawężanie zakresu
Nie każdy z tych mechanizmów da się wyłączyć, ale każdy da się obejść lub przynajmniej ograniczyć.
- Skróć zakres dat. Najtańsze i najskuteczniejsze lekarstwo na sampling. Zamiast jednej eksploracji na kwartał zrób trzy miesięczne i zsumuj wyniki poza narzędziem.
- Ogranicz liczbę wymiarów w zapytaniu. Każdy dodatkowy wymiar mnoży liczbę możliwych kombinacji, więc szybciej dobijasz do limitów.
- Wyczyść parametry zapytań. W ustawieniach usługi wskaż parametry do wykluczenia z adresu strony. To działa wyłącznie na przyszłość, więc im wcześniej, tym lepiej.
- Przenieś identyfikatory do parametrów zdarzeń zamiast rejestrować je jako wymiary niestandardowe. Nie trafią wtedy do tabel zagregowanych i nie podbiją liczności.
- Włącz eksport do BigQuery. To jedyne pełne rozwiązanie: dane zdarzeniowe są surowe, bez próbkowania, bez wiersza zbiorczego i bez progów prywatności. Eksport warto włączyć nawet wtedy, gdy nie masz jeszcze pomysłu na zapytania, bo obejmuje wyłącznie dane od momentu konfiguracji.
Jeśli budujesz raportowanie poza interfejsem, ten sam problem czeka Cię po stronie Search Console, gdzie interfejs pokazuje ograniczony wycinek zapytań. Rozwiązanie jest analogiczne i opisaliśmy je w poradniku o tym, jak pobrać pełne dane o zapytaniach przez API. Kiedy oba źródła spinasz w jeden pipeline, warto od razu ustawić go zgodnie ze schematem z tekstu o łączeniu API GA4 i Search Console.
Kiedy różnice można zignorować
Nie każda rozbieżność wymaga śledztwa. Jeżeli raport ma jakość danych powyżej 90%, a Ty analizujesz trend albo udziały kanałów, próbkowanie nie zmieni wniosku. Wiersz zbiorczy obejmujący 2% ruchu też jest kosmetyczny, o ile nie szukasz akurat w nim konkretnej podstrony.
Reguła praktyczna jest prosta: te trzy mechanizmy psują szczegół, a nie skalę. Sumy zbiorcze i trendy pozostają wiarygodne. Uważaj dopiero wtedy, gdy podejmujesz decyzję na podstawie małej liczby zdarzeń, wąskiego segmentu albo długiego ogona wymiarów.
Osobna sprawa to rozbieżności między GA4 a innymi systemami, które z próbkowaniem nie mają nic wspólnego i wynikają z różnic w modelu atrybucji oraz oknach konwersji. Jeśli Twój problem polega na tym, że dwa narzędzia pokazują inną liczbę konwersji, zacznij od tekstu o tym, dlaczego GA4 pokazuje mniej konwersji niż Google Ads. Pełne definicje pojęć z tego obszaru znajdziesz też w naszym słowniku terminów technicznych. Szczegółową dokumentację limitów publikuje sam Google w centrum pomocy Analytics.
FAQ
Czy standardowe raporty GA4 są próbkowane?
Nie. Standardowe raporty korzystają z tabel zagregowanych i pokazują pełne dane. Próbkowanie dotyczy eksploracji oraz zapytań do Data API, gdy przekroczą limit zdarzeń (około 10 milionów w usłudze standardowej).
Czy da się usunąć wiersz „(other)” z raportu?
Nie dla danych już zebranych, bo agregacja jest nieodwracalna. Na przyszłość pomaga wykluczenie parametrów zapytań z adresu strony, ograniczenie wymiarów niestandardowych o wysokiej liczności i eksport do BigQuery, który nie stosuje tego limitu.
Jak wyłączyć progi prywatności w GA4?
Nie da się ich wyłączyć bezpośrednio. Zmiana tożsamości raportowania na opartą wyłącznie na urządzeniu usuwa progi z większości raportów, ale kosztem danych demograficznych i łączenia użytkowników między urządzeniami.
Który mechanizm odpowiada za moją rozbieżność?
Sprawdź w kolejności: ikona jakości danych poniżej 100% oznacza sampling, obecność wiersza zbiorczego wskazuje na liczność wymiarów, a suma wierszy mniejsza od wartości całkowitej przy aktywnych sygnałach Google sugeruje progi prywatności.
Czy BigQuery rozwiązuje wszystkie trzy problemy?
Tak, ponieważ eksport zawiera surowe dane zdarzeniowe bez próbkowania, agregacji i progów. Ma jednak dwa ograniczenia: obejmuje wyłącznie dane od momentu włączenia eksportu i wymaga pisania zapytań SQL zamiast klikania w interfejsie.