Ad conversions show as Direct when the click identifier didn’t survive the journey to the converting session — stripped by an email client, removed by a privacy browser, dropped in a redirect chain, or simply not present because the person converted on a later visit or a different device. Direct isn’t a traffic source. It’s the absence of evidence on one particular session.
That distinction matters, because the evidence usually still exists somewhere in that visitor’s history. The click happened. The identifier existed. It just wasn’t attached to the visit where the money changed hands — which means the attribution is frequently recoverable, despite the widely repeated advice that it isn’t.
What does “Direct” actually mean in conversion attribution?
It means: no source signal was present on this session, so we filed it under nothing.
Most articles about Direct traffic are written about web analytics — inflated session counts in a GA4 report, a reporting annoyance you learn to live with. The version that costs money is different. When a conversion lands with Direct as its source, the campaign that actually earned it receives no credit. Your reporting shows a purchase from nowhere, the ad account shows spend without return, and budget shifts away from the channel that was working.
And almost nobody in that bucket is actually direct. The genuine Direct visitor — someone who typed your URL from memory with no prior exposure — is rare, and rarer still among people who convert on the same visit. What’s really in the bucket:
- Clicks whose tracking parameters were stripped in transit.
- Returning visitors converting on a later session that carries no parameters.
- People who clicked on one device and converted on another.
- Sessions where the referrer was suppressed by browser policy.
- Ad clicks where iOS privacy rules limited what could be passed along.
Each one is a real, identifiable source that lost its label. Treating that bucket as “brand strength” or “word of mouth” is the expensive mistake — it’s misfiled revenue, not organic demand.
Why do ad clicks lose their click ID?
Seven mechanisms, most of them entirely outside your control:
1. Email and messaging clients rewrite links. Click a link inside a mail client or a messaging app and the URL that opens is frequently not the URL that was sent — wrapped for safety scanning, shortened, or cleaned. Query parameters are collateral damage.
2. Privacy browsers remove tracking parameters outright. Several browsers now strip known tracking parameters from URLs on navigation as an anti-fingerprinting measure. The user clicks your ad; the browser deletes the identifier before your page ever sees it.
3. Redirect chains drop the query string. A link that passes through a shortener, a geo-redirect, an A/B testing tool, or a poorly configured 301 can arrive at the destination with the parameters removed. Every hop is an opportunity for the query string to be dropped rather than forwarded.
4. The converting visit isn’t the clicking visit. This is the most common cause and the least discussed. Someone clicks an ad on Tuesday, browses, leaves, and returns on Thursday by typing your domain or clicking a bookmark. Thursday’s session genuinely has no parameters — it is, narrowly, direct. But the purchase belongs to Tuesday’s ad.
5. The conversion happens on a different device. Clicked on a phone during a commute, purchased on a laptop that evening. The laptop session has no click history at all. Cookie-based attribution cannot bridge devices, because cookies don’t travel between them.
6. Referrer policy suppresses the referring page. When a site sends a restrictive Referrer-Policy, the destination sees no referrer at all. Without parameters and without a referrer, a session has nothing to classify on.
7. iOS privacy limits what can be passed. Apple’s tracking restrictions constrain both what identifiers persist and how long they survive, which is why mobile-heavy accounts see disproportionately large Direct buckets.
Notice the pattern: in cases 4, 5, and 6 particularly, nothing was ever broken. The tracking worked correctly. The click identifier existed and was captured — on a different session than the one that converted.
Why can’t your analytics fix this retroactively?
Because most analytics tools decide a session’s source at the moment the session starts, write it to that session’s record, and never revisit it.
This is why the standard advice around Direct traffic is some version of “you can’t move traffic around once it’s been logged — just fix your tagging going forward.” Within a session-scoped model, that’s accurate. The source field was populated at write time from whatever signals were present in that instant. If nothing was present, the field says Direct, and there’s no mechanism to reconsider it later.
The limitation isn’t the data. It’s the model. Session-scoped attribution asks a narrow question: what signals did this session arrive with? A visit with no parameters and no referrer has exactly one honest answer.
But that’s not the question a marketer needs answered. The useful question is: what do we know about this person, across everything they’ve done? Under that question, a Thursday visit with no parameters isn’t an orphan — it’s the fourth session of someone whose first session on Tuesday arrived with a Google Ads click identifier attached. The evidence exists. It’s simply attached to a different row.
Resolving attribution at read time, across a person’s whole history, rather than at write time from a single session, is what makes previously-Direct conversions recoverable. Same raw data, different question.
How does PartialLeads recover Direct conversions?
By refusing to treat a session as the unit of attribution.
Every visitor gets a durable identity, not just a cookie. Sessions are linked into a person through a tiered identity graph — a persistent visitor ID, then normalised email, then phone, then IP and device signals, then the click identifiers themselves. The visitor ID is set server-side rather than by JavaScript, so it survives browser tracking-prevention limits that would otherwise sever the link after a few days — which is exactly the window in which Tuesday’s click and Thursday’s purchase need to stay connected.
Sessions inherit attribution from their siblings. When a visit arrives with no campaign signal but belongs to a person whose earlier visit carried a strong one, the attribution is inherited rather than discarded. A real example from production: a purchase reporting as Direct was correctly reattributed to Google Ads because the buyer’s earlier same-visit session carried the click ID. That sale went from unattributed to credited to the campaign that earned it.
Sessions with no parameters get classified from what did survive. When no utm_source is present, a session classifier resolves the real channel from the remaining evidence — referrer, landing page, click identifiers found elsewhere in the visitor’s history, and the pattern of prior sessions. In practice this is the largest single source of recovered attribution, bigger than iOS click rescue or partial-lead recovery.
The recovery is itemised, not asserted. The Attribution Report shows recovered revenue broken out by mechanism — ad clicks re-linked, sessions reclassified by the classifier, and buyers matched despite never finishing a form — each with its own purchase count and affected channels. You can audit the reattribution rather than take it on faith, which matters when you’re about to move budget based on it.
And the resolved view sits beside the naive ones. First-touch, last-touch, and the resolved model appear together, each with its own purchase count. The resolved model can show more attributed purchases than the other two precisely because it recovers journeys they lose. You see the difference the recovery made rather than being handed a single number.
Honest boundaries. Not every Direct conversion is recoverable. A genuinely new visitor with no prior session, no captured contact detail, and no identity signal stays unattributed — and the report shows that as unmatched revenue rather than hiding it or guessing. Reclassification is reasoned inference from surviving evidence, not certainty, which is why it’s displayed alongside the simpler models instead of replacing them. And nothing here reaches back into Meta’s or Google’s own dashboards to rewrite their numbers; it corrects your attribution, so you can allocate budget against something closer to the truth.
Where your Direct bucket actually comes from:
| What’s really in “Direct” | Why it lands there | How it’s recovered |
|---|---|---|
| Click parameters stripped in transit | Email clients, privacy browsers, redirect chains | Session classified from referrer, landing page, and prior-session evidence |
| Returning visitor converting later | The converting session genuinely has no parameters | Linked to the earlier session that carried the click ID |
| Clicked on phone, converted on laptop | Cookies don’t cross devices | Identity graph matches on email or phone across devices |
| Regenerated visitor ID mid-journey | Platform sandboxes reset storage | Visit-sibling inheritance re-unifies the split sessions |
| Referrer suppressed by browser policy | Restrictive Referrer-Policy on the referring page |
Resolved from click identifiers elsewhere in the visitor’s history |
| Genuinely unknown visitor | No prior session, no identity signal | Not recovered — reported honestly as unmatched |
Setup is one tag. The free tier includes the Attribution Report, so you can see how much of your own Direct bucket is recoverable before paying anything.
Tell us what's broken. We'll fix your tracking — free.
Describe the tracking/attribution problem you're stuck on and we'll map it to a fix: server-side conversions to Meta, Google, TikTok and Pinterest, plus first-party tracking that survives Safari. No code required.
Sources
- MDN Web Docs — Referrer-Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
- Google Ads Help — About auto-tagging and the gclid: https://support.google.com/google-ads/answer/3095550
- WebKit — Tracking Prevention in WebKit: https://webkit.org/tracking-prevention/
- Google Analytics Help — Direct and unassigned traffic: https://support.google.com/analytics/answer/6205762
- Apple Developer — User Privacy and Data Use: https://developer.apple.com/app-store/user-privacy-and-data-use/