Analytics · 9 min read · 2026-09-22
GA4's New Hostname Include Filter: Stop SaaS Data Spam
On September 21, 2026, Google added an Include option to GA4's hostname data filter — a domain allowlist that authorizes only approved hostnames to send event data to a property, and drops everything else. Until this release, GA4's hostname filter was Exclude-only: you could name specific bad domains to block, but any hostname you had not explicitly listed still flowed into your reports. Google documents the change in its What's new in Google Analytics announcements, and practitioner guides tracking the rollout, such as this 2026 Google Analytics updates guide, confirm the Include allowlist as the September change. For SaaS teams, this is a small setting with an outsized effect on data integrity.
This post explains what the Include filter is, why unauthorized hostnames quietly corrupt SaaS funnel and attribution data, why an allowlist beats the exclude-list approach it replaces, how to configure it safely, and what it does and does not fix. The through-line: your real traffic comes from a small, known set of domains, so a default-deny allowlist is the cleanest way to keep phantom sessions out of the numbers your team makes decisions on.
What the Include hostname filter actually does
The Include hostname filter tells GA4 to accept event data only from the hostnames you approve and to discard the rest before it reaches your reports. You create it under Admin, Data filters, as a Hostname filter with an Include condition, then list the domains your organization legitimately measures — typically your marketing site, your application subdomain, and any docs or blog hosts wired to the same measurement ID. Every event whose reported hostname is not on that list is dropped at collection time, so it never inflates a session count or a conversion denominator.
The mechanic matters because a hostname is trivially spoofable in the wild but highly predictable for a legitimate business. A ghost-spam script can claim to be any domain, a scraped copy of your landing page will report the scraper's host, and a staging deploy reports its own subdomain — none of which you can anticipate one by one. An allowlist does not need to anticipate them: it grants access to the four or five hostnames you actually own and refuses the infinite set you do not. That is a structural fit for how SaaS traffic is distributed, and it is why the Include option is more than a convenience over the exclude list.
Why unauthorized hostnames corrupt SaaS data
Unauthorized hostname traffic corrupts SaaS analytics by adding sessions that had no chance of converting, which drags down every rate computed against them. There are three common sources. Ghost referral spam fires fabricated hits directly at the Measurement Protocol or an exposed measurement ID, never touching your site at all. Non-production environments — staging, preview deploys, localhost — leak test events into the production property when the same ID is reused. And scraped or cloned pages carry your snippet onto domains you do not control, sending real-looking pageviews from an audience that will never sign up.
The damage is downstream and easy to misread. Inflated top-of-funnel sessions make activation rate and signup-to-trial conversion look artificially low, so a growth team may chase an onboarding problem that is really a data-hygiene problem. Phantom sessions also get bucketed into Direct or fake referral channels, muddying channel ROI and attribution. We treat this class of contamination in depth in our guide to bot and invalid traffic inflating SaaS metrics, and the hostname allowlist is the most direct lever for the wrong-domain slice of that problem. It is the mirror image of the under-counting failure mode we cover in GA4 traffic under-counting: here the risk is over-counting, and the fix is exclusion at the source.
Why an allowlist beats the exclude-list it replaces
An allowlist wins because it is default-deny, so it does not depend on you noticing each new offender. The Exclude hostname filter that shipped earlier in 2026 was a denylist: useful, but reactive. Every time a new spam domain appeared or a new staging host came online, someone had to spot it in the data, then add another exclusion rule — and until they did, the bad events kept counting. In practice that means the exclude list is perpetually incomplete, because the set of domains you do not own is unbounded and constantly changing.
The Include filter inverts that maintenance burden. You describe the small, stable set of domains you do own, and GA4 rejects everything else automatically, including hostnames that do not exist yet. Maintenance drops to the rare event of launching a new legitimate domain, at which point you add one entry. This is the same governance principle we apply to campaign tagging in UTM taxonomy governance for attribution integrity: constrain inputs to a known-good schema at the source rather than cleaning an open-ended mess in analysis afterward.
How to configure it safely
Set the filter up in Testing state first, so a misconfiguration cannot silently delete real traffic. In Admin, open Data filters, create a Hostname filter, choose the Include condition, and enter every hostname that legitimately sends events: your apex and www marketing domains, your app subdomain, and any docs, help, or blog hosts on the same property. Do not omit a domain you actually use — an Include filter blocks everything absent from the list, so a forgotten subdomain becomes invisible the moment the filter goes Active.
Leave it in Testing while you validate against the Realtime and DebugView reports and, ideally, the filter's own evaluation summary, confirming that legitimate hostnames pass and only the unwanted ones are dropped. Only then switch it to Active. Remember that filters are not retroactive: they act on data collected after activation, so historical contamination remains and must be handled with report segments. Fold this into a recurring review rather than a one-off — our SaaS analytics data-quality audit checklist is a good home for a quarterly re-check of the allowlist against your current set of live domains.
What it fixes — and what it does not
The Include filter fixes wrong-hostname contamination going forward: it stops ghost spam, leaked staging events, and cloned-page hits from entering the property, which tightens the denominators in your funnel and gives attribution real touchpoints to model. Because phantom sessions no longer land in Direct or fake referrals, channel reports and conversion rates read closer to reality, and the improvement compounds — every report built on the property inherits the cleaner base data without any per-report work.
It does not fix everything, and it is important to be precise about the boundaries. It is not retroactive, so pre-existing spam stays in historical ranges. It does not stop invalid traffic that correctly reports one of your own hostnames — a bot hitting your real marketing site still passes the hostname test and needs separate bot mitigation. It does not change how the attribution model allocates credit among legitimate touchpoints; it only ensures those touchpoints are genuine. And it does nothing for hostname problems on other tools in your stack. Where accurate channel-to-revenue tracing is the goal, pair it with the broader discipline in our marketing channel revenue traceability audit.
A rollout checklist for SaaS teams
Make the change a short, repeatable procedure. First, enumerate every hostname that legitimately sends events to the property — check your tag deployment across the marketing site, app, docs, and any microsites, and write them down; the allowlist is only as safe as this inventory is complete. Second, create the Include hostname filter with that list and leave it in Testing, then watch Realtime and DebugView for a full traffic cycle to confirm no real host is being dropped. Third, activate it, and note the activation date so you know which historical ranges still carry pre-filter spam.
Fourth, schedule a recurring review tied to your data-quality cadence: whenever you launch a new legitimate domain, add it to the allowlist before you deploy the tag, and periodically confirm no stale hostnames remain. Done this way, the Include filter turns hostname hygiene from a reactive game of whack-a-mole into a one-line governance rule — approved domains in, everything else out — and your funnel, conversion, and attribution numbers stay anchored to traffic that could actually become a customer.
FAQ
What is GA4's Include hostname filter?
The Include hostname filter is a data filter, added to GA4 on September 21, 2026, that lets you define an allowlist of approved domains authorized to send event data to a property. Events reporting a hostname that is not on the list are dropped before they enter your reports. It is the inverse of the older Exclude hostname filter: instead of naming the bad domains one at a time, you name the handful of domains you own and everything else is rejected by default. For a SaaS company whose real traffic comes from a known set of domains — the marketing site, the app subdomain, maybe a docs host — an allowlist is a far tighter control than trying to enumerate every spam source.
How is the Include filter different from the Exclude hostname filter?
The Exclude filter, available since mid-2026, is a denylist: you list specific hostnames whose events should be discarded, and anything you did not name still gets through. That means every new ghost-spam domain or unauthorized mirror requires you to notice it and add another rule, so you are always one step behind. The Include filter flips the logic to a default-deny allowlist: only the domains you explicitly approve can send data, and every unknown hostname — including ones that do not exist yet — is blocked automatically. For data integrity the allowlist is strictly stronger, because it does not depend on you spotting each new offender.
How do I set up an Include hostname filter in GA4?
Go to Admin, open Data filters under the property's Data collection and modification settings, and create a new filter of type Hostname. Choose the Include (allowlist) condition, then enter each hostname your organization legitimately sends events from — your www marketing domain, your app subdomain, any tracked docs or blog hosts. Start the filter in Testing state so you can confirm it is not dropping legitimate traffic, verify against the debug and realtime views, then switch it to Active. Filters are not retroactive, so they only affect data collected after activation; historical spam already in the property stays until you segment it out in reporting.
Why does unauthorized hostname traffic corrupt SaaS analytics?
Because it inflates the top of your funnel with sessions that never came from a real prospect, which then distorts every conversion rate and attribution calculation downstream. Ghost referral spam sends fabricated hits that never touched your site, staging and localhost environments leak test events into production, and scraped or cloned copies of your pages fire your measurement ID from domains you do not control. Each of these adds users and sessions with no chance of converting, so activation rate, signup-to-trial conversion, and channel ROI all read artificially low. Filtering by hostname removes the events at the source instead of trying to reverse the damage in analysis.
Does the Include filter fix historical spam or affect attribution models?
It does neither retroactively. GA4 data filters only apply to incoming data from the moment they are set to Active, so any spam collected before then remains in the property and must be handled with report-level segments or comparisons. Going forward, a clean hostname allowlist improves attribution by removing phantom sessions that would otherwise be assigned to Direct or bogus referral channels, which sharpens the denominator in every conversion and channel report. It does not change how the attribution model distributes credit across legitimate touchpoints — it just ensures the touchpoints being modeled are real.