Boty w danych GA4: co Google filtruje, a czego nie zatrzyma

Otwórz kanał Direct na stronie, której nikt nie sprawdzał od miesiąca, i znajdź skok. Kilka tysięcy sesji z jednego miasta, po jednym zdarzeniu, bez zdarzeń kluczowych i ze współczynnikiem odrzuceń pod sufitem. Pierwszy odruch to błąd pomiaru. Drugi to zdanie, że Google Analytics usuwa ruch botów, więc boty nie mogą być przyczyną.

To zdanie jest prawdziwe tylko w połowie, a niewiedza o drugiej połowie ma cenę. GA4 filtruje automatycznie i tego nie wyłączysz. Nie pokaże też, ile ruchu odrzucił. Usługa wyrzuca to, co rozpoznaje, milczy o skali i zostawia resztę w raportach.

Co GA4 usuwa i dlaczego nie zobaczysz liczby

Wykluczanie ruchu znanych robotów działa w każdej usłudze. Dokumentacja Google jest tu krótka i wyjątkowo konkretna: ruch generowany przez znane roboty jest wykluczany automatycznie, nie możesz tego wyłączyć ani sprawdzić, ile takiego ruchu zostało pominięte. Nie ma pola do zaznaczenia, raportu do otwarcia ani sumy, którą porównasz z logami serwera.

Rozpoznawanie opiera się na badaniach Google i liście Spider and Bot List prowadzonej przez Interactive Advertising Bureau. Wpisany na nią user agent jest odrzucany, zanim ruch dotrze do raportów. Traktuj efekt jak dolny limit, nie jak pomiar.

Analizy firm zewnętrznych mówią to samo i warto je podać z nazwą. Opticks Security pisze w 2026 roku, że filtr nie wyłapuje ruchu naśladującego ludzi, rotującego adresy IP ani przechodzącego przez proxy rezydencjalne. Brytyjski przewodnik Priority Pixels dodaje szczegół istotny dla agencji: lista obejmuje roboty wyszukiwarek, narzędzia SEO, podglądy linków w mediach społecznościowych i duże monitory dostępności, a poza nią zostają przeglądarki headless z normalnym user agentem Chrome oraz farmy scrapujące przez proxy rezydencjalne.

Gdzie filtr się kończy

Cztery kategorie ruchu przechodzą obok wbudowanego filtra i zachowują się na tyle różnie, że warto je rozdzielić.

Fałszowanie user agenta. Filtr czyta ciąg user agenta. Bot, który podaje zwykły ciąg Chrome, nie jest na liście, więc nic się z nim nie dzieje.

Przeglądarki headless. Skrypty Playwright, Puppeteer i Selenium domyślnie się ujawniają, a wystarczy jedna linia konfiguracji, żeby przestały. Automatyczne testy na produkcji, usługi zrzutów ekranu i scrapery cen wchodzą wtedy wyglądając jak ludzie.

Roboty renderujące JavaScript. Twoje tagi to skrypty, więc robot pobierający sam HTML nic nie wywołuje i nigdy nie pojawi się w GA4. Problemem jest ten, który wykonuje strony poprawnie, bo odpala każdy tag na trasie, którą przejdzie.

Oszustwa klikowe w kampaniach płatnych. To osobny problem budżetowy, który ląduje w tych samych raportach. Google Ads filtruje nieprawidłowe kliknięcia przed rozliczeniem i pokazuje odfiltrowaną liczbę w kolumnie Nieprawidłowe kliknięcia. Za kliknięcia uznane za nieprawidłowe nie płacisz, a gdy podejrzewasz, że coś przeszło, zgłaszasz sprawę formularzem Click Quality.

Jak rozpoznać ruch, który przeszedł

Żaden pojedynczy wymiar nie mówi wprost, że to bot. Mówi o tym dopiero kombinacja, a wzorce się powtarzają.

Zacznij od zaangażowania. Sesja z jednym zdarzeniem, bez zdarzeń kluczowych i z niemal zerowym czasem zaangażowania to albo błędny tag, albo maszyna, a skupisko takich sesji z jednej lokalizacji rozstrzyga sprawę.

Potem sprawdź miasto i kraj. Regiony centrów danych oraz jedno miasto z wolumenem, którego nie wyjaśnia żadna kampania, to typowy podpis.

Dalej strony wejścia. Gdy jeden adres wchłania tysiące sesji, a reszta witryny stoi płasko, robot albo scraper znalazł coś, co lubi: stronę wyników, feed, wpis z mapy strony albo listę produktów, którą da się przejść.

Pomaga też rytm. Popyt ludzki ma kształt dnia pracy z nachyleniem wieczorem. Ruch botów przychodzi seriami, o dziwnych godzinach albo jako płaska linia ciągnąca się tygodniami. Zanim cokolwiek wyciągniesz, porównaj GA4 z logami serwera lub CDN, bo oba liczą inaczej, a sama różnica jest informacją. Jeśli ruch przychodzi z nazwy hosta, która nie powinna w ogóle mierzyć, na przykład z domeny testowej, starej subdomeny albo adresu podglądu, temat filtrów nazwy hosta opisaliśmy osobno.

Trzy filtry, które masz pod kontrolą

Google daje trzy typy filtrów danych: ruch generowany przez dewelopera, ruch wewnętrzny i ruch w sieci z daną nazwą hosta. Dwa pierwsze to praktyczna odpowiedź na zanieczyszczenie własnych raportów.

Filtry danych stosują się od momentu utworzenia i nie działają na dane historyczne. Efekt jest nieodwracalny: wykluczone dane nie zostaną nigdy przetworzone, więc nie będzie ich ani w Google Analytics, ani w BigQuery. Jeśli chcesz tylko ukryć dane w części raportów, użyj filtrów raportów, bo one są odwracalne. W usłudze możesz utworzyć maksymalnie dziesięć filtrów danych, a do pracy potrzebujesz roli Edytor lub wyższej.

Ruch wewnętrzny w dwóch krokach

Krok pierwszy jest tym, który wszyscy pomijają. W Administracji w sekcji Zbieranie i modyfikowanie danych otwórz Strumienie danych, wejdź w strumień internetowy, kliknij Konfiguruj ustawienia tagu, potem Pokaż więcej i Zdefiniuj ruch wewnętrzny. Reguła dodaje do każdego zdarzenia parametr traffic_type, jedyny parametr, któremu na tym ekranie ustawisz wartość. Domyślnie jest to internal, ale możesz wpisać własną etykietę, na przykład nazwę biura.

Adres dopasujesz jednym z sześciu operatorów: równa się, zaczyna się od, kończy się na, zawiera, mieści się w zakresie w notacji CIDR albo wyrażenie regularne. IPv4 i IPv6 działają tak samo, a link obok podpowiada twój aktualny adres publiczny. Kilka warunków łączy się operatorem LUB, nie ORAZ, więc jedna reguła może objąć kilka biur. Ruchu użytkowników aplikacji tą drogą nie odfiltrujesz.

Krok drugi tworzy filtr, który działa na parametrze. W Administracji otwórz Filtry danych, kliknij Utwórz filtr, wybierz Ruch wewnętrzny, nadaj nazwę i ustaw stan Wyklucz. Nazwa musi być unikalna w usłudze, zaczynać się od litery i zmieścić się w czterdziestu znakach. Filtr danych może zacząć działać dopiero po 24 do 36 godzinach.

Czego filtr nie zrobi

Nie cofnie się. Wykluczone dane przepadają, więc źle wpisany zakres adresów kosztuje prawdziwy ruch, którego nie odzyskasz. Przed zapisaniem filtra sprawdź zakres i porównaj sumy z dniem wcześniej.

Nie obejmie aplikacji ani nie pokaże, ile ruchu odrzuciły filtry Google. Do domen testowych i podglądów użyj osobnego filtra nazwy hosta, zamiast liczyć na to, że roboty znikną same.

Nie zastąpi też porządku w zgodach. Ruch bez zapisanego źródła zostaje w danych oznaczony jako (direct) / (none), a sesje bez zgody analitycznej zostawiają tę samą lukę. W polskim porządku prawnym zapis w urządzeniu reguluje art. 399 PKE, a standard zgody wyznacza RODO przez art. 400 PKE. Bot i brak zgody wyglądają w raporcie podobnie, choć to dwie różne naprawy.

Co zrobić w tym tygodniu

Sprawdź, czy skok w Direct to skupisko sesji z jednym zdarzeniem, z jednej lokalizacji i z jednej strony wejścia. Jeśli tak, postaw filtr ruchu wewnętrznego i osobny filtr dla każdej nazwy hosta, która nie powinna mierzyć. Zapisz zakresy adresów na jednej stronie razem z datą dodania, bo za pół roku nikt nie odtworzy, skąd wzięła się reguła.

Na koniec porównaj GA4 z logami serwera w tym samym okresie. Różnica między tym, co widzi twoja infrastruktura, a tym, co przyjmuje Analytics, jest jedynym uczciwym punktem wyjścia, bo wbudowany filtr nie poda ci liczby.