Since 21 September 2026, GA4 lets you build an allowlist of hostnames with an Include data filter. Two things to know before you switch one on. It is permanent: anything it drops “will never be available in Google Analytics or BigQuery”. And it drops more than spam — every event whose hostname is missing, plus every legitimate hostname you forget to list. We checked what Consent Mode pings carry: a page_view sent with all signals denied (gcs=G100) carries the page URL exactly like a consented one, so the filter does not treat consent states differently. Test it first; GA4 has a testing state for exactly this.
Hostname filtering is an old spam defence. Until now GA4 only offered it as an exclude list, which meant chasing every new spam domain. The new option inverts it: name the hostnames that are allowed, and everything else is discarded. It is simpler to maintain and much easier to get wrong in a way you cannot undo.
What Google announced
The release note is short and has two details that matter more than the headline:
- “Hostname Include filters will not be applied to events sent from the Measurement Protocol”. Server-to-server events bypass the allowlist entirely.
- “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 line is ambiguous in a way we could not resolve: it does not say which gtag.js traffic arrives without a hostname. What we could check is what ordinary gtag.js hits carry.
Consent Mode pings carry the hostname too
A worry specific to Consent Mode setups: if a denied-consent ping were stripped down enough to lose its hostname, an Include filter would quietly delete the very data Google uses for modelling. We measured it. Two local pages with the same GA4 tag, one without Consent Mode, one with ad_storage, analytics_storage, ad_user_data and ad_personalization set to denied, loaded in Chromium on 27 September 2026:
gcs dl (page URL sent with the hit)
no Consent Mode — http://127.0.0.1/ga?consent=granted
all signals denied G100 http://127.0.0.1/ga?consent=denied
Both page_view hits carry the full page URL in dl. Consent state does not change that, so an allowlist that contains your hostname keeps denied-consent pings as well as consented hits. One small detail from the same capture: the page was served on port 8970 and dl omitted the port. The hostname you list is the bare host.
What we cannot see is GA4’s side — how it derives the hostname from the hit and what it then discards. That part rests on Google’s documentation, not on our measurement. (How to read gcs yourself is in verifying Consent Mode from the network tab.)
Why a mistake here is permanent
GA4’s data filters documentation is blunt: “Once you apply a data filter, the effect on the data is permanent.” Excluded data “is never processed and will never be available in Google Analytics or BigQuery.” Filters only act from the moment they are active — “Data filters do not affect historical data” — so there is no backfill either way. And the order is fixed: “All active ‘Include only’ data filters are unioned and applied first as a group, followed sequentially by any active ‘Exclude’ filters.”
The failure mode is not spam getting through. It is a real part of your site going dark because nobody remembered it sends data.
The hostnames people forget
- Both forms of the main domain —
example.comandwww.example.comif both ever serve pages, including during a redirect change. - Subdomains — shop, blog, help, app, and any marketing landing-page host.
- Country and language domains sharing one property.
- Third-party hosted steps that load your tag: checkout, booking, payment return pages.
- Anything that rewrites the page URL — server-side tagging or proxies that set
page_locationthemselves. Check what they actually send before assuming.
How to switch it on without losing data
- Inventory first. In an Exploration, break down events by hostname over the longest range you have. Anything with real traffic that you do not recognise is either spam or a hostname you forgot; find out which.
- Use the testing state. GA4 data filters can be created in a testing state, and the Test data filter name dimension exists “to validate your filters before activating them.” Leave the filter in testing for at least a full business cycle and check which events it would have caught. Confirm the hostname filter offers the testing state in your property before relying on it.
- Look for the empty ones. Before activating, check how many events already arrive with no hostname. Google says those will be blocked; that is the one category the testing period should explain.
- Remember the Measurement Protocol exception. Server-sent events are unaffected, so a filter that looks clean in testing will not tell you anything about them.
If the reason you are cleaning up GA4 is that the numbers stopped matching, check what your tags send before filtering what GA4 keeps. A single wrong line can change it — a gtag wrapper that pushes an array instead of arguments makes gtag.js ignore the consent default entirely, as we measured in the gtag dataLayer push bug.
Before changing what GA4 keeps, check what your tags actually send. Check your Consent Mode signals with CookieInspector.