On September 21, 2026, Google shipped a button that can destroy your data without anything ever showing up in a report. It is the Include mode of the GA4 hostname include filter, and Google frames it as the end of ghost spam “with minimal maintenance.” The reality is trickier: this filter does not block the main spam vector, and any legitimate domain you forget to list has its hits wiped at collection, invisible in reports and in the BigQuery export alike, with no way to recover them. Before you touch this setting, here is what it actually does, what it does not, and the protocol to turn it on without shooting yourself in the foot nine weeks out from Black Friday.
GA4 hostname include filter: what changed on September 21, 2026
Since June 11, 2026, GA4 let you filter traffic by hostname in Exclude mode: you listed the domains to block, one by one, and everything else passed through. That is blocklist logic, reactive, fed as you spot intruders.
Include mode flips it. You declare, once and for all, the list of allowed domains, your allowlist, and GA4 refuses anything not on it. On paper it is cleaner: no more chasing every new spammer. In practice, you just turned a wide net into a blind wall. Anything you forgot to list is gone, and gone for good.
The two exceptions written into the release note
Google documents two behaviors of the filter that deserve a pause, because they are what decide whether the tool keeps its promise.
”Measurement Protocol events are not filtered”
It is spelled out in the release note: the hostname filter does not apply to events sent via the Measurement Protocol. Yet that is exactly the path a large share of ghost spam takes, traffic injected straight into your property by someone who grabbed your measurement ID. In other words, if your spam arrives through the Measurement Protocol, your allowlist will never see it. You think you are closing the door; there is no wall around it.
Let’s be honest here, because sources disagree. Some practitioners describe ghost spam as pure Measurement Protocol injection; others pin it on a plain reuse of your measurement ID in a gtag.js copied onto another domain. Google does not settle it, and the two routes call for different fixes. The hostname filter catches the second one (a real web hit from a foreign domain does carry a hostname) but not the first. The only way to know which one is hitting you is to look inside your own property. For what the Measurement Protocol is and why its exemption matters, our guide on the GA4 Measurement Protocol and the CRM loop covers the basics.
”Empty hostnames are blocked automatically”
Google’s second note: empty hostnames are blocked by default, “such as gtag.js traffic.” That parenthetical is ambiguous, and ambiguity is expensive when deletion is permanent. Literal reading: only hits with no hostname at all are affected. Restrictive reading: some of your legitimate gtag.js traffic could land in that bucket if the hostname is not resolved at collection time. Until Google clarifies, treat this sentence as an unknown to verify, not a guarantee. A (not set) hostname in your reports is exactly the symptom to watch for here.
The real risk: Include deletes, Exclude lets through
Here is the nuance Google does not put forward, and the one that should drive your decision. A mistake in an Exclude filter and a mistake in an Include filter do not carry the same cost at all.
If you get an Exclude wrong (you forget to block a spam domain), the worst that happens is noise entering your reports. Annoying, but recoverable: the data is there, you can segment it, exclude it after the fact in an exploration, filter it in BigQuery. Nothing is lost.
If you get an Include wrong (you forget to allow a legitimate domain), that domain’s data is destroyed at collection. It never enters. It is nowhere: not in reports, not in the Data API, not in the BigQuery export. You cannot recover it, because it never existed on Google’s side. And since the filter is not retroactive, turning the allowlist on does not touch the past, but every day it runs incomplete digs a permanent hole.
| Criterion | Exclude filter | Include filter (allowlist) |
|---|---|---|
| Logic | Blocklist: blocks what you name | Allowlist: blocks everything else |
| Cost of a mistake | Spam passes, segmentable later | Legitimate data destroyed, unrecoverable |
| Reversibility of the mistake | Yes, data is still collected | No, nothing is collected |
| Maintenance | Ongoing, at each new intruder | One-off, but exhaustive inventory required |
| Good use case | A few known parasite domains | Stable, perfectly known domain scope |
A GA4 hostname include filter is therefore not an “Exclude but better.” It is a sharper tool, reserved for properties whose domain scope you know down to the hostname.
The 5-step activation protocol
If you decide to move to Include, do not do it blind. Here is the method to build a complete allowlist and validate it before it cuts anything.
Step 1: inventory every legitimate hostname over 12 months
This is the step that makes or breaks it. You cannot allow what you have not listed, so list everything. If you have the BigQuery export, this query aggregates every hostname seen over a year, with its volume and its first and last dates:
SELECT
device.web_info.hostname AS hostname,
COUNT(*) AS events,
MIN(PARSE_DATE('%Y%m%d', event_date)) AS first_seen,
MAX(PARSE_DATE('%Y%m%d', event_date)) AS last_seen
FROM `your_project.analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20250922' AND '20260922'
GROUP BY hostname
ORDER BY events DESC
Without the export, rebuild the same inventory in a free-form exploration with the Hostname dimension in rows and event count as the value, over the longest range available. This inventory query is a natural eleventh to add to your toolkit: see our essential BigQuery queries for GA4 and, if the export is not wired up yet, our GA4 BigQuery export guide.
Then hunt the usual forgotten ones: subdomains (blog, checkout, help, app), your campaign landing domains, translated or cached versions served by Google, your staging environments carrying the same container, and your app streams if the property is mixed. A low-volume hostname over twelve months is not necessarily noise: it can be a campaign landing page that only runs six weeks a year.
Step 2: set the filter to Testing, 7 to 14 days
GA4 offers a Testing state that applies the filter without deleting data: it simply tags what would have been filtered. Use it, it is not optional. And let it run longer than the 24 to 48 hours often advised: aim for 7 to 14 days. The reason is simple, you need to cover at least one full weekly cycle and ideally a campaign launch, otherwise episodic domains never show up in the test window and you will discover them the day you have deleted them.
Step 3: read the “Test data filter name” dimension
During the test, GA4 fills the Test data filter name dimension on events that would have been filtered. Open an exploration, cross that dimension with Hostname, and look at what would have dropped. Every hostname listed here is a decision to make: a forgotten legitimate one to add to the allowlist, or a genuine unwanted one to let filter. Do not switch over while that list still holds a single domain you are unsure about.
Step 4: verify the unknowns in your own property
Google does not document everything, and on an irreversible setting, the unknown is a risk. Three questions stay open, so test them at home rather than trusting an invented answer. Does matching run on the exact hostname, or are subdomains included automatically? How are Data Manager API events handled, the ones now carrying Shopify server-to-server purchases since July 2026? And app streams in a web-plus-app property? The method: isolate each case in Testing and read the Test data filter name before concluding. On server-to-server handling, our Measurement Protocol vs Data Manager API comparison and our native Shopify GA4 server-side guide give the context.
Step 5: build in the operational constraints
Three limits to know before relying on this filter. You are capped at 10 data filters per property, and that quota is shared with your internal and developer traffic filters. You need the Editor role to create or enable a filter. And the filter is not retroactive: it does not clean history, it only acts on future collection. The hostname filter is precisely the new item to add to any audit checklist: see our 11 GA4 configuration mistakes to fix.
When you should NOT move to Include
My take as a practitioner: for many properties, Exclude mode stays the right call, and Include is a trap. Stay on Exclude if you are in any of these cases.
You run a cross-domain setup or several active subdomains, where the inventory keeps moving. Your property is fed by multiple sites you do not all control. You are an agency managing properties whose client domain launch calendars you do not know. Your property is mixed web plus app, where the filter’s behavior is undocumented. And above all, the rule that trumps the rest: never move a property to Include within eight weeks of a commercial peak. The risk of destruction far outweighs the benefit of slightly cleaner reporting. A misconfigured Include filter also becomes a cause of missing data that no diagnosis will surface, since the data does not exist: that is exactly the scenario in our article on GA4 missing data: Google bug or your tracking?.
What it means for the Black Friday season
We are about nine weeks from the peak. Through October and November, your teams multiply landing pages, campaign domains, one-off operations. That is precisely the period when an allowlist frozen in late September goes stale, and when every forgotten domain destroys data over the most expensive commercial window of the year. The math is simple: the gain of clean reporting is not worth the risk of permanently losing your November 28 conversions. If you are prepping for the peak, park this project for later and focus on the essentials with our Black Friday 2026 tracking checklist.
Conclusion: who carries the risk
On September 20, Google published a page reminding advertisers that its invalid-traffic filters are not enough against fake leads, and that validation falls back on the advertiser. The hostname Include filter follows the exact same pattern: Google provides the control, you carry the cost of the error. The difference is that here the error is irreversible. An incomplete allowlist does not get corrected, it leaves a permanent hole in your history.
So before you hit Activate, ask yourself a single question: do you truly know, down to the hostname, every legitimate domain that feeds your property? If the answer is not a clear yes, stay on Exclude, do your inventory, test for two weeks, and keep Include mode for the day your scope is stable and documented. Slightly noisy reporting can always be cleaned. Data that was never collected cannot.