1. What Has Changed
In its Analytics announcements, Google lists include filters for hostnames under the date 21 September 2026. They let you store an allowlist of the domains that are permitted to send event data to a property. Anything arriving from a different hostname is no longer taken into the property.
Until then, filtering was limited to exclude filters. That logic works against a list of offenders you first have to know before you can shut them out — and one that keeps growing, because every new spam source demands a new entry. Reversing the logic removes that upkeep: if you know your own domains, you no longer need to know who is bothering you at the moment.
The filter is set up through the property's data filters. This requires the Editor role at property level, and no more than ten data filters are possible per property. As of September 2026, that limit applies to all data filters together, not per filter type.
2. Why an Allowlist Works Differently From a Blocklist
The difference between include and exclude is not convenience but the direction of the error. An exclude filter that is too short lets junk through: annoying, visible, and fixable at any time. An include filter that is too short leaves real data behind — and does so silently, because nothing is missing from the reports that you could notice.
Exclude and include filters differ above all in the direction of the error.
That is exactly where both the practical value and the practical risk lie. If you know all of your own hostnames in full, you get clean reports with no further upkeep. If you overlook a subdomain, you lose its data without any notice appearing.
On top of that comes an automatic rule that works in the same direction: events without a hostname are blocked automatically while an include filter is active. The reasoning is plausible — a missing hostname usually points to spam or suspicious traffic. But it also means that an include filter enforces not only the list you wrote, but in addition a rule you did not write.
3. What Filtered Means
The decisive point is not in the headline of the announcement but in how the feature works: data excluded by an active filter is not processed in the first place. It is available neither in Analytics nor in the BigQuery export.
This is not a view filter that can be undone later. An exclude filter that was accidentally drawn too wide is an error with limited reach, because the raw data keeps flowing elsewhere. With the include filter there is no such second layer — a forgotten subdomain is irretrievable for the period in which the filter was active.
In practice, this leads to a clear order of priority. The completeness of the list matters more than the moment of activation. A filter that goes live two weeks later costs two weeks of spam in the reports; a filter that goes live two weeks too early costs two weeks of real data.
4. Which Mid-Sized Businesses Should Look Closely
For companies with exactly one domain and one website, the feature is uncritical. It becomes interesting and risky in the set-ups that are the rule among mid-sized businesses: several subdomains, a shop at its own address, a landing page environment hosted by a service provider, a booking or appointment system that runs under a third-party hostname.
For hotels, clinics, car dealerships or trades businesses, it is often precisely the most valuable part of the measurement that depends on such a third-party hostname — the booking funnel, the enquiry form, the configurator. If you do not add these hostnames to the allowlist, you are filtering out not the spam but the conversions.
Equally easy to overlook are environments that do not show up in day-to-day business: staging and test systems, preview addresses of the content management system, an old domain that still lives on through a redirect, or a campaign domain from the previous year. Whether these hostnames belong on the list is a decision — that they have to be known beforehand is not.
5. Testing Mode Is Where the Real Work Happens
Before a filter becomes active, it can be run in a testing mode. In this state, affected events are not removed but marked with a dimension of their own. That makes it possible to evaluate in advance what the filter would sort out in live operation.
This is the point at which the set-up is decided. If you skip testing mode, you check your list against your memory; if you use it, you check it against the actual data. The difference costs a few days of patience and replaces any discussion about whether the list is complete.
It makes sense to run testing mode over a period that covers the usual fluctuations — a weekend, a change of month, a running campaign. A hostname that sends data only once a month, because a newsletter form sits there, will not show up in a two-day sample.
First the list from the data, then testing mode, then activation.
6. Limits and Special Cases
One exception is expressly provided for: hostname include filters are not applied to events from the Measurement Protocol. Anyone feeding in events server-side should know this before treating the filter as complete protection against injected data.
The limit of ten data filters per property also restricts how finely a property can be governed. In set-ups with many brands or countries in one property, that is more a question of structure than a question of the filter. As of September 2026: if you already use exclude filters, they take up slots that may then be missing for the include filter.
And finally, a data filter only works going forward. Spam that already sits in the historical reports does not disappear as a result. For comparisons across periods, this creates a break that you need to know about and keep in mind when reading the figures.
7. Checklist
- Gather all hostnames that are allowed to send data to the property: main domain, subdomains, shop, landing pages, booking and form systems under a third-party hostname.
- Check which hostnames have actually sent events in recent months instead of relying on the list in your head.
- Decide whether staging, test and preview environments belong in the reports or should deliberately stay out.
- Make sure you have Editor rights at property level and check how many of the ten possible data filters are already in use.
- Create the filter in testing mode first and evaluate the marked events over a period that includes a weekend and a change of month.
- Look at events fed in server-side separately, because Measurement Protocol events are exempt from the filter.
- Activate only after evaluating testing mode, and note the activation date so that the break in period comparisons can still be explained later.
8. Conclusion
The feature clears away a real nuisance. Spam traffic in GA4 has so far been either a never-ending upkeep task or an item you explained away in reports — an allowlist ends both with one entry per domain of your own.
At the same time, I think describing it as a mere clean-up feature is too kind. For the first time, GA4 offers a setting whose errors go unnoticed: a filter that is too narrow produces reports that look clean and are wrong, and neither Analytics nor the BigQuery export holds a safety net underneath. That is a different risk from an exclude filter drawn too wide, and it calls for a different kind of care.
My recommendation would therefore be to use the feature, but not to shorten the sequence: first pull the hostnames from the actual data, then let testing mode run over a full cycle, then activate. If you already have spam under control with exclude filters, what you mainly win back is upkeep effort — a good reason, but not an urgent one.
9. Frequently Asked Questions
Does the spam also disappear from the reports retroactively?
No. A data filter only affects data that arrives after it has been activated. Historical reports stay as they are, and comparisons across the activation date therefore show a jump that has nothing to do with the business.
Can traffic that was filtered by mistake be restored?
No. Data excluded by an active filter is not processed and is available neither in Analytics nor in the BigQuery export. That is the essential difference from the exclude filter and the reason why testing mode before activation is not an optional step.
What happens to events that do not carry a hostname?
They are blocked automatically while an include filter is active, because a missing hostname usually points to spam. If you send events of your own from sources without a hostname, you should check this in testing mode beforehand.
Does the filter also apply to events sent server-side?
Not to all of them. Hostname include filters are not applied to events from the Measurement Protocol. If you feed in data there, the filter therefore does not give you complete protection against injected events.
How many filters can be created, and who is allowed to do so?
No more than ten data filters are possible per property, and creating them requires the Editor role at property level. If you already have exclude filters in use, you should check beforehand how many slots are still free.
Is the change worthwhile if the reports currently look clean?
Then it is not an urgent step. The gain lies less in better figures than in less upkeep, because an allowlist does not have to be extended with every new spam source. With a single domain and no subdomains, however, the gap between effort and benefit is small.
