1. Was sich geändert hat
Google führt in den Analytics-Ankündigungen unter dem Datum 21. September 2026 Include-Filter für Hostnamen. Damit lässt sich eine Positivliste der Domains hinterlegen, die Ereignisdaten an eine Property senden dürfen. Alles, was von einem anderen Hostnamen kommt, wird nicht mehr in die Property aufgenommen.
Bis dahin war die Filterung auf Exclude-Filter beschränkt. Diese Logik arbeitet gegen eine Liste von Störern, die man erst kennen muss, bevor man sie ausschließen kann — und die laufend länger wird, weil jede neue Spam-Quelle einen neuen Eintrag verlangt. Die Umkehrung der Logik nimmt diese Pflege heraus: Wer seine eigenen Domains kennt, muss nicht mehr wissen, wer ihn gerade stört.
Eingerichtet wird der Filter über die Datenfilter der Property. Dafür ist die Editor-Rolle auf Property-Ebene erforderlich, und je Property sind höchstens zehn Datenfilter möglich. Stand September 2026 gilt dieses Limit für alle Datenfilter zusammen, nicht je Filterart.
2. Warum eine Positivliste anders wirkt als eine Sperrliste
Der Unterschied zwischen Include und Exclude ist nicht der Komfort, sondern die Richtung des Fehlers. Ein zu kurzer Exclude-Filter lässt Müll durch: ärgerlich, sichtbar, jederzeit nachbesserbar. Ein zu kurzer Include-Filter lässt echte Daten liegen — und zwar still, weil in den Berichten nichts fehlt, das man vermissen könnte.
Exclude- und Include-Filter unterscheiden sich vor allem in der Richtung des Fehlers.
Genau darin liegt der praktische Wert und das praktische Risiko. Wer alle eigenen Hostnamen vollständig kennt, bekommt saubere Berichte ohne weitere Pflege. Wer eine Subdomain übersieht, verliert deren Daten, ohne dass ein Hinweis darauf erscheint.
Dazu kommt eine Automatik, die in die gleiche Richtung wirkt: Ereignisse ohne Hostname werden bei aktivem Include-Filter automatisch blockiert. Die Begründung ist plausibel — ein fehlender Hostname deutet in der Regel auf Spam oder auffälligen Traffic hin. Sie bedeutet aber auch, dass ein Include-Filter nicht nur die Liste durchsetzt, die man geschrieben hat, sondern zusätzlich eine Regel, die man nicht geschrieben hat.
3. Was gefiltert heißt
Der entscheidende Punkt steht nicht in der Überschrift der Ankündigung, sondern in der Funktionsweise: Daten, die ein aktiver Filter ausschließt, werden gar nicht erst verarbeitet. Sie stehen weder in Analytics zur Verfügung noch im BigQuery-Export.
Das ist kein Ansichtsfilter, der sich später zurücknehmen lässt. Ein Exclude-Filter, den man versehentlich zu weit gefasst hat, ist ein Fehler mit begrenzter Reichweite, weil die Rohdaten an anderer Stelle weiterlaufen. Beim Include-Filter gibt es diese zweite Ebene nicht — eine vergessene Subdomain ist für den Zeitraum, in dem der Filter aktiv war, unwiederbringlich.
Für die Praxis folgt daraus eine klare Rangfolge. Die Vollständigkeit der Liste ist wichtiger als der Zeitpunkt der Aktivierung. Ein Filter, der zwei Wochen später scharf geschaltet wird, kostet zwei Wochen Spam in den Berichten; ein Filter, der zwei Wochen zu früh scharf geschaltet wird, kostet zwei Wochen echte Daten.
4. Wer im Mittelstand besonders hinsehen sollte
Die Funktion ist für Unternehmen mit genau einer Domain und einer Website unkritisch. Interessant und riskant wird sie in den Konstellationen, die im Mittelstand die Regel sind: mehrere Subdomains, ein Shop unter eigener Adresse, eine Landingpage-Umgebung bei einem Dienstleister, ein Buchungs- oder Terminsystem, das unter einem fremden Hostnamen läuft.
Bei Hotels, Kliniken, Autohäusern oder Handwerksbetrieben hängt oft genau der wertvollste Teil der Messung an so einem fremden Hostnamen — die Buchungsstrecke, das Anfrageformular, der Konfigurator. Wer diese Hostnamen nicht in die Positivliste aufnimmt, filtert nicht den Spam heraus, sondern die Conversions.
Ebenfalls leicht zu übersehen sind Umgebungen, die nicht im Tagesgeschäft auftauchen: Staging- und Testsysteme, Vorschauadressen des Content-Management-Systems, eine alte Domain, die noch per Weiterleitung lebt, oder eine Kampagnendomain aus dem Vorjahr. Ob diese Hostnamen in die Liste gehören, ist eine Entscheidung — dass sie vorher bekannt sein müssen, ist keine.
5. Der Testmodus ist der eigentliche Arbeitsschritt
Bevor ein Filter aktiv wird, lässt er sich in einem Testmodus betreiben. In diesem Zustand werden betroffene Ereignisse nicht entfernt, sondern mit einer eigenen Dimension gekennzeichnet. Damit lässt sich vorab auswerten, was der Filter im Echtbetrieb aussortieren würde.
Das ist der Punkt, an dem sich die Einrichtung entscheidet. Wer den Testmodus überspringt, prüft seine Liste gegen sein Gedächtnis; wer ihn nutzt, prüft sie gegen die tatsächlichen Daten. Der Unterschied kostet ein paar Tage Geduld und ersetzt jede Diskussion darüber, ob die Liste vollständig ist.
Sinnvoll ist, den Testmodus über einen Zeitraum laufen zu lassen, der die üblichen Schwankungen abdeckt — Wochenende, Monatswechsel, eine laufende Kampagne. Ein Hostname, der nur einmal im Monat Daten sendet, weil dort ein Newsletter-Formular liegt, taucht in einer Stichprobe von zwei Tagen nicht auf.
Erst die Liste aus den Daten, dann der Testmodus, dann die Aktivierung.
6. Grenzen und Sonderfälle
Eine Ausnahme ist ausdrücklich vorgesehen: Auf Ereignisse aus dem Measurement Protocol werden die Hostname-Include-Filter nicht angewendet. Wer serverseitig Ereignisse einspeist, sollte das wissen, bevor er den Filter als vollständige Absicherung gegen eingeschleuste Daten versteht.
Das Limit von zehn Datenfiltern je Property begrenzt außerdem, wie fein sich eine Property regeln lässt. In Konstruktionen mit vielen Marken oder Ländern in einer Property ist das eher eine Frage der Struktur als eine Frage des Filters. Stand September 2026 gilt: Wer schon Exclude-Filter einsetzt, verbraucht damit Plätze, die für den Include-Filter fehlen können.
Und schließlich wirkt ein Datenfilter nur nach vorn. Spam, der bereits in den historischen Berichten liegt, verschwindet dadurch nicht. Für Vergleiche über Zeiträume hinweg entsteht damit eine Bruchstelle, die man kennen und beim Lesen der Zahlen mitdenken muss.
7. Checkliste
- Alle Hostnamen zusammentragen, die Daten an die Property senden dürfen: Hauptdomain, Subdomains, Shop, Landingpages, Buchungs- und Formularsysteme unter fremdem Hostnamen.
- Prüfen, welche Hostnamen in den letzten Monaten tatsächlich Ereignisse gesendet haben, statt sich auf die Liste aus dem Kopf zu verlassen.
- Entscheiden, ob Staging-, Test- und Vorschauumgebungen in die Berichte gehören oder bewusst draußen bleiben sollen.
- Editor-Rechte auf Property-Ebene sicherstellen und prüfen, wie viele der zehn möglichen Datenfilter bereits belegt sind.
- Den Filter zuerst im Testmodus anlegen und die gekennzeichneten Ereignisse über einen Zeitraum auswerten, der Wochenende und Monatswechsel einschließt.
- Serverseitig eingespeiste Ereignisse gesondert betrachten, weil Measurement-Protocol-Ereignisse vom Filter ausgenommen sind.
- Erst nach Auswertung des Testmodus aktivieren und das Aktivierungsdatum notieren, damit die Bruchstelle in Zeitvergleichen später erklärbar bleibt.
8. Fazit
Die Funktion räumt ein echtes Ärgernis ab. Spam-Traffic in GA4 war bisher entweder ein Pflegethema ohne Ende oder ein Posten, den man in Berichten wegerklärt hat — eine Positivliste beendet beides mit einem Eintrag je eigener Domain.
Zugleich halte ich die Einordnung als reine Aufräumfunktion für zu freundlich. Zum ersten Mal steht in GA4 eine Einstellung bereit, deren Fehler nicht auffällt: Ein zu enger Filter produziert Berichte, die sauber aussehen und falsch sind, und weder Analytics noch der BigQuery-Export halten ein Netz darunter. Das ist ein anderes Risiko als ein zu weit gefasster Exclude-Filter, und es verlangt eine andere Sorgfalt.
Meine Empfehlung wäre deshalb, die Funktion zu nutzen, aber die Reihenfolge nicht zu verkürzen: erst die Hostnamen aus den tatsächlichen Daten ziehen, dann den Testmodus über einen vollen Zyklus laufen lassen, dann aktivieren. Wer den Spam ohnehin schon per Exclude-Filter im Griff hat, gewinnt vor allem Pflegeaufwand zurück — das ist ein guter Grund, aber kein dringender.
9. Häufige Fragen
Verschwindet der Spam damit auch rückwirkend aus den Berichten?
Nein. Ein Datenfilter wirkt nur auf Daten, die nach seiner Aktivierung eingehen. Historische Berichte bleiben so, wie sie sind, und Vergleiche über den Aktivierungszeitpunkt hinweg zeigen deshalb einen Sprung, der nichts mit dem Geschäft zu tun hat.
Lässt sich versehentlich gefilterter Traffic wiederherstellen?
Nein. Daten, die ein aktiver Filter ausschließt, werden nicht verarbeitet und sind weder in Analytics noch im BigQuery-Export verfügbar. Das ist der wesentliche Unterschied zum Exclude-Filter und der Grund, warum der Testmodus vor der Aktivierung kein optionaler Schritt ist.
Was passiert mit Ereignissen, die keinen Hostnamen mitliefern?
Sie werden bei aktivem Include-Filter automatisch blockiert, weil ein fehlender Hostname in der Regel auf Spam hindeutet. Wer eigene Ereignisse aus Quellen ohne Hostname sendet, sollte das vorher im Testmodus prüfen.
Gilt der Filter auch für serverseitig gesendete Ereignisse?
Nicht für alle. Auf Ereignisse aus dem Measurement Protocol werden Hostname-Include-Filter nicht angewendet. Wer dort Daten einspeist, hat mit dem Filter also keinen vollständigen Schutz gegen eingeschleuste Ereignisse.
Wie viele Filter lassen sich anlegen und wer darf das?
Je Property sind höchstens zehn Datenfilter möglich, und zum Anlegen ist die Editor-Rolle auf Property-Ebene erforderlich. Wer bereits Exclude-Filter im Einsatz hat, sollte vorher prüfen, wie viele Plätze davon noch frei sind.
Lohnt sich die Umstellung, wenn die Berichte aktuell sauber aussehen?
Dann ist es kein dringender Schritt. Der Gewinn liegt weniger in besseren Zahlen als in weniger Pflege, weil eine Positivliste nicht bei jeder neuen Spam-Quelle nachgezogen werden muss. Bei einer einzigen Domain ohne Subdomains ist der Aufwand-Nutzen-Abstand allerdings gering.
