A strange domain in Analytics can make a clean dashboard feel contaminated overnight. The instinct is to paste that hostname into a filter and move on. In GA4, that shortcut can quietly turn the same sessions into Direct traffic while leaving every event in the property. The first job is diagnosis, not exclusion.

Four problems that look like referral spam

  • A legitimate referral: a real person followed a link from another site. Excluding it would hide useful acquisition information.

  • Broken journey attribution: your own domain, authentication service, or payment provider interrupts a session and becomes the apparent referrer. Fix cross-domain/session design or list a legitimate unwanted referral.

  • A crawler that actually visits the site: server/CDN logs contain requests. Analytics may automatically exclude known bots, but unknown automation can still execute tags. Mitigate at the edge/site when appropriate.

  • Injected measurement events: no corresponding web request exists, or event/hostname/user-agent patterns are impossible. Investigate Measurement Protocol and server-side collection credentials.

Start with evidence, not a domain blacklist

  • In Reports → Acquisition → Traffic acquisition, inspect Session source / medium over a narrow date range and compare it with the previous period.

  • Add dimensions such as hostname, landing page, country, browser, device category, and event name. Impossible combinations often distinguish injection from real browsing.

  • Compare session starts, engaged sessions, engagement time, page views, key events, and revenue. A “spam” label based only on a high session count is weak evidence.

  • Check Realtime/DebugView only for current tests; use Explorations or BigQuery export for deeper event-level investigation.

  • Correlate timestamps and landing paths with web server, CDN, WAF, consent-platform, and tag-manager logs. GA4 is a measurement system, not the authoritative request log.

When unwanted referrals is the correct tool

Use the feature when a domain participates in a legitimate journey but should not receive acquisition credit—for example, an external payment processor that sends customers back after checkout. It can also help with a website-managed recovery/authentication flow. For your own domains, configure cross-domain measurement correctly first; GA4 already recognizes common self-referral cases.

Configure the GA4 list

  • Open Admin → Data collection and modification → Data streams.

  • Select Web, then the intended web stream. Confirm the property and measurement ID before editing.

  • Open Configure tag settings → Show all → List unwanted referrals.

  • Choose the narrowest match type, enter only the domain identifier, add another condition if needed, and save. Google evaluates the conditions with OR logic and currently allows up to 50 per web stream.

  • Record the change time, reason, owner, and previous configuration. Allow processing time, then compare new sessions rather than expecting old reports to change.

What changes after saving

  • Matching events remain collected; the referrer is ignored as a traffic source.

  • Attribution may fall back to an earlier eligible source or appear as Direct depending on the journey and attribution rules.

  • Returning users can still show the old source because previously attributed sessions and lookback behavior do not vanish immediately.

  • The setting is stream-scoped and forward-looking. It does not clean historical rows or block the named site from visiting yours.

If real bots are loading the website

  • Verify requests in CDN/server logs by timestamp, path, status, IP/ASN, request rate, and user agent. User-agent strings alone are trivial to forge.

  • Protect expensive endpoints with rate limits, caching, bot management, challenges, or WAF rules proportionate to the evidence. Avoid blocking legitimate search crawlers and accessibility/privacy tools.

  • Do not add client-side JavaScript that trusts document.referrer as a security control; referrers can be absent or manipulated, and code still downloads before it decides.

  • Validate the effect in infrastructure metrics first, then in GA4. A lower Analytics count without lower request/resource usage is not a successful bot mitigation.

If Measurement Protocol injection is possible

A GA4 measurement ID used by browser tags is visible by design. A Measurement Protocol api_secret is not. Google explicitly warns that exposing it lets unauthorized parties send arbitrary or spam events that corrupt reporting.

Audit application and deployment code

application repositorybash
rg -n --hidden \
  --glob '!node_modules/**' \
  --glob '!.git/**' \
  'api_secret|/mp/collect|region1\.google-analytics\.com'

How to use the search safely

  • rg -n --hidden includes hidden configuration files and prints line numbers; the globs skip dependency and Git object trees.

  • The pattern finds likely Measurement Protocol endpoints and secret parameter names, not every secret-management path. Search CI variables, cloud secret stores, deployed artifacts, and logs separately.

  • Do not paste matches into tickets or chat. A discovered secret should be treated as compromised, rotated in GA4, and removed from history/logs using the organization’s incident process.

  • Keep new secrets server-side in an approved secret manager. Never embed them in browser JavaScript, mobile applications, public repositories, URLs, or analytics debug output.

Contain and verify

  • Create a replacement Measurement Protocol API secret in the correct data stream, update authorized server senders, and validate them.

  • Revoke/delete the exposed secret after the controlled cutover. Account for retries, queues, scheduled jobs, and regional endpoints.

  • Monitor event names, hostname values, geography, and volume after rotation. If contamination continues, revisit other senders and tag deployments rather than assuming the rotation failed.

  • Document the polluted date range so analysts do not mistake a sudden post-rotation drop for a business change.

GA4 data filters are not referral-domain filters

GA4 property data filters are designed for internal traffic and developer/debug traffic. They have Testing, Active, and Inactive states, and active exclusion affects processed data going forward. They are not a replacement for the old Universal Analytics custom campaign-source filter shown in the original 2015 article.

Handle historical pollution honestly

  • GA4 does not retroactively remove collected events when you edit unwanted referrals or data filters.

  • Create a saved Exploration/report comparison that excludes the diagnosed source, event signature, or other defensible conditions, and label its limitations.

  • For exported BigQuery data, build a documented cleaned view rather than deleting raw evidence. Preserve the raw table and make the transformation reviewable.

  • Annotate dashboards and stakeholder reports with the affected interval, estimated impact, query logic, and remediation timestamp.

  • Do not claim a clean total when the signal cannot reliably distinguish real users from injected events; report a range or exclude the metric with an explanation.

Why a referral still appears after configuration

  • The condition does not match the normalized domain; inspect exact values and use the narrowest correct operator.

  • You edited another property or web stream. Reconfirm property ID, stream name, and measurement ID.

  • Reports include sessions attributed before the change or returning-user attribution influenced by an earlier session.

  • Processing/reporting latency means a new configuration is not an instantaneous historical rewrite.

  • The suspicious value is coming from a custom event parameter or Measurement Protocol payload rather than the automatic referrer field.

  • The source is legitimate traffic, and the apparent anomaly came from date range, thresholding, consent effects, or comparison logic.

A small prevention checklist

  • Keep Measurement Protocol secrets server-side, rotate them periodically, and restrict who can view/change data-stream configuration.

  • Separate production and development measurement where the organization’s governance requires it; test filters before activation.

  • Maintain cross-domain configuration for checkout, authentication, and owned-domain journeys.

  • Alert on sudden changes in event volume, novel event names, impossible hostnames, and key-event/revenue anomalies.

  • Retain server-side request evidence long enough to investigate analytics anomalies within privacy and legal policy.

Primary references