document.referrer is null for traffic from Copilot / Claude. Anyone else seeing this?

Hello Isha,

Guess it’s because of this reason these AI sites are adding utm_source=copilot in the links to the site. I am observing this behaviour in my prod scenario.

Regards,

Manish

Hi Isha!

This is a good one to dig into, the "gray instead of black and white" bit is really several separate behaviours stacking on top of each other rather than one inconsistency.

document.referrer only gets populated when the navigation request itself carries a Referer header, and that depends entirely on how the link was opened. If Claude or Copilot render citations as plain anchor tags and the browser does a normal top-level navigation, you'd expect a referrer under default policies. But a lot of these chat UIs open links via window.open() from a sandboxed iframe, or set rel="noopener noreferrer" on the anchor, or the parent frame sends Referrer-Policy: no-referrer or same-origin on its own responses. Any of those suppress the header before it ever reaches your site, so there's nothing for Adobe's tags to capture downstream.

Worth separating app clients from web clients too. The Windows Copilot app and the Claude desktop app aren't rendering a browser document when they hand off a link, they're invoking an OS-level URL handler and launching your default browser as a fresh process. That's not a navigation from a referring document at all, so document.referrer is null by construction rather than by stripping. Bing's web AI Mode is a genuine in-browser navigation from bing.com, which is why that one still carries a referrer, even if you can't isolate the AI layer from it.

On the low volume of hits that do show "Claude" or "Copilot": my read is that's a standard anchor click happening inside an actual rendered web surface (Claude's web app rather than the desktop client, for instance) without a stripping policy applied, so the Referer header survives. The inconsistency comes from which surface, which headers, and which link-rendering path produced that specific click, not from anything flaky on your side.

On the utm_source=copilot workaround Manish mentions, I'd treat that as supplemental signal rather than a fix. It's not guaranteed by spec or convention, each vendor can change it without notice, and based on what Jennifer's seeing it's already inconsistent even within one vendor's own surfaces. Worth logging as a dimension so you've got a rough floor, but I wouldn't build attribution logic on the assumption it'll be there.

If you want a partial mitigation, inspecting user agent strings on first-party server logs can catch some of the app-handoff cases that never reach your JS layer at all, since those requests sometimes carry distinguishing UA strings even with no referrer. Won't be complete, but paired with UTM presence it narrows the unknown-Direct bucket a bit.