GA4 bot traffic: How to filter bots without losing real users

If you manage a Google Analytics 4 (GA4) property, there's a good chance bots are inflating your traffic numbers. According to the 2026 Imperva Bad Bot Report, automated bots accounted for 53% of all web traffic in 2025, the second consecutive year that bot activity outpaced human visitors. And those numbers are only accelerating, driven in part by AI-powered scraping tools and large language model crawlers that mimic real browsing behavior more convincingly than ever.

Sophisticated bots driving that growth don't announce themselves the way traditional crawlers do. They mimic real browsing behavior, generate legitimate-looking events, and slip past the built-in filters of Google Analytics without raising obvious red flags.

The good news is that a layered detection strategy — combining native tools from Google Analytics 4, Google Tag Manager client-side logic, and BigQuery behavioral analysis — can bring bot contamination under control. The less-discussed challenge is minimizing how many real users your filters catch in the process, because some tradeoff between bot coverage and false positives is inevitable. This post walks through each layer, explains what it catches and what it misses, and helps teams make informed decisions about where that tradeoff line sits.

How much of your GA4 traffic is actually bots?

Unlike traditional known crawlers that self-identify through their user agent strings, today's sophisticated bots use headless browsers, spoof screen resolutions, and rotate through residential proxy networks. They generate page views, trigger events, and inflate session counts, all while looking enough like a real user to evade the default protections in Google Analytics.

Cleaning up bot traffic means audiences built on verified human behavior perform better in ad platforms, engagement metrics become trustworthy benchmarks, and conversion rates reflect actual campaign performance. For GA4 360 customers managing enterprise-scale properties, getting bot contamination under control means every report, audience, and optimization decision is built on a stronger foundation.

We’ve seen this firsthand with clients: properties where suspicious traffic accounts for a significant share of total events, often unnoticed until someone examines the behavioral signals beneath the surface metrics.

What GA4's built-in bot filtering covers

Google Analytics 4 does include automatic bot filtering, and it handles the basics well. By default, Google Analytics properties exclude traffic from known bots and spiders identified through a combination of Google's own research and the International Spiders and Bots List maintained by the Interactive Advertising Bureau (IAB). This filtering runs in the background with no configuration required, removing the most common, self-identifying crawlers before they show up in your reports.

Beyond that baseline, Google Analytics 4 offers a few additional tools that can help isolate suspicious traffic. Hostname filters let you restrict reporting to valid domains, which blocks ghost spam from fabricated hostnames and filters out hits from development environments. Google Analytics now includes a native hostname filter available for both standard and 360 properties.

This can be implemented through Google Tag Manager using a hostname lookup table with a regex pattern matching your known domains, or monitored through Explorations in Google Analytics. Language filters can catch another category of bot traffic: crawlers that report malformed, missing, or nonsensical language settings, a common fingerprint of automated scripts.

Internal traffic filters round out the native toolkit. While their primary purpose is excluding your own team's visits, defining internal traffic properly creates a cleaner baseline dataset that makes genuine bot anomalies easier to spot.

These layers are useful starting points, but they rely on self-reported characteristics that sophisticated bots can spoof. To catch the traffic that slips through, you need detection logic that evaluates behavior instead.

How to tag bot traffic using Google Tag Manager (GTM)

The most effective client-side bot detection strategy starts with a simple principle: flag first, block later. Rather than immediately preventing suspicious traffic from firing tags, which risks silently dropping real user data, the better approach is to tag visitors as "bot" or "human" using a custom user property in Google Analytics 4, then use that classification for segmentation and analysis before making any blocking decisions.

The implementation runs through Google Tag Manager. A Custom JavaScript Variable evaluates several browser-level signals and returns a classification. The Google Tag is updated to include a user_type user property, ideally set through the dynamic event settings variable so it's included on all Google Analytics tags.

After publishing the Google Tag Manager container and defining the custom user property in Google Analytics 4, teams can build audiences and segments that include or exclude traffic based on the bot classification.

Your implementation team can use a Google Tag Manager Custom JavaScript Variable like this one to check for common bot signals:

function() {
  try {
    var ua = navigator.userAgent || '';
    var width = screen.width || 0;
    var height = screen.height || 0;
    var screenSize = width * height;

    // Bot signals
    var isHeadless = /HeadlessChrome|PhantomJS|Puppeteer|Headless/i.test(ua);
    var tinyScreen = width === 0 || height === 0 || screenSize === 1;
    var squareScreen = (screen.width === screen.height) && screen.width > 0;
    var badBrowser = /Chrome\/[1-6][0-9]\./.test(ua); // Chrome 69 or older

    // Safely check navigator.plugins (deprecated in modern browsers)
    var noPlugins = false;
    try {
      noPlugins = !navigator.plugins || navigator.plugins.length === 0;
    } catch (err) {
      // Ignore plugin read errors in restricted contexts
    }

    if (isHeadless || tinyScreen || squareScreen || badBrowser || noPlugins) {
      return 'bot';
    }
    return 'human';
  } catch (e) {
    return 'human'; // Fallback on error
  }
}

This covers the fundamentals, but more sophisticated detection can also factor in signals like marketing parameters in the URL, whether document.referrer is populated, user interactions such as mouse movements and touch events, and time on page. Layering these behavioral checks alongside the browser-level signals above gives teams a more complete picture of which sessions are likely automated.

Among browser-level signals, the lowest-risk checks are the navigator.webdriver property, which returns true when a browser is controlled by automation software, and user agent string inspection for known headless browser identifiers. Legitimate human users shouldn't trigger either under normal browsing conditions, which makes them a good starting point before layering in the behavioral signals above.

Additional signals like screen resolution anomalies, missing language settings, and outdated browser versions can strengthen the detection, but each adds false-positive risk. Test any multi-check variable thoroughly before scaling beyond monitoring-only mode.

Honeypot fields offer another high-confidence supplement. By adding a hidden form input (invisible to human visitors through CSS), any submission that fills it can be reliably classified as bot activity and integrated into the same GTM detection logic.

Using BigQuery to score and isolate bot sessions

Not every team is ready to change their site tagging, and not every bot problem requires it. The GA4 BigQuery export gives teams access to raw, event-level data that standard Google Analytics 4 reports don't surface, making it possible to score and segment bot-like sessions entirely through analysis. Plus, this flexibility lets you easily iterate on queries and reprocess historical data as needed.

A BigQuery-based approach rolls events into sessions and scores each one across multiple dimensions: device characteristics, landing hostname, referral source, traffic channel, engagement depth, session duration, event count, and key events. Sessions that cluster on several bot-like signals score higher, making them easy to isolate and investigate.

For teams already running GTM-based detection, BigQuery also serves as a validation layer. Comparing sessions flagged as "bot" through client-side logic against the behavioral patterns in the raw data confirms whether detection rules are catching the right traffic and helps calibrate thresholds over time.

Either way, the output is the same: a clear picture of how much of your traffic is likely automated, where it's coming from, and which mitigation path makes sense for your property. For measurement and analytics teams already using the BigQuery export, adding bot scoring to an existing pipeline is a relatively low-lift extension.

Why some popular GA4 bot filters create false positives

Most bot traffic guidance focuses on what to block. Equally important is what not to block. Aggressive filtering rules can quietly exclude real users, and that kind of data quality problem is harder to detect because the missing traffic never shows up in your reports.

Screen resolution filters are a common culprit. Values like 0x0 and perfect squares (1280x1280, 1600x1600, 2000x2000) are reliable bot signatures. But some widely shared filter lists also include resolutions like 390x2532 and 375x2436, which match real Apple mobile devices currently in widespread use. Filtering on those values silently drops traffic from popular smartphones and tablets. Any screen resolution filter should be validated against current device specs before deployment.

Geographic signals are another area where context matters. City ID 1015724 in Google's geographic targeting database maps to Council Bluffs, Iowa (home to a major Google data center hub). Desktop traffic from that location is often non-human. Filtering on this signal can be useful, but Council Bluffs is just one of many data center cities, and expanding geographic filters broadly risks blocking legitimate users.

The subtlest false-positive trap involves Apple's iCloud Private Relay. When an iCloud+ subscriber browses in Safari on macOS with the stricter "Use country and time zone" location setting, their traffic routes through a two-hop proxy that anonymizes their IP address. In Google Analytics, these users show up as Macintosh, direct traffic, no city, and a broad state-level region like New York. Every one of those signals individually appears on common bot filter lists. A combined filter targeting that exact pattern will catch every privacy-conscious Mac user in the New York metro area along with the data center bots it was designed for.

Calibration matters more than coverage. Every filter rule should be tested in a Google Analytics Exploration or validated through BigQuery before going into production. The goal is clean data, not just less data, and that distinction requires ongoing attention as both bot behavior and privacy technology continue to evolve.

Getting bot traffic under control in your GA4 property

A layered approach combining native Google Analytics filters, GTM-based client-side detection, and BigQuery behavioral analysis gives teams the most reliable path to cleaner analytics data. But the right combination of layers depends on the size of the property, the volume of suspicious traffic, and how the data feeds into downstream systems like ad platforms and audience activation tools.

Adswerve has helped brands and agencies across industries assess the impact of bot traffic on their analytics and implement remediation strategies tailored to their specific Google Analytics 4 and Google Tag Manager setups. If bot traffic is showing up in your reports, or if you suspect it might be but aren't sure how much, we'd love to hear from you.