1. Unknown is a missing signal, not a visitor identity
You open a traffic report and see sessions grouped under “Unknown source.” That label does not identify a hidden company or reveal exactly how someone found you. It means the session had no campaign source that the report could use and no external referrer origin that it could classify.
WhoVisited records a referrer origin from the browser’s document.referrer and reads utm_source, utm_medium and utm_campaign from the current page URL. The tracker sends the origin and accepted campaign values with its event. Ingestion drops a referrer that points back to the same website, an allowed site origin or a supported payment processor. The Growth report uses a campaign source first, then recognizes a few search engines, then displays the remaining external referrer host. If none is available, it labels the session Unknown source.
This is a hierarchy of available signals. It is not a guarantee that every channel can be reconstructed after the fact. In particular, analytics cannot recover a source that was never present in the arriving URL or referrer.
2. Reasons a referrer can be absent
A visitor who enters a URL, uses a bookmark or opens a saved shortcut may arrive without a referrer. MDN documents that Document.referrer is an empty string for direct navigation. That is one normal explanation for Unknown, but the dashboard cannot tell it apart from a privacy or application handoff that also removed the referrer.
A browser’s referrer policy controls how much information a navigation sends. The common strict-origin-when-cross-origin policy sends only the origin for a secure cross-site transition, so WhoVisited can still recognize a host while losing the previous page path. A no-referrer policy omits it entirely. Links with rel="noreferrer" also suppress referrer information.
HTTPS-to-HTTP downgrades can omit the referrer under strict policies. Redirects, link shorteners, mobile apps, email clients and payment flows can also change the chain. If an intermediate page drops campaign query parameters or sends a no-referrer link, the final website may receive neither signal.
These controls protect visitors from exposing full URLs that can contain private paths or query values. Do not change a site-wide policy to unsafe-url just to fill an analytics column; that can leak sensitive URL details to other sites. Use a deliberate campaign label when you control the link, and keep the policy appropriate for your application.
3. Understand campaign precedence in WhoVisited
When the landing URL contains an accepted utm_source, the report uses that campaign source instead of the referrer host. It can append utm_medium to the displayed source and group by utm_campaign. This is useful for a newsletter link whose mail client would otherwise produce no referrer, or for a partner link where you want a stable campaign label.
The current tracker reads only three keys: utm_source, utm_medium and utm_campaign. It trims values, accepts up to 100 characters matching letters, numbers, spaces, underscores, periods or hyphens, and drops a value that fails validation. Parameter keys are case-sensitive in the URL API, so UTM_Source is not the same key as utm_source. Do not assume support for utm_content, utm_term or other campaign fields in this product’s source report.
UTM values are labels supplied by the link creator. They do not prove that a visitor came from the named publisher. Anyone can copy or edit a tagged URL. Pick a consistent naming convention and use it only on outbound campaign links; tagging internal navigation can overwrite the useful acquisition context.
Google’s campaign URL guidance also recommends consistent source, medium and campaign naming. The exact supported report fields differ by analytics product, so verify the destination tool’s implementation rather than copying all of Google Analytics’ parameters into a WhoVisited expectation.
4. Trace the final landing URL and referrer
Use a test link with neutral values and open it in a fresh browser context. The following read-only helper mirrors the three campaign fields the current tracker accepts. It reports only the referrer origin, current path and allowed campaign labels. It does not send a request or inspect any private page content.
function inspectEntryAttribution(href, referrer) {
const page = new URL(href);
let referrerOrigin = null;
try {
const previous = new URL(referrer);
if (["http:", "https:"].includes(previous.protocol)) {
referrerOrigin = previous.origin;
}
} catch {}
const campaign = {};
for (const key of ["source", "medium", "campaign"]) {
const value = (page.searchParams.get(`utm_${key}`) || "").trim();
if (value && value.length <= 100 && /^[\p{L}\p{N} _.-]+$/u.test(value)) {
campaign[key] = value;
}
}
return { pagePath: page.pathname, referrerOrigin, campaign };
}
console.log(inspectEntryAttribution(
"https://example.com/pricing?utm_source=partner&utm_medium=referral&utm_campaign=launch",
"https://partner.example/article?private=ignored"
));For the example, expect /pricing, partner.example and the three campaign labels. The article field intentionally shows only the referrer origin because that is what the tracker transmits. Do not run the snippet on a page with sensitive query parameters and share the console output without inspecting it first.
- Open the final public campaign URL and note whether the three lowercase UTM keys remain in the address bar after redirects.
- Inspect document.referrer in the final page console. An empty value confirms the browser exposed no referrer to the document; it does not reveal why.
- Compare the visible referrer origin and accepted campaign values with the landing session in WhoVisited.
- Check the campaign URL itself and every redirect or link-shortening hop you control. Confirm that campaign parameters reach the final HTTPS destination.
- Repeat in a fresh test context; an existing session keeps its original landing and acquisition fields.
Do not infer ingestion from the tracker JavaScript loading. Check bootstrap and event requests separately, then confirm the visitor journey and session source. Requests are batched, and a successful network response can contain more than one event.
5. Read Unknown alongside the evidence you have
If document.referrer is empty and there are no accepted UTMs, Unknown is the expected outcome. If referrer is present but the source is still Unknown, check whether the origin is your own allowed site or whether the report’s recognized search-engine patterns apply. Self-referrals are deliberately excluded so your own domain does not masquerade as an acquisition channel.
If a tagged link still looks Unknown, inspect exact parameter spelling, case, value characters and the final URL after redirects. A campaign parameter may be absent by the time the landing page runs, or its value may have failed validation. Confirm that the session was actually created from your test arrival rather than an earlier visit.
If some sources show a host but no article path, that is expected: WhoVisited stores only the external origin, not the referrer page URL. The reduced detail limits the amount of third-party browsing information recorded. Likewise, campaign attribution belongs to the session’s initial acquisition fields; later tagged URLs do not turn the report into a click-by-click attribution log.
Unknown is a useful data-quality prompt, not a defect to eliminate at any cost. Measure how often controlled links arrive with the labels you expect, document handoffs that strip them, and leave unobservable visits unknown. Do not claim that a change recovered the visitors’ true source unless you have independent evidence.
6. A practical way to reduce avoidable Unknown traffic
- Add consistent utm_source, utm_medium and utm_campaign values to newsletter, partner and paid links that you control.
- Keep parameter names lowercase and values within the product’s accepted character and length limits.
- Test redirects from the original campaign URL through to the final landing page in a fresh browser context.
- Preserve sensible referrer privacy settings. Do not expose full paths or query strings just to improve attribution.
- Compare test requests with the actual session landing record, and keep expected Unknown cases in your reporting notes.
You cannot control the browser policy chosen by every referring site, the behavior of every app handoff or whether a visitor clicks a tagged link. A healthy acquisition report distinguishes what the evidence supports from what it cannot observe. Unknown keeps that boundary visible.