On September 21, Google quietly added a third option to GA4's data filters: you can now build an allowlist of hostnames instead of a blacklist. A property can declare which domains are authorized to send event data, and everything else gets dropped before it ever reaches a report. Until this week, hostname filtering was exclude-only — you named the spam domains one by one and played whack-a-mole as new ones appeared.
The release note on Google's "What's new in Google Analytics" page frames it as a maintenance problem solved: "Previously, filtering was limited to Exclude filters, which required ongoing manual updates to keep up with new sources of spam. By allowing you to define a list of approved hostnames, this feature simplifies configuration and helps ensure the integrity of your analytics data with minimal maintenance."
For anyone who has inherited a GA4 property polluted by ghost referral spam — fake events sent directly to a Measurement ID without anyone visiting the site — this is the cleanup tool that was missing. But the fine print contains two asymmetries that matter, and one of them cuts in an unexpected direction.
What actually shipped
The change appears in the September 21, 2026 entry of Google's release notes under "Hostname filters." Google added the filter type itself on June 11, when the note described it as a way to "filter out (exclude) events based on their hostname." Include matching is the new part.
Two behaviors are worth quoting in full, because they're the difference between a clean rollout and a silent data incident:
Measurement Protocol events pass through untouched. "Hostname Include filters will not be applied to events sent from the Measurement Protocol, ensuring this data remains unblocked." Any server-side or offline events you push via MP ignore the allowlist entirely.
Events with no hostname get blocked. "Include filters will automatically block events with empty hostnames (such as gtag.js traffic), as a missing hostname typically indicates spam or abnormal traffic."
That second one is doing a lot of work. A missing hostname is treated as spam by default — even when the sender is Google's own standard web tag.
Why the allowlist matters
Ghost spam has been a low-grade chronic infection in GA4 since the platform replaced Universal Analytics. Anyone can read a property's Measurement ID out of a site's page source and fire fabricated events at the collect endpoint. Those events carry no real session, and they typically arrive with either the spammer's own domain or nothing at all in the hostname field. They inflate sessions, pollute engagement metrics, and quietly corrupt conversion rates.
The June filter was a partial answer: block the bad hostnames you noticed. But a blacklist is only as current as the last unwanted hostname you spotted, which is exactly the maintenance treadmill Google's release note now says it wants to end. With Include, you list your production domains once — www.example.com, example.com, and any subdomains or regional properties feeding the same web data stream — and stop editing the filter every time a new spam source shows up.
There's also a structural argument for allowlists that Google doesn't spell out: they fail closed. A blacklist fails open — a new spam domain sails through until someone notices. An allowlist fails shut — a new legitimate subdomain gets dropped until someone notices. For data integrity, one of those errors is much cheaper than the other.
The Measurement Protocol carve-out
The exemption is reasonable on its face: Measurement Protocol events often don't carry a meaningful hostname at all. Server-side tagging, offline CRM conversions, and point-of-sale integrations commonly send events with no page_location and therefore no hostname. Apply the allowlist strictly and every one of those events vanishes.
But the carve-out has an obvious side effect: if spammers can send junk straight to your Measurement ID via Measurement Protocol today, they can keep doing it after you activate an Include filter. The allowlist hardens the web tag door and leaves the API door open. Google's note is candid that "this data remains unblocked" — that's a promise to MP senders and a warning to everyone else in the same sentence.
Practically, this means an Include filter is not a complete spam defense. It kills the two most common pollution vectors — spoofed web events with forged hostnames, and empty-hostname noise — while MP junk requires separate handling, such as API secret hygiene, MP validation, or filtering at the reporting layer.
The empty-hostname trap
The automatic blocking of empty-hostname events is the sharpest edge in this release. Google's example of what falls into that bucket is gtag.js traffic — the standard tag most GA4 properties run.
In a normal gtag.js setup the hostname is populated and there's no issue. But there are legitimate configurations where events arrive without one: browser privacy tools and extensions that strip referrers and URLs, certain consent-mode and tag-routing setups, poorly configured single-page-app instrumentation, and accelerated or proxy-served pages that mangle page_location. Anyone with an unusual implementation should assume some fraction of real traffic carries an empty hostname, because the filter will treat all of it as spam.
There's also a rollout-timing subtlety. Data filters act on incoming data only — Google's documentation notes Analytics evaluates them "from the point of creation forward," so historical reports don't change. Once a filter is Active, the effect is permanent: matching events are never processed and, per Google's data-filters documentation, "will never be available in Google Analytics or BigQuery." Not "hidden from reports" — gone from the raw event export too.
That's why Google provides a Testing state before activation. In Testing, matching events aren't dropped; they're tagged with a "Test data filter name" dimension you can inspect in reports. Google says a data filter can take 24 to 36 hours to apply, and the sensible workflow is to run the filter in Testing for at least a few days, then compare the tagged dimension against the hostnames you intended to catch before flipping it to Active.
What practitioners should do this week
Audit your hostnames before touching anything. Open the Hostname dimension in your standard reports and export it. You want the full list of domains currently sending events — production domains, subdomains, legacy regional properties, and anything unexpected. This list is the input to your allowlist, and it's also a diagnostic: unexplained hostnames with meaningful volume are your spam sources.
List every legitimate variant. An include filter matches what's in the data, not what's in your brand guidelines. If both example.com and www.example.com send traffic, both go on the list. Miss one and you'll silently discard real users — permanently, given the no-BigQuery rule.
Build the filter in Testing and leave it there. Create it under Admin → Data collection and modification → Data filters, set the state to Testing, and give it 24–36 hours plus a full weekly cycle if you can. Then compare the "Test data filter name" dimension against your hostname audit. Anything with real sessions that got tagged is a hostname you forgot.
Decide your Measurement Protocol posture separately. If you rely on MP for server-side or offline events, this filter won't touch them — good. If you don't, MP remains your open flank, and the allowlist gives you no protection there. Rotate API secrets if they've ever been committed anywhere, and watch for suspicious event volume that skips the filter entirely.
Don't assume it's live in your property yet. The release note carries no rollout details, and as of September 22 Google's own setup documentation for hostname filters still describes the feature as exclude-only — the same docs-lag pattern that followed the May launch of the AI Assistant channel. The reliable check is the Data filters section in Admin: if the Include option is present in your property, it's shipped for you.
Watch your empty-hostname volume in Testing. If the test dimension tags a nontrivial share of sessions, you have instrumentation sending events without a hostname — fix the tagging before activating, or you'll be losing real traffic with no way to recover it.
The bigger picture
This is a data-quality release, and it lands at a moment when data quality is getting harder to maintain. Consent-mode adoption, browser privacy restrictions, server-side tagging, and now AI assistants fetching pages without rendering tags all fragment what "a session from your domain" even means. An allowlist is Google handing properties a simple, enforceable contract: tell me which domains are yours, and I'll keep everything else out.
It's also a small acknowledgment of a problem Google has largely ignored since GA4's launch — that Measurement IDs are public identifiers and the collect endpoint will accept whatever anyone sends. The Include filter doesn't fix that; it gives properties a perimeter. And the Measurement Protocol exemption makes clear where the perimeter ends.
One open question: Google hasn't said whether Include matching supports subdomain patterns or wildcard entries, and the release note is silent on how properties receiving data from multiple hostnames should configure matching. Until documentation catches up, the Testing state is your only safe way to find out — test before you trust it, because after activation there's no undo.
Sources
- What's new in Google Analytics — September 21, 2026: Hostname filters (Google)
- GA4 hostname filter announcement entry (Google Analytics announcements)
- Filter, report on, or restrict access to data subsets — data filters evaluated "from the point of creation forward" (Google)
- Hostname Filter in Google Analytics 4 (Loves Data) — https://www.lovesdata.com/blog/google-analytics-hostname-filter/
- GA4 Hostname Filter: How to Block Spam Traffic (FourFront) — https://www.fourfront.us/blog/using-the-hostname-filter-for-accurate-google-analytics-data/
