GA4's 'Direct / (none)' is mostly measurement loss, not user behavior

#analytics #marketing #googleanalytics #webdev

When you open GA4 and see "Direct / (none)" sitting at 30%, 40%, sometimes higher — what's the first thought that goes through your head?

For a long time, mine was: "Brand is finally landing. People are coming back directly."

Then I dug in. Almost every time, that interpretation is wrong. Direct / (none) is mostly measurement loss, not user behavior. And once you accept that, the next question stops being "is this good?" and becomes "how much of this can I recover?"

How GA4 actually decides "Direct / (none)"

The Google Analytics docs are explicit about this. A session falls into Direct / (none) when both of the following are true:

Translation: "We have no idea where this user came from."

In a healthy setup, that bucket should be tiny — bookmarks, direct URL typing, email clients that strip referrers. The fact that it's 30% or 40% for so many sites is not a signal of brand strength. It's the size of your measurement blind spot.

The 20% / 40% threshold

The rough heuristic I use when reviewing ad performance dashboards:

If you write "Paid Search ROAS = 400%" in a board deck while Direct / (none) is 45% of sessions, that 400% is almost certainly inflated. A non-trivial chunk of those Paid Search clicks are being mis-classified into Direct, and the channel that did drive the conversion is getting double credit on the rest.

The 5 causes (and 8 of 10 are fixable in-house)

Direct / (none) bloat traces back to two root mechanisms: missing campaign parameters or lost referrer. The five most common patterns, ranked by how often I encounter them:

Missing utm_source — ads, newsletters, LINE messages, QR codes shipped without UTM. Most common by a wide margin.
In-app browser taps — LINE, Instagram, Facebook in-app browsers either don't pass Referer or send a custom value (com.facebook.katana) that GA4 doesn't recognize as a social source.
HTTPS → HTTP downgrade — the W3C Referrer Policy spec deliberately strips Referer on protocol downgrades. If your funnel passes through any HTTP intermediate page, the referrer is gone before it reaches you.
Redirect intermediaries — bit.ly, lin.ee, t.co, internal redirect chains. Server redirects vary by browser, JavaScript redirects almost guarantee referrer loss.
Referrer policy — modern browsers default to strict-origin-when-cross-origin, which only passes the hostname. Stricter sites (no-referrer) pass nothing at all.

Of these five, only the last one (referrer policy on third-party sites) is genuinely outside your control. The other four — missing UTMs, in-app browser handling, protocol downgrades, redirect chains — are all recoverable through your own implementation. That's where the "8 out of 10" framing comes from.

A 10-minute health check

If you read this and want to know where your own site stands, here's the minimum-viable diagnostic:

That last step is where the diagnosis happens. If Direct sessions concentrate on mobile + specific landing pages, you're looking at an in-app browser problem. If they spike at the same time as a campaign launch, you have a UTM gap. If they cluster by country, you're hitting referrer policy variation.

So what?

The thing I find genuinely useful about this framing is that it converts a vague "Direct / (none) is going up" worry into a measurable, recoverable problem. The fix isn't a new tool. It's a habit:

Track Direct / (none) ratio monthly. Annotate the 20% and 40% lines on your dashboard. When it crosses, decompose before you re-baseline anything.

I'd be curious to hear how high Direct / (none) is on the sites you work on, and whether anyone has cracked the in-app browser case more cleanly than "ensure UTMs are set on every share link." Drop a comment — I'll learn from it too.

This post is an English re-edit of an article originally published on RevenueScope. Full Japanese original (with diagnostic flowchart and 5-cause frequency breakdown):

→ GA4の『Direct / (none)』が増える5つの原因と診断・対処

I'm building RevenueScope — a revenue-first analytics layer that sits next to GA4 for eCommerce teams. One of the things it does is automatically re-classify sessions trapped in Direct / (none) back to their probable original channel using domain heuristics. Built because manually fixing this in spreadsheets is a problem nobody should still be doing in 2026.