Our Direct channel's engagement rate looked mediocre for weeks: 25%, against 60%+ on every other channel. The standard GA4 dashboard never explained why. It took a dimension filter to find the real number, twelve points higher, once we excluded traffic that was never a visitor at all.
The number that didn't add up
Direct traffic, people typing your URL in or opening a bookmark, is usually your most intentional channel. Ours had the worst engagement rate of any channel we track. That's backwards. So we pulled 30 days of session data through the GA4 Data API and started slicing by dimension instead of trusting the top-level report.
One filter told the whole story: sessions where browser is unset. Not "Chrome," not "Safari," not even "unknown" as a labeled value, just empty. 122 sessions in 30 days, every one from the same country, every one on desktop, every one landing on a login-redirect URL pointed at a specific pricing plan's checkout page. Zero engagement on all of them. That's not a browser GA4 failed to identify. That's a client that isn't a browser at all.
What it was doing
The landing pages weren't random. They matched, almost one for one, every paid plan across our product line. Something was working through our own pricing page, extracting each checkout URL, and requesting it. Not fast enough to trip a rate limiter, not doing anything past the login redirect, just confirming each URL resolved.
Low-grade reconnaissance, not an attack in progress. But it was sitting inside our "Direct" numbers the entire time, and it was large enough to matter: roughly 23% of that channel's total sessions, dragging its measured engagement rate down by more than a third.
Why the dashboard never caught it
GA4's default channel grouping has no concept of "this doesn't look like a person." It buckets by referrer and campaign parameters, and a request with no referrer lands in Direct regardless of what's making the request. Bot filtering exists in GA4, but it filters known bot signatures, not behavioral patterns like "one fingerprint hitting every checkout URL in sequence with zero time on page." That kind of pattern only shows up if you go looking for it with a custom dimension filter, which most reporting workflows never do, because the top-level dashboard looks fine at a glance.
What we did about it
We didn't chase the source. There is currently no way to trace it further: it was public GET requests against public pricing URLs, nothing that required credentials or touched user data, and the actual IP-level trail turned out to be unrecoverable for an unrelated infrastructure reason (a container had been rebuilt with its access logs pointed at a file instead of stdout, so anything the bot did before that rebuild is just gone, a mistake we've since fixed). What we did fix is the analysis: excluding that browser fingerprint from Direct-channel reporting to see the channel's real performance, and treating any future "Direct traffic with an empty browser dimension" cluster as a signal worth checking rather than noise to average over.
The takeaway
A dashboard metric that looks slightly off is worth one dimension filter before you write it off as "that's just how this channel performs." Ours wasn't underperforming. A quarter of it wasn't a channel at all.
