Updated: November 17, 2025
If you work in analytics, digital marketing, or MarTech engineering, you’ve probably looked at your acquisition reports and wondered:
“Why is there so much Direct traffic? Where did my referral URLs go?”
One of the most common—and most overlooked—reasons is your Referrer-Policy.
This tiny HTTP header can decide whether your analytics tools receive:
- a full URL with UTM parameters,
- just the domain, or
- nothing at all.
In this post, we’ll walk through every Referrer-Policy value, explain how each affects data accuracy, and offer recommendations for real-world use.
Grab a coffee—let’s make sense of this once and for all.
A Human-Friendly Explanation of Referrer-Policy
Whenever a user clicks a link on your site and loads another page (same site or another domain), the browser may send a Referer header. This tells the destination page where the user came from.
But how much detail the browser includes depends entirely on your Referrer-Policy.
- Some policies send everything (full URL + query parameters).
- Some send only the domain.
- Some send nothing.
- And some behave differently depending on HTTPS/HTTP or whether it’s cross-domain.
For marketers and analysts, this distinction matters a lot—because it determines whether your analytics tools can correctly attribute traffic.
Complete List of Referrer-Policy Values
Referrer-Policy governs how browsers send the Referer header when requesting resources. Different policies control referrer behavior for same-origin requests, cross-origin requests, and HTTPS→HTTP transitions.
| Policy | What It Sends | What It Means for Analytics | Risk Level |
|---|---|---|---|
| no-referrer | Sends nothing | Almost all referrals show as “Direct” | 🔒 Safest |
| no-referrer-when-downgrade | Full URL unless navigating HTTPS → HTTP | Mostly complete data | ⚠️ Legacy behavior |
| origin | Sends only domain | UTMs lost, only root-level attribution | 🔒 Safe |
| same-origin | Full URL for same-site links only | Cross-domain referrals lost | 🔒 Safe |
| origin-when-cross-origin | Full URL for same-origin; domain only for cross-origin | Good for internal analytics, weaker external attribution | 🟡 Balanced |
| strict-origin | Domain only; nothing when HTTPS → HTTP | Clean but limited data | 🔒 Safe |
| strict-origin-when-cross-origin (default) | Full URL for same-origin; domain only for cross-origin; blocks insecure downgrade | Best balance for most sites | 🟡 Recommended |
| unsafe-url | Full URL always—including cross-site and HTTPS→HTTP | Perfect attribution… but extremely risky | 🔥 Not recommended |
How Policy Changes Affect Analytics Tools
Different policies produce very different acquisition reports. Here’s what actually changes behind the scenes:
Traffic Attribution
- Strict policies (
no-referrer,same-origin) erase cross-site referrers → analytics platforms classify traffic as Direct, harming attribution accuracy. - Open policies (
unsafe-url) allow full URLs with parameters → precise understanding of where traffic came from.
Cross-Domain Tracking
For websites using multiple subdomains or third-party services (payment gateways, login providers):
- Strict policies break session continuity → more “new users” and split sessions.
strict-origin-when-cross-originenables full same-origin visibility while limiting cross-origin leakage.
UTM & Query String Tracking
- UTMs are essential for measuring campaign performance.
- Strict policies may remove UTMs on cross-site navigation.
unsafe-urlpreserves all parameters but risks leaking sensitive information to third parties.
Best Practices
- Avoid
unsafe-urlin production：It offers full analytics data but poses serious privacy and security risks. - Use
strict-origin-when-cross-origin(the default)：This policy provides an optimal balance.
