Why fixing 'Direct/None' alone won't reduce GA4's 'unknown traffic'

A friend running a D2C brand told me last week: "I enforced UTMs across every ad and email link to reduce Direct / (none) in GA4. The Direct share dropped, but the total 'unknown traffic' in the report barely changed. What did I miss?"

I dug into it. The answer is straightforward — and slightly embarrassing for me, because I had never internalized it cleanly either.

The "unknown traffic" you see in GA4 is not one category. It's four.

Direct / (none), (not set), Unassigned, and (other). Each is generated at a completely different stage, by a completely different mechanism, and demands a completely different fix. Reducing Direct / (none) on its own does nothing for the other three.

The 4 stages where these are generated

The crucial thing to understand is at which stage GA4 produces each of these values. Mapping it to the three stages from data arrival to display, the relationship snaps into focus.

The breakdown:

• Stage 1 — Receive → (not set). The dimension value never reached GA4. Could be a tag that didn't fire, an incomplete UTM, a missing session_start event.
• Stage 2 — Classify → Direct / (none). GA4 deliberately assigned this session to Direct because Source = (direct) AND Medium = (not set) or (none). This is an explicit classification result, not missing data.
• Stage 2 — Classify → Unassigned. The data arrived, Source and Medium have values, but no channel grouping rule matched.
• Stage 3 — Display → (other). Cardinality limits aggregated low-frequency rows into a single bucket. This is purely a display-layer issue.

If you only attack stage 2 (Direct), stages 1 and 3 keep producing their own "unknown" values regardless of how much UTM hygiene you enforce.

Why this matters: different fixes, different owners

Each of the four needs a different fix — and a different person on the team:

A few real-world failure modes I've personally watched happen:

• Asking an analyst to "fix (not set)" → They edit channel groupings for hours. No effect, because (not set) is a measurement-tag implementation problem.
• Asking an engineer to "fix Unassigned" → They re-instrument every tag. No effect, because the data was arriving fine; the channel grouping just had no rule for that source/medium pair.
• Treating "(other)" as a data-quality issue and ignoring it → It actually means your dimension cardinality is exploding (page paths with user IDs, event params with free text, etc.). It silently hides real data.

The diagnostic order I now use

Once you accept the 4-category model, the first step shifts from "how do I make the unknown traffic go away?" to "which of the four is the largest, and what does that imply?"

In GA4, the "Acquisition → Traffic acquisition" report with the dimension switched to "Session default channel group" instantly shows the Unassigned share. Switching to "Source / medium" reveals the (not set) and (direct) / (none) shares. The "Pages and screens" report with "Page path" surfaces the (other) share.

A practical priority order:

1. Unassigned > 10% → Add channel grouping rules. Are you using a new ad platform that GA4's defaults don't recognize? (TikTok, LINE Ads, etc.)
2. A specific dimension shows (not set) > 5% → Audit the tag implementation that sends that dimension.
3. Direct / (none) > 20% → Decompose the 5 sub-causes (UTM gaps, in-app browsers, referrer loss, etc.). I've covered that one in detail in another article.
4. (other) appearing → Revisit your dimension design. Trim cardinality.

This sequence comes from one obvious-in-hindsight observation: each category lives at a different layer, so you can't usefully diagnose the second-priority one until the first-priority one is contained.

So what?

The thing I wish I had understood earlier is this: "unknown traffic" is not a single problem. Treating it as one — building one fix, one alert, one monitoring rule — guarantees that you'll be busy without making the dashboard meaningfully more honest.

Splitting it into the four categories, mapping each to its own stage and its own owner, is unglamorous work. But it's the difference between fixing one of the four (and being puzzled why the total didn't move) and fixing the actual largest leak in your reports.

If you've found a different decomposition that works for your team — or you've cracked the (other) cardinality problem more elegantly than "exclude query strings from the URL dimension" — I'd genuinely like to hear about it in the comments.

---

This post is an English re-edit of an article originally published on RevenueScope. Full English version (with references to all four official Google Analytics docs):

→ Why fixing 'Direct/None' alone won't reduce GA4's 'unknown traffic'

I'm building RevenueScope — a revenue-first analytics layer that sits next to GA4 for eCommerce teams. One of the things it does is re-classify sessions trapped in Unassigned and Direct / (none) back to their probable original channel using domain heuristics, so revenue attribution doesn't silently leak through these four buckets.

References

1. Google Analytics Help — "[GA4] About (not set)" — 2026-04
2. Google Analytics Help — "[GA4] Default channel group" — 2026-04
3. Google Analytics Help — "Tagging best practices to avoid unassigned, (not set), and direct traffic issues" — 2026-04
4. Google Analytics Help — "[GA4] High-cardinality dimensions" — 2026-04