A post in r/GoogleAnalytics pulled 34 comments last week because someone shared their process for debugging a Direct/(none) traffic spike. The replies split between people who’d seen the exact same pattern and people who had no idea GA4’s “direct” label was this misleading. But I’ve been through this investigation on our own analytics twice now. And both times the process was identical, which is why I finally wrote the whole thing down as a checklist instead of reconstructing it from memory every time something looks off in the real-time report.

The checklist

Run through these in order. Each step either clears the traffic as legitimate or pushes you closer to confirming bots.

  1. Filter to Direct/(none) in the source/medium report. Look at the percentage. Above 40% for a small SaaS, keep going.

  2. Break down by landing page. Real direct traffic hits a mix of pages because humans bookmark blog posts, product pages, docs. But if 90%+ of your Direct/(none) sessions land on / and nothing else, that is not people typing your URL.

  3. Check engagement rate. GA4 counts sessions longer than 10 seconds, with a conversion, or with 2+ pageviews as “engaged.” Bot sessions show 0% because the bot loads the page and bounces immediately. Below 5% engagement on high volume means something is crawling your site and not reading it.

  4. Build an Explore report for time distribution. This is where most people quit because GA4’s Explore interface is genuinely awful. But you need this step. So plot sessions by hour over the suspicious period and look for clustering — bot traffic almost always arrives in synchronized bursts during off-hours rather than spread across the day the way real visitors land.

  5. Check device and browser uniformity. Sophisticated bots spoof Chrome on Windows because it’s the most common user agent string on earth. But they all tend to report the same browser version, same screen resolution, same language setting. That kind of uniformity across hundreds of sessions does not happen with real people.

  6. Cross-reference your CDN or WAF logs. GA4 cannot tell you the origin ASN or IP range. Cloudflare, Fastly, or your server access logs can. Look for a single ASN generating the bulk of traffic during the suspected window.

  7. Block at the WAF layer. Not in GA4. If you find a suspicious ASN (Tencent-owned ranges show up constantly for small SaaS sites), create a managed challenge rule. Your Direct/(none) should drop within 24 hours.

When to stop digging

Below 30% Direct/(none) for a small SaaS, or somewhere close? Probably normal. Don’t waste your afternoon.

Referrer stripping is making everything worse

Some of that Direct/(none) is not bots at all, and you cannot fix it with WAF rules. Safari strips referrer headers aggressively in private browsing, and Firefox has been tightening its referrer policy with each release, which means a growing chunk of real human traffic shows up at your site with zero attribution data and GA4 has no choice but to label it direct. And email clients are another black hole because most of them route links through intermediaries that kill the referral chain entirely.

So the non-bot portion of your Direct/(none) is growing for reasons completely outside your control. UTM parameters on every link you own are the only real counter. Newsletter sends, social posts, links from your product to your marketing site. Because without UTMs you are telling GA4 to file that traffic wherever it wants, and it will happily dump it right next to your bot sessions where both become impossible to untangle.

The damn Explore reports

Steps 3 through 5 on that checklist involve a crap ton of clicking through GA4’s Explore interface, which might be the least intuitive reporting tool I’ve dealt with in ten years of running analytics on SaaS products. I used dassi to navigate those reports during my last investigation and it cut the time roughly in half, not because the analysis was faster but because I wasn’t hunting for the right dropdown in a menu system that seems deliberately designed to waste your time.

Google does not seem interested in fixing this

Built-in bot filtering has not meaningfully improved since GA4 launched. And the Explore report builder still feels like a beta product three years in. Between Cloudflare for blocking and dassi for navigating the investigation, the actual fix lives entirely outside Google’s product. And there’s no indication that will change, because Google’s analytics priorities clearly sit with advertising integration and not with making the free tier usable for small SaaS founders trying to figure out where their traffic comes from.

So bookmark this checklist. I wrote about a specific traffic spike investigation with more detail after our last incident. And if the Explore interface makes you want to close your laptop, I get it — I’ve had that exact reaction with complex web UIs before.