GA4-Hostname-Filter: Testmodus, Spamgrenzen und historische Auswertung

Ein GA4-Hostname-Filter kann unerwünschten Webverkehr vor der Verarbeitung ausschließen. Das hilft bei bekannten Testdomains oder einer bewusst gepflegten Liste zulässiger Hostnamen. Ein Hostname beweist jedoch keinen echten Besuch. Ereignisse aus dem Measurement Protocol sind laut Google ausdrücklich vom Hostname-Include-Filter ausgenommen.

Drei Aufgaben brauchen getrennte Verfahren: unerwünschte neue Daten vermeiden, Filter vor der Aktivierung prüfen und bereits erhobene Daten auswerten. Ein pauschales Versprechen vollständiger Spamentfernung kann zum Verlust gültiger Ereignisse führen.

Der Hostname beschreibt das Ereignis, nicht die Identität des Senders

Die Dimension Hostname enthält Domain und gegebenenfalls Subdomain, beispielsweise shop.example.com. Der Referrer bezeichnet dagegen eine vorherige Seite oder verweisende Quelle. Auch ein fehlender Hostname ist möglich: In einer Property mit Web- und App-Daten enthält nicht jedes Ereignis einen verwendbaren Webhostnamen.

Die öffentliche Messkennung ist kein geheimes Zugangsmittel. Das dokumentierte Measurement Protocol verlangt zusätzlich api_secret; dieser Schlüssel gehört auf den Server. Ein offengelegter Schlüssel erfordert einen Wechsel und die Korrektur des undichten Protokollierungswegs oder der Konfiguration. Eine Hostnameregel ersetzt den Schutz der Zugangsdaten nicht.

Ein unerwarteter Hostname ist ein Prüfhinweis, kein automatischer Spamnachweis. Kampagnenseiten, Checkout-Domains, Übersetzungsproxys und Entwicklungssysteme können unterschiedliche Regeln benötigen. Umgekehrt belegt ein zulässiger Hostname allein keine echte Aktivität.

Testsysteme und interne Zugriffe sind unterschiedliche Fälle

Ein Testsystem lässt sich anhand eines eigenen Hostnamens erkennen. Wenn das Testsystem keine Messcodes der echten Website verwendet oder Daten an eine eigene GA4-Testproperty sendet, gelangen Testaufrufe erst gar nicht in die echten Besuchsdaten. Ein Hostname-Ausschluss kann eine zusätzliche Grenze für entsprechend benannte Testsysteme bilden.

Interne Zugriffe verwenden oft denselben Produktionshostnamen wie gewöhnliche Besuche. Google dokumentiert dafür gesonderte Regeln anhand von IP-Adressen oder Adressbereichen, einen Marker traffic_type und einen passenden Datenfilter. Eine breite Regel für ein gemeinsam genutztes Netz kann auch gültigen Verkehr erfassen. Der Hostname allein unterscheidet Beschäftigte nicht von anderen Besuchen derselben Seite.

Exclude, Include only und die Grenzen beider Verfahren

Google führte Hostname-Exclude-Filter am 11. Juni 2026 und Include-Filter am 21. September 2026 ein. Exclude entfernt passende eingehende Daten. Include only behält innerhalb des jeweiligen Anwendungsbereichs passende Daten. Zunächst genügt eine passende Regel aus allen aktiven Include-Filtern für die Zulassung; anschließend folgen die aktiven Exclude-Filter nacheinander. Ein zunächst zugelassenes Ereignis kann deshalb durch eine andere Regel ausgeschlossen werden.

Die Versionshinweise nennen zwei wichtige Eigenschaften von Include: Ereignisse mit leerem Hostnamen werden blockiert, Ereignisse aus dem Measurement Protocol bleiben ausgenommen. Diese Ausnahme betrifft ausdrücklich die dokumentierte Include-Operation und belegt keine identische Behandlung durch sämtliche Filterverfahren. Weitere Einrichtungshinweise enthält der Beitrag zum Include-Modus.

Ein exakter Hostname lässt sich leichter kontrollieren als ein breiter Teilstring. Beispielsweise kann contains example.com auch example.com.unrelated.test erfassen. Eine Endungsprüfung ohne Domaingrenze kann notexample.com zulassen. Benötigte Hauptdomains und Subdomains brauchen gezielte Regeln und Tests; eine bekannte Zeichenfolge ist keine Domainvalidierung.

Vor der Aktivierung testen

1. Hostnamen nach Datenstream, Plattform, Ereignisname und Datum erfassen. Fehlende Werte sichtbar halten; Checkout-, Kampagnen- und Testdomains prüfen.
2. Den gewünschten Web-Hostname-Filter im Zustand Testing anlegen. Google verlangt die Rolle Bearbeiter oder höher. Dokumentiert sind exakte Übereinstimmung, Anfang, Ende und enthaltene Zeichenfolge.
3. Vor der Auswertung 24–36 Stunden abwarten. In einer freien explorativen Analyse Test data filter name, Hostname und Event name mit Event count betrachten. Zusätzlich den ungefilterten Gesamtbestand vergleichen, besonders bei Include.
4. Zugelassene und ausgeschlossene Fälle gezielt auslösen: Hauptseite, Checkout, Kampagnendomain, Testsystem und fehlender Hostname. Measurement-Protocol-Verkehr braucht eine eigene Kontrolle.
5. Einen repräsentativen Betriebszyklus abdecken. Eine Woche ist ein möglicher Anfang, erfasst aber nicht jede monatliche Kampagne oder Veröffentlichung.
6. Nach erfolgreicher Prüfung aktivieren und Einstellungen sowie Datum dokumentieren. Google nennt 24–36 Stunden bis zur Wirkung; ein sofortiger Rückgang zu einem exakt bestimmbaren Zeitpunkt ist nicht garantiert.

Testing kennzeichnet passende Daten, statt Daten zu verwerfen. Inactive beendet die Auswertung der Regel. Ein aktiver Ausschluss entfernt betroffene Daten dauerhaft aus der Verarbeitung einschließlich der Verfügbarkeit in BigQuery. Eine spätere Deaktivierung beendet nur die künftige Filterung; bereits verworfene Ereignisse werden nicht wiederhergestellt.

Historische Auswertung bleibt möglich

Ein neuer Eingangsfilter schreibt bestehende Berichte nicht um. Weiterhin verfügbare historische Daten lassen sich trotzdem mit Berichtsfiltern, explorativen Analysen oder der Data API auswerten. In einem kompatiblen Detailbericht verändert ein Hostname-Filter Diagramm und Tabelle, ohne die zugrunde liegenden Daten zu löschen. Verfügbare Dimensionen, Aufbewahrung und Berichtsgrenzen bleiben maßgeblich.

BigQuery bietet einen weiteren Weg, sofern der Ereignisexport vorhanden ist. Die folgende Inventur trennt Web- und App-Datenstreams, vereinheitlicht Groß-/Kleinschreibung sowie äußere Leerzeichen und erhält fehlende Namen als eigene Gruppe. Gezählt werden Ereignisse, keine Sitzungen oder Nutzer.

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, Dataset, Datumsgrenzen und zugelassene Hostnamen sind Platzhalter. Die festen Datumsgrenzen wählen tägliche Septembertabellen statt Intraday-Tabellen. Die Abfrage liest vorhandene kompatible Exporttabellen; fehlende Tage werden nicht zu Tagen mit null Ereignissen. Eine Inventur beweist keine Exportvollständigkeit. Vor der Ausführung sind BigQuery-Dryrun und eine passende Obergrenze für abrechenbare Bytes sinnvoll.

Für eine bewusst eingeschränkte Webauswertung behält hostname_group = 'approved_hostname' in einer umgebenden Abfrage nur die gewählten Namen. Damit entfällt auch die Gruppe ohne Hostnamen. Serverereignisse und App-Daten brauchen deshalb eine ausdrückliche eigene Regel statt eines stillen Ausschlusses. Die Gruppen beschreiben beobachtete Namen; die Zulassung belegt keine Echtheit des Ereignisses.

Der native Ereignisexport rekonstruiert nicht auf Abruf sämtliche Daten aus der Zeit vor Exportbeginn. Ein Nachimport über die Reporting-API ist ein anderer Datenbestand mit zusammengefassten Werten statt einzelnen Ereignissen und stellt fehlende Rohereignisse nicht wieder her. Durch aktive Datenfilter bereits verworfene Ereignisse fehlen sowohl in Analytics als auch im nativen Export.