GA4 Source Groups and hostname filters: cleaner reports without losing real bookings

GA4's Source Group dimension helps standardise messy source names. Hostname filters control which domains can send data into your reports. They solve different problems, and a filter needs more care than a reporting change.

I work with tour operators and D2C brands whose booking and advertising reports often disagree. A useful first step is to separate inconsistent labels from unwanted traffic. Neither one tells you, by itself, whether an ad caused a sale.

Source Group is populated automatically

Google introduced Source Group on 11 June 2026. It groups variations of common platform source names into a consistent reporting value and populates historical data too. You can compare it with the original Source dimension to see what has been consolidated. The Google Analytics release notes describe the change.

This is an automatically populated dimension. It is different from building a custom channel group with your own rules for Paid Social, Email or other channels. Source Group also does not repair missing events, rewrite your campaign tags or establish advertising attribution.

Start by comparing Source, Source Group and Source Platform in the reports where they are available. Check unfamiliar values against your campaign tagging. Keep a consistent UTM convention for new links, even when the reporting layer makes older variations easier to read.

Hostname filters support both Include and Exclude

Hostname filters live in Admin, under Data filters. Exclude filters remove traffic from specified hostnames. Since 21 September 2026, Include filters can also limit incoming data to approved hostnames. The earlier version of this article described the feature as exclude-only; that is no longer current.

These filters affect incoming data, not historical reports. Data discarded by an active filter cannot later be recovered in Analytics or BigQuery. For a reversible reporting view, use a report filter instead. See Google's data-filter guidance.

One detail matters when you review coverage: Google says hostname Include filters do not apply to Measurement Protocol events, and they block events with an empty hostname. Review those collection paths separately rather than assuming an allowlist covers every event source.

Inventory the booking journey before filtering

“Anything outside our main domain is junk” is a risky rule for a tour operator. A visitor may move from the marketing site to a legitimate booking engine or checkout on another domain. An online store may also have payment or account journeys that need investigation before you exclude their data.

• List the hostnames actually sending events. Identify the main site, legitimate subdomains, booking and checkout domains, staging sites and unknown sources.
• Follow a real booking or order journey with your team. Check where the relevant events are collected and which domains belong in this property.
• Investigate unfamiliar hostnames. Confirm ownership and purpose before classifying them as unwanted traffic.
• Keep a written list of approved domains and the reason each belongs. Review it when you change booking providers, launch a subdomain or replace checkout.

The aim is useful measurement across the customer journey. A shorter hostname list is not an outcome on its own.

Test first, then activate deliberately

Begin with a report-level comparison so you can see what the proposed rule would remove. Where the filter's testing state is available, use it and review its results before activation. Check legitimate purchases, lead submissions and booking events, not just session totals.

Have a second person review an Include list if it spans several domains. Check any other active filters too: Google applies the union of active Include filters first, then the active Exclude filters. An exclusion can still remove events from an included hostname.

What cleaner data can tell you

Once source names are easier to interpret and unwanted traffic has been investigated, comparing periods becomes more useful. Keep the filter activation date visible so a change in collection is not mistaken for a change in demand.

Then reconcile advertising reports with your booking or store backend. Differences can come from attribution, consent, date conventions, refunds and tracking faults. The booking measurement guide explains that comparison, and MER vs ROAS explains why total revenue divided by spend is a business-efficiency measure rather than proof of incremental advertising revenue.

Start with the source and hostname inventory. Make reporting changes first, verify the legitimate customer journeys, then activate collection filters only when their effect is understood.