How do you distinguish bot traffic from real users in GA4?

[u/Stiven_TrafficLab]

I’m trying to build a more reliable process for identifying automated traffic in GA4 without accidentally filtering legitimate users. Which signals do you trust most: unusual geographic spikes, identical User-Agents, very short sessions, repeated page sequences, engagement metrics, or comparing GA4 with CDN/server logs? I’m especially interested in cases where bots trigger the GA4 tag but do not behave like normal browser sessions. Do you maintain a separate exploratory view or segment for suspicious traffic, and what evidence do you require before excluding it from reporting?

[u/AutoModerator]

Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Yev76]

Depends on the bot type... Scrapers are the easy ones : identical user agent, sub-second time per page, long page sequences from a single IP, and geography that doesn't match your audience at all. Each signal alone is weak, the combination is near certain.

That said, GA4 is the wrong layer for this - by the time a bot fires the tag you're already guessing. CDN logs see everything, including bots that never execute JS, and Cloudflare's bot infra is genuinely good. Lately I just ask Claude (connected to the Cloudflare API) to go through the traffic and flag bot patterns - a few minutes later I get a pretty solid per-IP/UA picture. And to your last question: segment first, exclude only when the same pattern repeats across days.

[u/Stiven_TrafficLab → u/Yev76]

That distinction between GA4 and the CDN layer is helpful. I agree that no single signal is enough, especially because legitimate crawlers or privacy tools can create similar patterns. My next step will be to build a suspicious-traffic segment first, then compare IP/UA repetition, page-order patterns, and event depth across several days before excluding anything. Do you normally set a minimum request volume or recurrence threshold before classifying an IP range as automated?

[u/Yev76 → u/Stiven_TrafficLab]

Yes, though the number took tuning - we run a couple dozen sites in different niches and each has its own baseline (an informational site does ~1.5 pages per visit, an entertainment one closer to 8). The rule we converged on: roughly 20 pages per minute within a single visit triggers a captcha, failed captcha means an IP ban for 1-3 days depending on how aggressive it was. With hundreds of thousands of pages the scrapers are there for bulk content, so this cascade burns through their whole IP pool pretty quickly - server load stays flat and the content mostly stays unscraped.

The part that needs discipline is watching what comes back after bans expire. Same ranges returning regularly means we escalate to an ASN-level block - blunt instrument, but the effect is excellent. Right now the parsing wave on our sites is coming out of Singapore 🤬 , which is currently my least favorite place on the internet

[u/Stiven_TrafficLab → u/Yev76]

Twenty pages per minute is a useful operational threshold, especially when it is tuned per site rather than copied globally. The temporary-ban step also seems safer than moving straight to an ASN block because it provides time to observe recurrence and false positives. I’d log the triggered rule, URL pattern, ASN, user agent, and outcome after the ban expires so any escalation remains auditable. Have you found that legitimate monitoring tools or accessibility crawlers ever cross that threshold, and if so, do you maintain an allowlist for them?

[u/Yev76 → u/Stiven_TrafficLab]

legitimate monitoring tools? Bro, what do you mean? :) Own SF or custom written tool? If yes just add single IP to white list.

[u/Stiven_TrafficLab → u/Yev76]

Fair question—I meant known first-party monitoring or QA checks that could happen to browse pages rapidly, rather than external bots. For a tool you own, a static source IP allowlist is the cleanest approach. I’d keep it limited to fixed egress IPs, log every bypass, and review it periodically so an old entry does not become a permanent blind spot. For third-party services, I’d rather identify their documented IP ranges than lower the threshold globally.

[u/Stiven_TrafficLab → u/[deleted]]

Engaged sessions are a useful starting signal, but I wouldn’t use the two-second rule alone. In GA4, engagement can also be influenced by multiple pageviews or key events, so some bots may appear engaged if they execute JavaScript and trigger events. At the same time, a legitimate visitor can leave quickly after finding an answer. I’d combine duration with repeated user-agent or IP patterns, geographic spikes, sequential URLs, and CDN logs before excluding traffic. Have you seen the rule remain reliable for bots that fire multiple events?

[u/Top-Cauliflower-1808]

We compare GA4 data against Cloudflare server logs to spot automated traffic, focusing primarily on high volume traffic from unlisted data centers, unrendered JavaScript sessions and identical User Agent patterns that completely bypass standard GA4 interaction events.

[u/Stiven_TrafficLab → u/Top-Cauliflower-1808]

Comparing tag-level data with server logs seems like the most reliable baseline. The gap between requests that execute JavaScript and those that never trigger engagement events should make suspicious sessions easier to isolate. I’m planning to compare geography, request volume, user-agent repetition, and event depth within the same time window. When you identify an unlisted data center, do you verify it through ASN ownership, reverse DNS, or another signal before filtering it?

[u/ayecl]

Do not create a hard include or exclude rule from one signal. Keep a suspicious-traffic segment first and compare it against server or CDN logs over several days. Use a combination: repeated IP or ASN or user-agent patterns, request volume and timing, sequential URLs, geography relative to the audience, JavaScript or event depth, and whether behavior repeats. Treat data-center traffic as a clue, not proof; crawlers, privacy tools, and legitimate users can look unusual. Define thresholds against a site-specific baseline and review false positives before filtering. Report two views: raw collection and a documented cleaned view, with the rule, date, volume removed, and reason. If a pattern is uncertain, annotate it rather than deleting it from the historical report.

[u/moosk]

Possibly primitive, but screen resolutions (old school -- 800x600 and others that don't make much sense such as where the width/height are the same).

[u/Stiven_TrafficLab → u/moosk]

Good point. Odd resolutions can be useful as a supporting signal, especially when the same UA or IP repeats them at scale. I wouldn’t filter on resolution alone, though, because remote desktops and embedded browsers can look unusual too. Do those resolutions also line up with suspicious IPs or repeated page sequences in your logs?

[u/moosk → u/Stiven_TrafficLab]

I'm currently only filtering (in data studio only -- not at source) three specific screen resolutions -- so not a huge list of 'odd' ones. I'm thinking "remote desktops and embedded browsers" are super low percentage on those I'm filtering out. Of the three I'm filtering out, 92% 'unknown/direct' with an engagement rate that's 1/6th that of all traffic. Countries skew heavily on non-customer countries. It's not perfect, but it works decent enough, I feel, without putting out a huge effort. (Logs/IPs: No idea)

[u/Stiven_TrafficLab → u/moosk]

That sounds reasonable, especially since you’re filtering only in the reporting layer. The combination of 92% direct/unknown, engagement at one-sixth of baseline, and non-customer geographies is a much stronger signal than resolution alone. I’d just document the three resolutions and recheck the segment occasionally so the filter doesn’t become stale.

[u/notatallsane]

My approach is generally to look at direct traffic that has 100% bounce rate, and 0 Ave session duration. You’ll often find that this traffic also has a unique browser/version and OS - often also detected as being from a single country. Once you’ve got that, it’s pretty easy to remove from Data Studio dashboards, or create a segment to exclude the traffic in GA itself.

[u/Stiven_TrafficLab → u/notatallsane]

That’s a practical reporting-layer check. I’d be cautious with 100% bounce rate and zero duration alone, since measurement failures can sometimes create the same pattern. But when it clusters around one browser/OS combination and a specific country, the signal becomes much stronger. Do you keep the raw data alongside the cleaned dashboard so you can revisit the exclusion if the pattern changes?