In Sources → All sources, you'll often see a row labelled (Unknown) or (Direct). Both are normal — they indicate visits that arrived without enough information to classify the source. Here's the breakdown.
What "(Unknown)" actually means
A visit gets the (Unknown) label when:
- The browser sent no Referer header (most common, see below).
- The Referer header was set, but the URL was malformed or didn't parse.
- The Referer was from a domain on Zenovay's deny-list (an internal tool, a known-bot domain, etc.) — but the visit itself wasn't bot-flagged.
What "(Direct)" means
(Direct) is a subset of "no referrer" — specifically, visits where:
- The user typed the URL directly into the address bar.
- The user clicked a bookmark.
- The visit came from an HTTPS page that explicitly suppressed the referrer (see HTTPS-to-HTTPS section below).
In most dashboards we group these into a single "(Direct)" bucket and show "(Unknown)" only for genuinely odd cases.
Why your "(Unknown)" rate may be growing
Several modern browser/privacy trends shrink the referrer signal:
1. Strict referrer policies on the source site
Many sites set Referrer-Policy: strict-origin-when-cross-origin or no-referrer on their pages. When a visitor clicks a link from such a site to yours, the referrer is stripped or reduced to just the origin. If it's stripped entirely, the visit lands as (Unknown).
2. Privacy browsers + ad-blockers
Brave, Firefox in strict mode, DuckDuckGo Privacy Browser, and Safari's ITP all strip or downgrade referrers for cross-site links. iOS 14+ added similar protections.
3. Mobile in-app webviews
Clicks from native apps (Twitter app, Instagram, LinkedIn app, Slack desktop) often arrive with Referer: android-app://... or no referrer at all. The Zenovay parser recognises common app schemes (android-app://com.twitter.android, etc.) and labels them — but new schemes show up as Unknown until the parser is updated.
4. HTTPS-to-HTTP referrer suppression
If a user clicks from an HTTPS page to your HTTP page (rare in 2026 — most sites are full-HTTPS), the browser drops the referrer entirely.
How to shrink your "(Unknown)" rate
You can't recover a referrer that was never sent, but you can bring more of those visits into a meaningful category by:
Use UTM parameters in your campaigns
Tag every campaign link with ?utm_source=twitter&utm_medium=social&utm_campaign=spring2026. UTMs survive even when the referrer is stripped. They appear in your dashboard under the explicit campaign source instead of (Unknown).
This is the highest-leverage single change. If you're running ads or email campaigns and don't have UTMs, adding them moves 30-60% of "(Unknown)" into proper buckets.
Check your own site's referrer policy
If your Referrer-Policy header is set to no-referrer for outbound clicks, it's stripping referrers for any sites linked from yours — and equivalently, those sites lose the ability to identify you as their source. Consider relaxing to strict-origin-when-cross-origin (the modern default).
Run server-side enrichment
For Pro+ customers using server-side tracking, you can supply extra context (the visitor's referring URL captured server-side, marketing-attribution from your CRM, etc.) that the JS tracker doesn't see.
When "(Unknown)" is actually a bug
If your "(Unknown)" rate is >50% of total visits, something is wrong:
- Check that visits from your top campaigns have UTMs (they should land under the campaign source, not Unknown).
- Look at a sample session in Live View and check the captured Referer field. If it's missing entirely on visits that should have come from somewhere, the JS tracker may be running before referrer data is available — common with very early page-script execution.
- Email support@zenovay.com with the website domain and a screenshot of the sources breakdown.
Plan applicability
Source classification works on every plan. The UTM auto-bucket and bot-filter features are on every plan as well. Custom source-mapping rules (renaming "(Unknown)" subgroups, adding allow/deny lists) are a Scale-tier feature.