Filtry hostname w GA4: lista dozwolonych domen zamiast bloklisty

Referral spam w GA4 wygląda dziś inaczej niż kilka lat temu. Kiedyś wystarczyło dopisać kilka domen do listy wykluczeń i problem znikał. Teraz do usługi trafiają zdarzenia z hostname, których klient nigdy nie miał w planach, a lista wykluczeń rośnie razem z liczbą nowych źródeł. Każdy nowy adres to kolejna ręczna poprawka w panelu.

21 września 2026 Google dodało do filtrów danych tryb Include dla hostname. Zamiast wyliczać, co wyrzucić, wypisuje się domeny, którym wolno wysyłać zdarzenia do usługi. Wszystko poza listą jest odrzucane.

Co dokładnie ogłosiło Google

Nowy tryb działa w ramach istniejącego typu filtra Web hostname traffic, który pojawił się 11 czerwca 2026 razem ze zmianą Source Group i Source Platform. Wtedy dostępna była wyłącznie opcja Exclude, czyli odrzucanie zdarzeń z podanych domen. Google opisało to jako odrzucanie danych spoza zatwierdzonej domeny, co przy liście wykluczeń działa tylko wtedy, gdy lista jest kompletna.

Tryb Include odwraca kierunek. Usługa przyjmuje zdarzenia z domen wpisanych na listę i odrzuca pozostałe. Google nazywa to listą zatwierdzonych domen uprawnionych do wysyłania danych i zaznacza, że taka konfiguracja wymaga mniej pracy przy utrzymaniu, bo nowe źródło spamu nie wymaga dopisania kolejnego wykluczenia.

Mechanika filtrów danych zostaje bez zmian. Filtr działa od momentu utworzenia, nie obejmuje danych historycznych, a skutek jest trwały. Odrzucone zdarzenia nie są przetwarzane i nigdy nie pojawią się w raportach ani w eksporcie do BigQuery. Tego nie da się cofnąć zmianą ustawienia.

Dwie luki, o których trzeba wiedzieć

Pierwsza dotyczy Measurement Protocol. Google zapisało wprost, że filtry Include dla hostname nie są stosowane do zdarzeń wysyłanych przez Measurement Protocol. Ta ścieżka zostaje otwarta między innymi dla wdrożeń server-side GTM, które przekazują zdarzenia do GA4 przez Measurement Protocol i sekret API. Jeśli klient ma taką konfigurację, filtr nie zatrzyma ruchu przychodzącego tą drogą. Dotyczy to zarówno spamu, jak i zdarzeń, które wdrożenie wysyła celowo. Blokowanie po stronie serwera wymaga osobnego rozwiązania poza filtrem.

Druga luka siedzi w opisie pustego hostname. Google pisze, że filtr Include automatycznie blokuje zdarzenia bez hostname, podając w nawiasie ruch z gtag.js. Ten nawias da się czytać dwojako. W wąskim znaczeniu chodzi o żądania zbudowane jak odsłony gtag.js, którym brakuje nazwy hosta. W szerokim ruch z gtag.js jako klasa nie niesie hostname, a to opisuje większość zwykłej zbiórki na stronach. Google tego nie rozstrzyga, a dane odrzucone przez filtr nie wracają. Przy takim zapisie rozsądna kolejność to test na kopii albo w stanie testowym, nie wdrożenie na produkcji.

Dlaczego tryb Include zmienia charakter pracy

Lista wykluczeń wymaga reakcji na każdy nowy adres. Lista dozwolonych jest skończona, dopóki nie pojawi się nowa domena własna: nowy landing, nowy sklep, nowa wersja serwisu po migracji. Ta różnica brzmi jak wygoda, ale zmienia rozkład ryzyka. Przy wykluczeniach kosztem błędu są śmieci w raportach. Przy liście dozwolonych kosztem błędu jest utrata danych, których nie odzyska ani poprawka filtra, ani ponowne wgranie.

Druga konsekwencja jest organizacyjna. Filtr należy do usługi, nie do kontenera, więc nie widać go w GTM i nie widać go w kodzie strony. Osoba, która przejmuje konto po agencji, nie odkryje go przez przegląd tagów. Bez notatki w dokumentacji zostaje ustawieniem, którego po roku nikt nie potrafi wyjaśnić, a które tłumaczy różnice między GA4 a danymi z panelu reklamowego.

Trzy ograniczenia, które wyznaczają granice

Na usługę można utworzyć maksymalnie 10 filtrów danych. Liczą się wszystkie typy, więc filtr hostname konkuruje o miejsce z filtrem ruchu wewnętrznego i ruchem deweloperskim. Przy rozbudowanych wdrożeniach to realne ograniczenie, zwłaszcza gdy filtru wewnętrznego używa się osobno dla każdego biura firmy.

Do tworzenia, edycji i usuwania filtrów potrzebna jest rola Edytor na poziomie usługi. Analityk z rolą Wyświetlającego nie zajrzy nawet do listy filtrów, więc pracę musi wykonać ktoś z rolą Edytor.

Filtr ma trzy stany: Nieaktywny, Testowanie i Aktywny. W stanie testowania pasujące zdarzenia nie są usuwane, tylko oznaczone wymiarem o nazwie Test data filter name. Wymiar jest dostępny w eksploracjach, więc walidację prowadzi się tam, a nie w standardowych raportach. To jedyny moment, w którym błąd w liście domen nic nie kosztuje.

Dokumentacja filtrów danych na 23 września 2026 nadal opisuje typ Web hostname traffic wyłącznie jako filtr wykluczający, bez wzmianki o trybie Include. Google wypuściło funkcję przed aktualizacją opisu, więc przy wdrożeniu liczy się panel, a nie strona pomocy.

Audyt hostname przed włączeniem

Lista, którą wpisuje się do filtra, powinna powstać z danych, a nie z pamięci. Najprościej zebrać wartości wymiaru Hostname w eksploracji za ostatnie dwanaście miesięcy i porównać je z domenami, o których wie klient.

Adresy, które najczęściej nie trafiają na taką listę: wersja z www i bez www, gdy po migracji zbierają do jednej usługi, warianty krajowe domeny podpięte pod ten sam strumień, subdomeny marketingowe typu go, lp, promo i sklep, środowiska testowe oraz podglądy z adresami netlify.app i vercel.app, stary mikroserwis z ofertą pracy albo centrum pomocy na innej platformie oraz webview w aplikacji mobilnej z zupełnie innym hostname. Każdy z tych punktów to dane, które po włączeniu filtra przestaną docierać.

Kontekst RODO i rozmowa z klientem

Filtr hostname jest narzędziem jakości danych, a nie narzędziem zgodności. Nie zastępuje Consent Mode i nie zmienia tego, co dzieje się ze zdarzeniami wysyłanymi przy odmowie zgody. Porządkuje natomiast zakres pomiaru, co ma znaczenie w dokumentacji przetwarzania dla UODO. Jeśli w usłudze widnieją zdarzenia z domen, których administrator nigdy nie wskazał, opisanie zakresu zbierania danych w rejestrze czynności przestaje być proste.

W rozmowie z klientem warto zaznaczyć dwie rzeczy: trwałość ustawienia i brak wpływu na dane historyczne, więc filtr nie wyczyści śmieci z poprzednich miesięcy, oraz brak ścieżki odwrotu dla zdarzeń już odrzuconych. Z tego powodu filtr uruchamia się po okresie testowania i po spisaniu listy domen, a nie jako szybka poprawka tuż przed raportem kwartalnym.

Lista kontrolna

1. Zbierz wymiar Hostname z eksploracji za ostatnie dwanaście miesięcy i wypisz wszystkie wartości razem z liczbą zdarzeń.
2. Zweryfikuj każdą wartość z klientem: czy to jego domena, czy domena partnerska, czy ruch, którego nie chce.
3. Sprawdź, czy klient wysyła zdarzenia przez server-side GTM albo inny kanał oparty na Measurement Protocol. Jeśli tak, filtr nie obejmie tego ruchu.
4. Sprawdź, czy wdrożenie nie zostawia pustego hostname, na przykład przez własne wywołania z niestandardowego kodu.
5. Utwórz filtr w trybie Include i ustaw stan Testowanie.
6. Zbuduj w eksploracji raport na wymiarze Test data filter name i porównaj wolumen oznaczonych zdarzeń z listą domen. Oczekiwany wynik to brak oznaczeń przy ruchu z listy.
7. Dopisz do dokumentacji konta datę utworzenia, listę domen i osobę, która filtr włączyła. Wróć do wpisu przy każdej zmianie w domenach klienta.

Lista dozwolonych domen porządkuje jedną z najbardziej męczących części pracy z GA4. Wymaga jednak spisania domen przed włączeniem, bo drugiej próby nie ma. Wdrożenie po testach i z wpisem w dokumentacji zajmuje mniej czasu niż odtwarzanie brakujących tygodni danych, gdy na liście zabrakło subdomeny sklepu.