Why GA4 Shows So Much (direct) / (none) Traffic, and What Fixes It

Every marketing team has had the conversation. Direct is the second or third largest channel in GA4, it grows when campaigns run, and nobody believes that thousands of people typed the URL from memory. The usual explanation, “brand awareness”, sounds reasonable and settles nothing, because a channel you cannot decide anything with still takes a share of every report.

The size of the problem is measurable. On Incapto's Shopify store, 14 of every 100 visits GA4 recorded had no origin a budget decision could use: nine assigned to no channel at all and five more in residual channels. Over the same days, Sealmetrics left 3 in every 1,000 without an origin. At Palladium Hotel Group, 40% of inbound traffic had no source or medium in the previous stack, and 35% of the bookings GA4 recorded had no channel. That is the gap the complete data argument starts from; this piece is about where it comes from.

What (direct) / (none) and Unassigned actually mean in GA4

GA4's default channel group defines Direct with a rule, not a judgement: the source is exactly (direct) and the medium is (not set) or (none). In plain terms, GA4 received neither a referrer nor campaign parameters for that session. Unassigned is what GA4 uses when no channel rule matches at all.

The detail most teams miss is how GA4 fills session-scoped source dimensions. For session and user scope, GA4 uses the paid and organic channels last click model, and a session that starts with a direct entrance takes the campaign values GA4 already holds for that user. A known visitor who first came from Google Ads and returns by typing your address is reported under Google Ads, not Direct.

Which means that what remains in (direct) / (none) is the traffic for which GA4 had nothing: no source for the session and no earlier source for the user. That is why direct is a symptom. It measures the visits whose origin was lost, plus a smaller share of genuine typed and bookmarked visits.

The six causes, in the order they usually matter

1. Consent is granted after the landing page

A tag that waits for consent does not run on the landing page if the visitor accepts the banner on the second page. By then the page that carried the referrer and the UTMs is gone: the second page's referrer is your own site and its URL no longer has the campaign parameters. The session starts without a source, and if the visitor is new to GA4 it has no earlier source to inherit.

2. GA4 does not recognise the visitor

The inheritance in the previous section only works for a user GA4 already knows, through its first-party cookie. A visitor who rejected cookies on an earlier visit, cleared them, or came back after Safari capped a script-set cookie at 7 days — 24 hours if the page arrived with tracking parameters — looks new. Their return visit has no source to inherit, so it becomes direct.

3. The session_start event is lost

Google documents several implementation errors that drop session_start, and with it the session's source, which then shows as (not set) and Unassigned: the Google tag firing after other events on the page, custom events sent before the config command, using the consent default command where update is needed, or sending denied events after the visitor granted consent. Inconsistent cookie prefixes across the site and a cross-domain linker that initialises late split identities in the same way.

4. Redirects and referrer policies strip the referrer

Server redirects, JavaScript and meta-refresh redirects, HTTPS-to-HTTP hops and strict Referrer-Policy headers can all remove the referrer before your page loads. Link shorteners and some native-content networks chain several redirects. The visit arrives with an empty referrer, and without UTMs there is nothing left to classify.

5. Links that never send a referrer

Email clients, messaging apps and the in-app browsers of social apps often open links without a browser referrer. Untagged links from those places, QR codes and PDFs are indistinguishable from typed visits. This is the one cause a UTM policy fixes almost completely.

6. Cross-domain hops

A checkout, booking engine or payment gateway on another domain breaks the session unless cross-domain measurement is configured and the cookie survives on both sides. When the visitor comes back from a payment page, the return is recorded either as a referral from the gateway or, if the referrer is stripped, as direct.

How to diagnose it in your own GA4 property

An hour with these checks tells you which causes you have:

1. Separate Direct from Unassigned. In Traffic acquisition, look at both rows. A large Unassigned share with a (not set) source points to cause 3, not to brand traffic.
2. Check landing page (not set). Google notes it appears when a session has no page_view event. A high share means events are firing before or without the page view.
3. Split direct by browser and device. Direct concentrated on Safari and mobile points to causes 1 and 2; direct that is flat across browsers points to redirects or untagged links.
4. Follow one tagged link end to end. Open a URL with UTMs in a clean browser, reject the banner on the landing page, accept it on the second page, and see which source GA4 records in DebugView.
5. Inspect the referrer through your redirects. In the browser's network tab, check that the referrer and UTMs survive every hop from the ad or email to the final page.
6. Compare with a number neither tool produces. Reconcile GA4 against your real orders or bookings before reading channels. The method is set out in one number for marketing and finance.

What a tag fix recovers, and what it cannot

Causes 3 to 6 are technical and fixable inside GA4: tag order, consent update instead of default, one cookie prefix, an early linker, fewer redirects and UTMs on every link you control. Do them; they shrink both direct and Unassigned.

Causes 1 and 2 are not bugs. They are what consent-based measurement is designed to do: a visitor who has not accepted has no cookie, and a visitor without a cookie has no history. No configuration gives GA4 the source of a visit it was not allowed to measure, and Consent Mode modelling estimates totals rather than restoring the source of each visit. The loss is also uneven: at Incapto, Sealmetrics recorded 11% more direct traffic than GA4, but 37–52% more from paid campaigns and 133% more from organic social, so direct looks bigger than it is precisely because it loses less than everything else.

How cookieless measurement treats the same visits

A cookieless tool does not depend on consent to read the landing page, so causes 1 and 2 stop producing direct traffic. Sealmetrics reads the source of every landing page — UTMs first, then a recognised referrer such as a search engine or social network, then any other referrer — and records direct only when there is no UTM and the referrer is empty. Visits that resume after the two-hour session window are labelled rejoined traffic instead of being added to direct, and payment gateways or booking engines registered as passthrough referrers keep the original source when the visitor returns.

It does not make causes 4 to 6 disappear. A redirect that strips the referrer, or an untagged link opened from an email app, still arrives with nothing to classify, and Sealmetrics records it as direct. The UTM and redirect hygiene in the previous section matters for any tool. And because Sealmetrics does not identify users, it cannot give a returning visitor the source of an earlier visit: each conversion is credited to the channel of the session in which it happens. How that plays out in campaign reporting is covered in campaign revenue attribution.