Two missing-information problems, not one channel
Direct commonly describes an observed website visit for which the analytics system has no usable acquisition source. Unattributed revenue describes a payment for which the system cannot assign an eligible marketing touch. The exact labels vary by product, so always read the reporting definitions.
A visit can be recorded as Direct and successfully linked to a payment. Conversely, a genuine payment can have no associated visit at all. Combining those cases into a single Direct revenue bucket hides whether you have a source-classification issue or an identity-and-checkout association issue.
Direct is not a synonym for brand recognition
People do type addresses and use bookmarks. But source information can also be absent when someone opens a link in an application, forwards an untagged message, follows a document link, or passes through a redirect that loses parameters. Those are possibilities to test, not a license to reassign every Direct visit to your favourite channel.
Google Analytics describes Direct as traffic without a clear referral source. Browser referrer policy also affects the information sent between pages. For example, a policy may send only an origin on a cross-origin request or no referrer at all. A referring domain is not necessarily a full page URL, campaign name, or search query.
Do not weaken a site’s privacy policy just to extract a longer referrer. For campaigns you control, consistent nonpersonal campaign tags are usually a more deliberate approach than relying on whatever an app or browser happens to disclose.
Unattributed does not mean unpaid
Imagine a fictional SaaS records a successful USD 59 payment but has no linked visitor identifier. The payment may be entirely valid. Perhaps the person denied analytics consent, used another device, started checkout after a session expired, or paid through an invoice created outside the website. The absence of an acquisition touch is not evidence of financial failure.
An attribution window is another boundary. If the only recorded touch falls outside the configured window, a system can correctly leave the payment Unattributed. Before extending that window, check whether you are changing a measurement definition or fixing a bug. Those require different explanations in your reporting notes.
A decision tree you can actually use
Pick one payment, not an aggregate chart. Start with a redacted internal record or a synthetic test customer. Follow the decision tree in order; searching for a marketing source before proving the association often wastes time.
Payment verified by the provider?
No -> investigate payment state; do not count it yet
Yes -> eligible visitor/account association present?
No -> Unattributed; inspect checkout association
Yes -> eligible recorded touch within the window?
No -> Unattributed; inspect consent/window
Yes -> usable campaign or referral source?
No -> Direct under a stated rule
Yes -> named source under that ruleTest source collection and payment association independently
For collection, open a controlled campaign link and check the final landing URL after redirects. Confirm that the intended source value survives and that your analytics event is recorded only after the appropriate permission. Inspect the expected categorical field rather than saving arbitrary full URLs that may contain personal information.
For association, inspect the server-created payment object. In one-time Stripe Checkout, payment_intent_data.metadata attaches metadata to the PaymentIntent; Session-level metadata is a different field. A value visible on the Session is not proof that the payment processor integration will find it on the PaymentIntent.
Keep this investigation within authorized logs and test data. Never paste payment secrets or customer identifiers into a public issue. After fixing a reproducible error, retest a new journey and document whether older payments can legitimately be repaired from preserved evidence.
A small report that exposes the gap
Here is a synthetic one-week example in one currency. There are 50 verified payments: 30 associated with named sources, 10 associated with recorded Direct visits, and 10 without eligible associations. The payment-count Unattributed share is 10 divided by 50, or 20%. Direct-associated payments are another 20%, not the same 20%.
You can also calculate an amount-weighted Unattributed share, but give it a different label: unassigned gross receipts divided by all gross receipts. One large annual payment can make the amount-weighted share very different from the count-based share. Do not switch between those denominators mid-report.
Track both measures around an integration change, using comparable periods and the same refund policy. A reduction in Unattributed after a checkout fix is useful evidence of better linkage; it does not automatically mean marketing improved.
What not to do when the chart looks uncomfortable
Do not relabel all unknown payments as Direct, distribute them proportionally among the visible channels, or treat a remembered campaign as a recorded fact. If you use a modeled allocation for planning, display it separately from observed attribution and explain the assumptions.
Do not assume your own login visits or admin-created orders represent customer acquisition. Exclude test traffic and test payments through explicit rules, preserving an audit trail. And do not judge a source solely by its share of tracked visitors when collection differs across devices or permission choices.
Make the next decision narrower
If you have no linked touch, work on the checkout association and its retention boundary. If you have a touch with no source, work on campaign naming and redirect tests. If both are working, accept that some uncertainty is real and compare channels within that limit.
The related UTM guide gives a naming system for the links you control. The installation checklist turns the diagnostic steps into repeatable tests. Together they are more useful than chasing a mythical dashboard with zero unknown visitors.