GA4 now has a hostname filter — and if you came from Universal Analytics, your first instinct might be to reach for it the same way you used hostname filters in UA views. Before you do that, there are two things worth understanding up front: where it actually lives in GA4's admin, and what it's actually good for. It's a more limited, more reactive tool than UA's view-level filtering, but it's genuinely useful in the specific scenarios it was built for.
TL;DR — GA4's hostname filter lives under Admin > Data Collection & Modification > Data Filters (filter type: Web hostname traffic). It's a reactive tool — you configure it using match statements against known hostnames, so it's most useful when your measurement ID was deployed somewhere you can't remove it from, or when you want to exclude known sources like staging environments. It is not a UA view replacement and won't proactively catch unknown spam sources.
What Is the GA4 Hostname Filter?
The GA4 hostname filter is a property-level setting that controls which hostnames are allowed to send data into your GA4 property. You define an approved list of domains — for example, www.yourdomain.com and yourdomain.com — and GA4 drops any incoming hit that originates from a hostname outside that list.
You'll find it under Admin > Data Collection & Modification > Data Filters. Click Create filter and select Web hostname traffic as the filter type. From there you configure a filter operation (Include or Exclude) and define one or more hostname conditions using match types — exactly matches, contains, begins with. Hits that match an Exclude filter are dropped before they reach your reports, Explorations, or BigQuery export; hits that match an Include filter are the only ones allowed through.
This is a welcome addition. GA4 has always had internal traffic filters (via IP address exclusion or the traffic_type parameter) and referral exclusion lists, but no native way to filter data by hostname until now. UA had this capability built into views, and its absence in GA4 was a genuine gap. GA4 data streams feed a single property, so without hostname filtering, any hit that knows your measurement ID can send data into your property.
One important caveat up front: this is a reactive tool. The match conditions (exactly matches, contains, begins with) mean you need to know the hostname you want to filter before you can configure it. It's most useful in two scenarios: your measurement ID was deployed on a domain you don't control and can't remove it from, or you want to explicitly exclude traffic from known sources like staging environments. For a deeper look at what can go wrong in a GA4 implementation, our GA4 audit surfaces these issues systematically.
Why This Feature Matters for Data Quality
Ghost traffic and referral spam have been around since the Universal Analytics era. These are hits sent to your analytics property from sources that were never real visitors to your site — fabricated sessions generated by bots or malicious scripts designed to inflate your traffic numbers, pollute your source/medium reports, or simply cause chaos in your data.
The mechanism is straightforward: a bot scrapes your GA4 measurement ID from your page source, then sends hits directly to Google's Measurement Protocol endpoint using that ID. GA4 has no way to know those hits didn't originate from a real browser session on your domain — unless you tell it which hostnames to trust.
Without the hostname filter, you'll see sessions appearing from hostnames you don't own. You'll see impossible traffic spikes in overnight reporting windows. You'll see referral sources that don't exist driving "conversions." All of that contaminates your acquisition reports, your conversion rate calculations, and your audience lists. When data like that makes its way into a Data Studio (formerly Looker Studio) dashboard that a marketing director is using to make budget decisions, the downstream consequences get expensive fast.
Reviewing your hostname breakdown is something we check on every GA4 audit — unknown or unexpected hostnames in the data are a reliable signal that something went sideways in the implementation.
The two most common scenarios where hostname filtering actually helps:
- Unauthorized deployment you can't control — your GA4 measurement ID was placed on a domain you don't own (implementation error, third-party platform, partner embed, white-label checkout). You can't remove the tag, but you can exclude that hostname's hits from your property once you know the hostname.
- Known internal sources skewing data — staging environments, dev servers, or localhost traffic using your production measurement ID. Because you know the hostname (
staging.yourdomain.com,localhost), you can exclude it explicitly.
What this tool doesn't do well: catch unknown bad actors. If a spam source you've never seen before starts sending hits using your measurement ID, you won't know to filter it until after it's already in your data. This is a targeted, reactive safeguard — not a blanket protection layer. For any business running a serious GA4 implementation, it's worth having configured, but set expectations accordingly.
This Is Not a Replacement for UA Views
Here's where I want to be direct: the GA4 hostname filter is not a views equivalent, and attempting to use it as one will fail. I understand the impulse — UA power users had views that were genuinely powerful reporting tools. You could create a view for your main site, a view for a specific subdirectory, a view for a language region, a view that excluded internal traffic, and a raw unfiltered view for QA. Losing that functionality when GA4 launched was a real pain point.
But the hostname filter doesn't restore views. It can't. Here's why.
In UA, a view was a separate reporting environment with its own filter set, its own goals, and its own data scope. Filters applied at the view level created a data sandbox — the underlying raw data was untouched; the view just presented a filtered interpretation of it. You could have five different views of the same property, each showing a different slice of reality, all running simultaneously. The hostname filter in those views meant "in this view, only show sessions where the hostname matched."
GA4 does not have views. The hostname filter in GA4 operates at the property level, which means it affects every single hit flowing into your property before they're stored, reported, or exported. It's not a reporting lens — it's a gate. There's one gate, and everything that passes through it enters your property. There's no "filtered version" and "unfiltered version" existing side by side.
If you enable the hostname filter to include only www.yourdomain.com, you will block hits from all other hostnames for all reporting, all Explorations, and all BigQuery exports — permanently, retroactively from the point of configuration. You can't then create a second "view" where those blocked hostnames are visible again. The data is gone from the property.
Teams that try to use GA4's hostname filter the way they used UA's hostname view filters end up with the same broken setup they had before, just with fewer data sources. The correct mental model is: the hostname filter is a property-wide security boundary, not a reporting segmentation tool. If you want to segment traffic for reporting purposes in GA4, you use comparisons, audiences, and custom dimensions — not filters.
The rule: Use the GA4 hostname filter to block data you never want in your property — spam, bots, staging traffic, unauthorized sources. Never use it to create reporting segments you want to analyze separately. Those two goals require fundamentally different tools.
Understanding GA4 Data Streams and Measurement IDs
To understand why GA4 can't replicate UA views, you need to understand how GA4's data architecture actually works — specifically the relationship between properties, data streams, and measurement IDs.
In GA4, a property is the top-level container for your analytics data. One business typically has one GA4 property (though you might have separate properties for different products or regions). Below the property level, you have data streams.
A GA4 data stream is the channel through which data flows into your property. You can have a web data stream, iOS app data streams, and Android app data streams — each is a distinct pipe into the same property. Each web data stream has exactly one measurement ID (the G-XXXXXXXXXX you add to your GTM tag or your page's gtag snippet). That measurement ID is what tells GA4 "this hit belongs to this property."
This is where the architecture diverges from UA in a critical way. In UA, the tracking ID (UA-XXXXXXXXX-1, UA-XXXXXXXXX-2, etc.) was tied to a view — different views had different IDs, so you could literally send the same pageview to multiple views by firing multiple tracking codes. GA4 doesn't work that way. Your measurement ID is tied to a data stream, which feeds your property directly. There's no layer between the stream and the property where separate reporting environments can be created.
When you configure the hostname filter, you're telling the property-level data intake: "only accept hits where the hostname matches this list." That's a single, property-wide rule. It's enforced before data reaches any reporting layer. There's no fork in the road where filtered and unfiltered versions diverge.
Understanding this architecture is also why your Google Tag Manager setup matters so much. Your GTM container deploys your measurement ID — it's the mechanism that actually sends hits to GA4. Keeping your GTM tags well-organized, using proper triggers, and avoiding duplicate measurement ID deployments across environments are all part of the same data quality story that the hostname filter addresses. If you're deploying the same measurement ID on your production site, your staging environment, and your dev environment, the hostname filter is your safety net. But the cleaner solution is to have separate measurement IDs per environment, with the production ID reserved exclusively for production data.
How to Configure the Hostname Filter in GA4
The hostname filter lives inside GA4's Data Filters — not as a standalone setting. Here's the exact path:
- Open GA4 Admin (gear icon, bottom left).
- Under the Property column, click Data Collection & Modification, then Data Filters.
- Click Create filter.
- Choose Web hostname traffic as the filter type.
- Give the filter a descriptive name (e.g., Exclude Staging).
- Set the Filter operation — typically Exclude for blocking specific known hostnames.
- Add one or more hostname conditions. For each condition, select a Match type (exactly matches, contains, begins with) and enter the hostname value.
- Click Create to save.
Before you configure it, pull a hostname report first. In GA4 Explorations, create a free-form exploration with Hostname as your dimension and Sessions as your metric. This shows you every hostname currently sending data into the property — which is exactly the information you need to know what to filter. Because the matching is string-based, you must see the hostname before you can exclude it.
After enabling:
- Monitor session volume for 24–48 hours to confirm you haven't inadvertently blocked a legitimate source.
- Check DebugView to confirm production hits are still flowing correctly.
- Revisit the hostname report after 7 days to see if any new unexpected hostnames have appeared.
One note on Measurement Protocol hits: server-side events may not carry a hostname field the same way client-side hits do. If you're sending server-side events from a CRM, fulfillment system, or sGTM container, verify those hits aren't caught by the filter before you finalize. Test using debug_mode: true in GA4 DebugView.
When to Use It (and When Not To)
Let's make this concrete with a quick decision guide.
Use the hostname filter when:
- Your GA4 measurement ID was deployed on a domain you don't own or control — an implementation error, a partner's site, a white-label checkout — and you can't remove the tag. You know the hostname, so you can exclude it.
- Your production measurement ID is also running on a staging or dev environment (e.g.,
staging.yourdomain.com). You know the hostname, so you can exclude it cleanly without touching the staging environment itself. - You can see specific unwanted hostnames already in your data and want to stop them from contributing going forward.
Do not use the hostname filter when:
- You want to create segmented "views" of your data — by subdirectory, by country, by user type. The hostname filter affects all data across the property; it's not a reporting segmentation tool. Use comparisons, audiences, and custom dimensions in GA4 Explore instead.
- You're hoping to proactively block unknown spam sources. Because matching requires you to specify known hostname strings, you can only filter what you've already seen. This tool won't catch a new bot domain before it hits your property.
- You want a raw unfiltered backup alongside a filtered view. GA4 doesn't have parallel property views — if you need an unfiltered dataset, use a separate GA4 property or rely on BigQuery exports.
The question to ask: "Do I know the specific hostname I want to block, and do I never want that data in my property?" If yes, configure the filter. If the problem is unknown or you want to segment rather than block, you need different tools.
If you're unsure how your property is currently configured and whether hostname filtering would help your specific setup, that's exactly what a structured GA4 audit is designed to answer. We review your data streams, filter configurations, traffic quality, and event setup against best practices — and give you a clear action plan. For broader help on standing up a clean GA4 property from the start, see our GA4 implementation services.
Also worth reading: our post on common GA4 mistakes covers several data quality issues that hostname filtering alone won't solve, and our GA4 best practices for 2026 walks through the full stack of configuration decisions that keep a property trustworthy over time.
Frequently Asked Questions
The GA4 hostname filter is a data filter (Admin > Data Collection & Modification > Data Filters) that filters event data based on the hostname. You create a filter of type "Web hostname traffic," set it to Include or Exclude, then add hostname conditions using match types like exactly matches, contains, or begins with. It's primarily useful when your GA4 measurement ID is deployed somewhere you don't control, or when you want to exclude traffic from known sources like staging environments.
No. The GA4 hostname filter is not a view replacement and should not be used as one. In Universal Analytics, views were separate reporting environments with independent filter sets. GA4 does not have views — it has data streams. The hostname filter operates at the property level and affects all incoming data from the moment it's enabled. It cannot create segmented reporting environments, isolate traffic by subdirectory, or replicate any of the segmentation use cases that UA views supported. If you need to analyze traffic segments separately in GA4, use Explorations with comparisons, audience filters, and custom dimensions instead.
In GA4, go to Admin, then under the Property column click Data Collection & Modification, then Data Filters. Click Create filter and choose Web hostname traffic. Name the filter, set the filter operation (Include or Exclude), and add hostname conditions using a match type (exactly matches, contains, begins with) and the hostname value. Before creating it, run a hostname report in GA4 Explorations to see which hostnames are currently sending data — this is a reactive tool, so you need to know the hostname before you can filter it. Monitor session volume for 24–48 hours after enabling.
Is Your GA4 Data Clean?
Our GA4 audit identifies data quality issues — hostname pollution, filter gaps, tracking errors — and fixes them fast. Get a clear picture of what your property is actually capturing.
Schedule a Free Call