You have a platform report showing link taps and your own analytics showing far fewer sessions attributed to that platform, with a large residue under the label direct. What you are being asked to account for is one HTTP header. The Referer field is the only thing in an ordinary request that says where a visitor came from, and the standard defining it never promised it would be there.
The gap you are asked to explain in the meeting
Refuse the premise that the two figures should match. A link tap is an event the platform observes on its own surface, counted by its own definition, the same problem as what the platform is counting on its own surface. A session with a source is what your site infers from whatever the browser sent. Two counts of different events, not two attempts at one.
If your instinct is that platforms define their metrics inconsistently, that is a real problem and a separate one, covered where the platforms define their metrics differently. This piece establishes which transitions populate the Referer header, which populate it partially, and which leave it out.
The Referer header was never a guarantee
RFC 9110, section 10.1.3, defines the field by what the browser may do, not by what the server can expect: it allows the user agent to specify a URI reference for the resource from which the target URI was obtained. Your server learns only what the browser chose to disclose. The section then sets down two facts in adjacent sentences. Servers use the field to generate back-links for simple analytics, logging and optimized caching. Some servers use it to deny deep linking or to restrict cross-site request forgery, “but not all requests contain it”. The concession belongs to that second sentence, not the first, and it ends the mystery framing.
Three details follow. The field name is misspelled in the standard, marked with a bracketed sic. A user agent MUST NOT include the fragment or userinfo components, and MAY truncate parts other than the referring origin, so a bare origin is conforming rather than broken in transit. The RFC frames these limits as privacy concerns, so the direction of travel has been toward sending less.
What the specification mandates
For current behaviour, read the living editor’s draft of the Referrer Policy specification, whose section 3 gives the default referrer policy as strict-origin-when-cross-origin. Cite it rather than the W3C TR version, a Candidate Recommendation from 26 January 2017 whose section 3.9 still defaults the empty string to no-referrer-when-downgrade.
Section 3.7 works the default through with its own example. A document at https://example.com/page.html sends the full URL to https://example.com/not-page.html, because that is same-origin. Navigating to https://not.example.com/ sends only the origin, https://example.com/. Navigating to http://not.example.com/, an insecure destination, sends no Referer header.
The middle case settles the argument. An ordinary cross-origin click from a secure page still sends the origin, and an origin is enough for receiving analytics to identify a referring host and record a referral. The default policy therefore does not explain traffic arriving as direct. It explains why you get a hostname with no path, the opposite of what most coverage of the subject implies.
The protocol level agrees: RFC 9110, section 10.1.3, says a user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol. Fetch applies the policy when the request is made, taking it from the request’s policy container when the request’s own is empty.
Which transition sends what
| The navigation | What the browser sends | Which document says so |
|---|---|---|
| Same-origin navigation, default policy | Full URL, path included | Referrer Policy draft, 3.7 |
| Cross-origin, both URLs secure, default policy | The origin only, no path | Referrer Policy draft, 3 and 3.7 |
| Secure page to insecure destination | No Referer header | Referrer Policy draft, 3.7, and RFC 9110, 10.1.3 |
| Referring page declares no-referrer | No Referer header, whatever the destination | Referrer Policy draft, 3.1 |
| The individual link carries rel=”noreferrer” | No referrer information | HTML standard, link type noreferrer |
| No referring document at all | No Referer header, or about:blank | RFC 9110, 10.1.3 |
The last row is cited to the RFC because the policy specification does not govern it.
Some of the loss is a choice the referring site made
Section 4 of the living draft sets out how a referrer policy reaches a request. Three routes are an explicit decision by the referring site: the Referrer-Policy HTTP header, a meta element with a name of referrer, and a referrerpolicy content attribute on an individual element. The value that matters is no-referrer, from section 3.1: no referrer information goes to any origin and the Referer header is omitted entirely, secure destination or not. The HTML standard offers the same decision one link at a time, through the noreferrer keyword on an a element.
When a referring site sets no-referrer, nothing on your side recovers the source. The information was never transmitted, and no analytics configuration changes that, so this loss is not a gap in your setup. Attributing that choice to a particular platform would require the platform’s own current documentation.
Trace one tap that had no referring document
A reader taps a link inside a native application, which opens it in an embedded web view, and a request reaches your server. There is no referring document: no page with a URL of its own initiated it, so there is nothing to generate a Referer value from.
RFC 9110, section 10.1.3, covers this shape of navigation. Where the target URI was obtained from a source that does not have its own URI, giving keyboard input and an entry in the user’s bookmarks as its examples, the user agent MUST either exclude the Referer header field or send it with a value of about:blank. The examples differ from an in-app tap, but the structure is identical: no referring URI exists, so no referrer can be sent.
This case sits outside the referrer policy specification, which derives a referrer from a referring document and has nothing to operate on here. Structurally it is the likeliest source of your direct residue, and your logs cannot confirm that: a request with no Referer header looks identical whether it came from a native application, a typed URL, or a bookmark.
Direct is a label your analytics assigns, not a state of the request
No specification defines direct. The request has two absences, no referrer and no campaign information in the URL. Direct is what an analytics product writes down when it has nothing to classify by, and the rule belongs to the product, not to the web platform. Google Analytics publishes its rule in the default channel group reference: traffic is Direct when the source exactly matches “(direct)” and the medium is “(not set)” or “(none)”. Read your own tool’s rule, and its scope, rather than assuming either matches.
Because the label is assigned on the receiving side, two tools can file identical traffic differently, and a change to a tool’s channel rules can move traffic between labels while nothing changes on the platform. Campaign parameters, per Google’s campaign URL documentation, travel inside the URL itself, so they survive transitions where the referrer does not.
What you can honestly say when you are asked
The defensible position is a statement about direction. The mechanism establishes that social sources are under-recorded systematically rather than randomly, and it names the transitions responsible: downgrades to an insecure destination, a referring site that declares no-referrer, links annotated with noreferrer, and navigations with no referring document.
The refusal has to be equally plain. The size of the loss cannot be established from the receiving side. Your server sees requests carrying no referrer and cannot tell them apart, so any percentage offered for how much of direct traffic is really social is an assertion, not a measurement.
Treat the platform’s link tap figure as its count of an event on its own surface, compare it against itself over time, and stop asking it to reconcile with a session count. Blaming a broken setup sends someone looking for a fix that does not exist, when the answer is that the browser was never obliged to tell you.
FAQ
Does an ordinary link from another website send a referrer?
Yes, under the current default. The living draft gives the default as strict-origin-when-cross-origin, and its example in section 3.7 shows a cross-origin navigation between two secure URLs sending the origin. That is enough to be recorded as a referral, which is why the default policy is not the explanation for direct traffic.
When does the specification require that no referrer is sent?
On a downgrade. Section 3.7 of the living draft shows a secure URL navigating to an insecure one and sending no Referer header. RFC 9110, section 10.1.3, states that a user agent MUST NOT send the field in an unsecured request when the referring resource was accessed securely.
Why do links opened inside an app arrive with no source?
Because there is no referring document for the field to be generated from. RFC 9110, section 10.1.3, requires that where the target URI came from a source with no URI of its own, the user agent must exclude the Referer header field or send about:blank instead.
Can a site choose to strip the referrer?
Yes. Section 3.1 of the living draft defines no-referrer, which sends no referrer information to any origin, and section 4 gives three declaration routes: the Referrer-Policy header, a meta element named referrer, and a referrerpolicy attribute. The HTML standard’s noreferrer link type does the same per link, and the receiving site has no recourse.
What share of direct traffic is really social?
The question cannot be answered from the receiving side, so decline it rather than estimate. A request arriving without a referrer is indistinguishable from every other request arriving without a referrer, so any share quoted for this anywhere is an assertion rather than a measurement.
Will campaign parameters fix this?
Campaign parameters travel in the destination URL itself, per Google’s campaign URL documentation, so they survive transitions where the Referer header does not, which changes what you can see on links tagged from now on and nothing about traffic already sitting under direct.
Sources
- RFC 9110, section 10.1.3, Referer, fetched 2026-08-26.
- Referrer Policy, living editor’s draft, sections 3, 3.1, 3.7 and 4, fetched 2026-08-26.
- Referrer Policy, W3C Candidate Recommendation, section 3.9, fetched 2026-08-26.
- Fetch standard, main fetch, fetched 2026-08-26.
- HTML standard, link type noreferrer, fetched 2026-08-26.
- Google Analytics, default channel group, fetched 2026-08-26.
- Google Analytics, traffic source dimension scopes, fetched 2026-08-26.
- Google Analytics, campaign data with custom URLs, fetched 2026-08-26.
