GA4 Hostname Include Filters: Build an Allowlist, Not a Blocklist

Ghost spam has been a fixture of every GA4 audit we run. The pattern is always the same. A property reports sessions from a domain nobody in the business recognises, the client asks which channel paid for them, and the honest answer is that no human ever visited.

Google shipped half an answer on 11 June 2026. Hostname data filters arrived as a new filter type sitting alongside internal traffic and developer traffic, and they did one thing. They excluded events from hostnames you named. Useful, but it inverted the work. Every spam domain had to be found in a report and typed in by hand, and spammers move domains faster than anyone updates a filter.

On 21 September 2026 the changelog entry Hostname filters added the other half. Hostname data filters now support an Include mode, which turns the filter into an allowlist of approved domains. Name the hostnames that belong to the property and everything else is refused.

That is a much better control. It is also the first GA4 setting in a while that can silently delete a legitimate traffic source permanently. Both halves deserve attention.

What actually changed

An Exclude filter is a blocklist. It stops what you name. Anything unnamed passes straight through, which is why the June release arrived carrying a promise it could not keep. Google's June wording said the filter would make sure any data that does not come from an approved domain is not collected. An exclusion list cannot do that. It stops the domains already on the list and waves through every domain the list has not met.

An Include filter is an allowlist. It refuses what you have not named. The administrative job changes shape. Instead of tracking domains you do not own, you keep an accurate record of the ones you do. That list is shorter, it changes rarely, and it does not depend on anybody spotting new spam in a report at the right moment.

The failure mode moves with it. With a blocklist, being slow costs you some junk in the reports. With an allowlist, being incomplete costs you real traffic, and by the time somebody notices, the data is gone.

The two carve-outs written into the release

Google put two exceptions in the announcement, and both change how the filter behaves on a real property.

Measurement Protocol events pass untouched

The first bullet states that Hostname Include filters will not be applied to events sent from the Measurement Protocol, so that data remains unblocked. Server-side events keep arriving, which is what you want for point-of-sale systems, call-tracking platforms and kiosks that have no hostname to declare in the first place.

It also means the allowlist does not close every route for fake traffic. Practitioners disagree about how much ghost spam arrives through the Measurement Protocol rather than through a copied measurement ID, and Google's note does not settle it. If a meaningful share of your junk arrives that way, an Include filter will leave it alone. Keep hostname breakdowns in your regular checks either way.

Empty hostnames are treated as spam

The second bullet is the one that deserves a second read. Include filters will automatically block events with empty hostnames, which Google describes as traffic such as gtag.js, on the basis that a missing hostname usually signals spam or abnormal traffic.

The parenthetical is ambiguous and the ambiguity is expensive. Read literally, it suggests gtag.js traffic as a class arrives without a hostname, which would describe most ordinary web collection and make the feature close to unusable. The narrower reading, that Google means requests formatted like gtag.js hits but missing a hostname, fits the rest of the sentence better. The release note does not say which one is intended.

What is clear is the target. Spam events commonly carry either the spammer's own domain or no hostname at all, and the second kind shows in reports as (not set) on the hostname dimension. Google is plainly trying to catch that. What no documentation has confirmed yet is whether an ordinary consented browser hit can ever land without a hostname. Until somebody publishes a controlled test, treat the first week after activation as a monitoring window rather than a set-and-forget change.

The rules Include mode inherits

Nothing about the new mode exempts it from the rules governing every GA4 data filter. Those rules are unforgiving, and together they are the reason this needs a process rather than a click.

• Permanent. Google's documentation is blunt about it. Once you apply a data filter, the effect on the data is permanent. Excluded data is never processed and never becomes available in Google Analytics or the BigQuery export. There is no undo button, and support will not restore it.
• Not retroactive. Filters act from the moment they are saved. The spam already sitting in your reports stays there. Filtering is a brake, not a mop.
• Ten per property. A property holds at most ten data filters. Between internal traffic, developer traffic and a hostname filter or two, that budget disappears faster than most teams expect. Delete the test filters you never activated.
• Editor at property level. Creating a filter needs the Editor or Administrator role on the property. If you work from a read-only agency seat, plan for somebody at the client to make the change, and send them the exact hostname list rather than a description of it.
• Three states. Testing, Active and Inactive. In Testing, matching events are labelled with a dimension called Test data filter name instead of being removed. That is your dry run.
• Processing delay. Allow 24 to 48 hours before the filter behaves as expected in reports. A filter saved this morning is not a filter you can prove this morning.

Inventory the hostnames before you write one

Include mode only works if the allowlist is complete, so start with the data rather than the setting. Open a free-form exploration, break sessions down by hostname over the last twelve months, and export the whole list. Sort it into three groups. Hostnames that are yours and must be allowed. Hostnames that are junk. Hostnames you cannot explain yet.

The third group is where the work is. Chase the unknown rows to a person, not to a guess. Then go looking for the hostnames that will not appear in any report because nobody has linked to them in months.

• Both the www and non-www versions, which can collect separately and often do after a migration.
• Country or trademark variants held defensively, such as a .co.uk or a .com sitting on the same stream.
• Subdomains marketing spun up without telling anyone, the go. and lp. and promo. hosts behind a campaign.
• A staging or build environment still firing the production measurement ID.
• A legacy help centre or careers microsite living on another platform.
• A webview inside a mobile app that renders web pages under a hostname that looks nothing like the main site.
• A preview or deployment domain from a host such as netlify.app or vercel.app.

The last two catch people out regularly. A property that measures an app webview has a hostname no marketing team will think to mention, and an allowlist built from the obvious domains will cut it off without a warning.

A rollout sequence that survives an audit

1. Export the hostname report. Twelve months, by sessions, before any filter exists.
2. Classify every row as mine, junk or unknown. Resolve every unknown before you continue.
3. Write the allowlist explicitly, including the subdomains you intend to keep measuring.
4. Create the filter in Testing. Give it a readable name. The test dimension carries that name into reports, so a colleague can find it without a handover note.
5. Run it for 24 to 48 hours. Watch sessions by hostname and watch the test dimension together. Anything labelled for removal that you did not intend to remove is a missing allowlist entry.
6. Compare the totals. If session totals move by more than the junk share you measured in step one, something on the list is wrong.
7. Activate, then leave it alone. With an allowlist in place, hostname filtering stops being a monthly maintenance task.

What the allowlist does not fix

A data filter is a collection control, not a compliance measure. It changes what reaches your reports and nothing else. Three limits are worth stating before anyone in the business treats it as housekeeping.

Consent still governs collection. The tag still fires, the request still goes to Google, and your consent banner still decides whether that request carries identifiable data. Filtering a hostname after the fact does not reduce what you are accountable for under UK GDPR, and the ICO's guidance on analytics cookies has not changed because Google shipped a filter. Hostname filtering and consent configuration are separate jobs, and passing one does not cover the other.

History stays dirty. If a stray domain has been feeding junk into a property for a year, the filter stops the bleeding and repairs nothing. Cleaning what is already stored means a segment, a comparison, or a filter in your reporting layer or in BigQuery. That work is worth doing once, because it stops your baseline moving every time somebody reports a number.

And Measurement Protocol traffic keeps arriving, as set out above. If your junk turns out to come from a copied measurement ID rather than from server-side sends, the allowlist handles it. If it comes from the other direction, the allowlist watches it go past.

The short version

Google has handed agencies the control Universal Analytics users had for a decade, and this version is stronger than the one it replaces. It also arrives with the sharpest edge of any GA4 setting released this year, because an incomplete allowlist deletes real data permanently and quietly.

Ten minutes with a hostname export before you switch it on is the whole difference between cleaning up a property and breaking one.