Filtry nazw hostów w GA4: testowanie, granice ochrony i analiza historii

Filtr nazwy hosta w GA4 może wykluczyć niepożądany ruch internetowy przed przetwarzaniem. Pomaga przy znanych domenach testowych lub świadomie utrzymywanej liście dozwolonych nazw. Nazwa hosta nie dowodzi jednak autentycznej wizyty. Google wyraźnie wyłącza zdarzenia Measurement Protocol z działania filtrów nazw hostów typu Include.

Trzy zadania wymagają odrębnych metod: zapobieganie napływowi niepożądanych danych, sprawdzenie reguły przed aktywacją i analiza już zebranych danych. Ogólna obietnica usunięcia całego spamu może prowadzić do utraty prawidłowych zdarzeń.

Nazwa hosta opisuje zdarzenie, nie tożsamość nadawcy

Wymiar nazwy hosta zawiera domenę i ewentualną subdomenę, na przykład shop.example.com. Referrer oznacza natomiast poprzednią stronę lub źródło odsyłające. Możliwa jest także pusta nazwa: w usłudze GA4 z danymi witryny i aplikacji nie każde zdarzenie ma użyteczną nazwę hosta internetowego.

Publiczny identyfikator pomiaru nie jest tajnym poświadczeniem. Udokumentowany Measurement Protocol dodatkowo wymaga api_secret; sekret powinien pozostawać na serwerze. Ujawnienie wymaga rotacji i poprawienia dziennika lub konfiguracji odpowiedzialnej za wyciek. Reguła nazwy hosta nie zastępuje ochrony poświadczeń.

Nieoczekiwana nazwa jest wskazówką do sprawdzenia, nie automatycznym dowodem spamu. Witryny kampanijne, domeny realizacji zamówienia, serwery tłumaczeniowe i środowiska programistyczne mogą wymagać różnych zasad. Z kolei dozwolona nazwa sama w sobie nie potwierdza rzeczywistej aktywności.

Środowiska testowe i ruch wewnętrzny to różne przypadki

Środowisko testowe może mieć własną nazwę hosta. Jeśli system testowy nie używa kodów pomiarowych rzeczywistej witryny albo wysyła dane do osobnej usługi GA4 do testów, testowe wizyty nie trafiają do danych prawdziwych odwiedzin. Wykluczenie hosta może stanowić dodatkową granicę dla odpowiednio nazwanych systemów testowych.

Ruch wewnętrzny często korzysta z tego samego hosta produkcyjnego co zwykłe wizyty. Google opisuje osobne reguły oparte na adresach lub zakresach IP, znacznik traffic_type i dopasowany filtr danych. Szeroka reguła wspólnej sieci może objąć także prawidłowy ruch. Sama nazwa hosta nie odróżnia pracowników od pozostałych odwiedzin tej samej strony.

Exclude, Include only i granice obu metod

Google wprowadziło filtry nazw hostów Exclude 11 czerwca 2026 r., a Include 21 września 2026 r. Exclude usuwa pasujące dane przychodzące. Include only zachowuje pasujące dane w zakresie działania danej funkcji. Najpierw do dopuszczenia wystarcza zgodność z dowolnym aktywnym filtrem Include, a następnie kolejno działają aktywne filtry Exclude. Początkowo dopuszczone zdarzenie może więc zostać wykluczone przez inną regułę.

Informacje o wersji wskazują dwa ważne zachowania Include: zdarzenia z pustą nazwą hosta są blokowane, natomiast zdarzenia Measurement Protocol pozostają wyłączone z filtrowania. Wyjątek dotyczy udokumentowanej operacji Include i nie dowodzi identycznego działania wszystkich mechanizmów filtrowania. Dalsze szczegóły zawiera artykuł o trybie Include.

Dokładną nazwę hosta łatwiej skontrolować niż szerokie dopasowanie fragmentu. Przykładowo contains example.com może objąć również example.com.unrelated.test. Sprawdzenie końcówki bez granicy domeny może dopuścić notexample.com. Potrzebne domeny główne i subdomeny wymagają celowych reguł i testów; znany ciąg znaków nie jest walidacją domeny.

Testowanie przed aktywacją

1. Zestawić nazwy hostów według strumienia, platformy, nazwy zdarzenia i daty. Zachować widoczność brakujących wartości oraz sprawdzić domeny zamówień, kampanii i testów.
2. Utworzyć docelowy filtr nazwy hosta w stanie Testing. Google wymaga roli Edytor lub wyższej. Dostępne dopasowania obejmują dokładną zgodność, początek, koniec i zawarty ciąg znaków.
3. Odczekać 24–36 godzin przed oceną. W eksploracji swobodnej zestawić Test data filter name, Hostname i Event name z Event count. Porównać też pełny, niefiltrowany zbiór, szczególnie przy Include.
4. Sprawdzić przypadki przyjmowane i odrzucane: witrynę główną, realizację zamówienia, domenę kampanii, środowisko testowe oraz brak hosta. Ruch Measurement Protocol wymaga osobnej kontroli.
5. Objąć reprezentatywny cykl działania. Tydzień może być punktem wyjścia, ale nie obejmuje każdej comiesięcznej kampanii lub publikacji.
6. Po weryfikacji aktywować regułę i zapisać ustawienia oraz datę. Google wskazuje 24–36 godzin do rozpoczęcia działania; natychmiastowy spadek w ściśle określonej chwili nie jest gwarantowany.

Testing oznacza pasujące dane zamiast odrzucania. Inactive wyłącza ocenę reguły. Aktywne wykluczenie trwale usuwa odpowiednie dane z przetwarzania, także z dostępności w BigQuery. Późniejsza dezaktywacja zatrzymuje przyszłe filtrowanie, ale nie przywraca wcześniej odrzuconych zdarzeń.

Analiza historii pozostaje możliwa

Nowy filtr danych przychodzących nie przepisuje istniejących raportów. Nadal dostępne dane historyczne można jednak analizować przez filtry raportów, eksploracje lub Data API. W zgodnym raporcie szczegółowym filtr nazwy hosta zmienia wykres i tabelę bez usuwania danych źródłowych. Nadal obowiązują dostępność wymiarów, okres przechowywania i ograniczenia raportowania.

BigQuery zapewnia inną drogę, jeśli istnieje eksport zdarzeń. Poniższe zestawienie rozdziela strumienie witryn i aplikacji, ujednolica wielkość liter oraz zewnętrzne spacje w nazwach i zachowuje braki jako odrębną grupę. Zliczane są zdarzenia, nie sesje ani użytkownicy.

WITH observed AS (
  SELECT
    platform,
    stream_id,
    NULLIF(LOWER(TRIM(device.web_info.hostname)), '') AS host
  FROM `project.analytics_XXXXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930'
)
SELECT
  platform,
  stream_id,
  host,
  CASE
    WHEN host IS NULL THEN 'missing_hostname'
    WHEN host IN ('www.example.com', 'shop.example.com') THEN 'approved_hostname'
    ELSE 'other_hostname'
  END AS hostname_group,
  COUNT(*) AS events
FROM observed
GROUP BY platform, stream_id, host, hostname_group
ORDER BY events DESC;

Projekt, zbiór danych, daty i zatwierdzone nazwy są wartościami przykładowymi. Stałe granice dat wybierają dzienne tabele wrześniowe zamiast tabel intraday. Zapytanie czyta istniejące, zgodne tabele eksportu; brakujące dni nie stają się dniami z zerową liczbą zdarzeń. Zestawienie nie dowodzi kompletności eksportu. Przed wykonaniem przydatne są próbna analiza BigQuery i odpowiedni limit rozliczanych bajtów.

Przy świadomie ograniczonej analizie internetowej warunek hostname_group = 'approved_hostname' w zapytaniu otaczającym zachowuje tylko wybrane nazwy. Usuwa również grupę bez nazwy hosta. Zdarzenia serwerowe i dane aplikacji wymagają więc osobnej, jawnej zasady zamiast cichego odrzucenia. Etykiety klasyfikują obserwowane nazwy; dopuszczenie nie dowodzi autentyczności zdarzenia.

Natywny eksport zdarzeń nie odtwarza na żądanie wszystkich danych sprzed rozpoczęcia eksportu. Import historyczny przez API raportowania tworzy inny zbiór zawierający podsumowania zamiast pojedynczych zdarzeń i nie rekonstruuje brakujących zdarzeń surowych. Zdarzenia odrzucone przez aktywne filtry danych są niedostępne zarówno w Analytics, jak i w natywnym eksporcie.