How Chrome's new referrer policy affects your site analytics
Google’s Chrome browser is the most popular web browser. It has a market share of more than 70%. Whatever new policy Chrome implements will have an affect on all websites as chances are the majority of your visitors use Chrome too.
In Chrome 85 which was released in August 2020, Google changed its default referrer policy to strict-origin-when-cross-origin. Firefox made the same change in March 2021 with version 87. Safari also follows the same policy.
What’s a referrer policy and what does strict-origin-when-cross-origin even mean? Why should I care as a website owner? You should be aware of it as it will affect your website analytics. Let’s take a closer look.
- TL;DR: How Chrome’s new referrer policy affects your analytics
- What is a referrer policy?
- What does Chrome’s new referrer policy default do?
- What are the default referrer policies in other browsers?
- The issue of dark traffic
- How can I set the referrer policy for my own website?
- Increased importance of tagging the links you can control
TL;DR: How Chrome’s new referrer policy affects your analytics
Web analytics tools will have reduced granularity in the referral sources data. Your website analytics will still be able to show the referral source of your traffic but only on the domain level rather than the full URL.
For instance, if
thatblog.com/one-post/ links to you and sends you visitors, you will see
thatblog.com in your referral sources list but won’t be able to see the exact post URL itself.
Most of the time the origin domain is sufficient for you to understand who has mentioned you, but in some cases, it may become more difficult to understand the exact page your traffic is coming from.
For instance, you would not be able to see the exact Reddit thread you were mentioned in anymore and would need to use Reddit search to try and find it manually.
The individual site can still pick a referrer policy of their choice. If the referring site changes its referral policy, then that policy will be followed in the browser.
Chances are some websites such as publishers and blogs will change their default referral policy to keep displaying their referring traffic in full.
What is a referrer policy?
As a web user navigates from one site to another, servers are informed of the URL that the user is coming from. The same happens with different resources such as images and scripts within websites. A server knows the origin of the request when a request is made.
This is done using the Referer header (it is missing an R due to the original misspelling). The Referer header helps the server where the resource is hosted understand which website is requesting that same resource.
This mechanism can be very useful for many things including for website owners to understand which other websites talk about them, link to their content and where their website traffic is originating from.
What does Chrome’s new referrer policy default do?
From Google’s announcement: “strict-origin-when-cross-origin offers more privacy. With this policy, only the origin is sent in the Referer header of cross-origin requests. This prevents leaks of private data that may be accessible from other parts of the full URL such as the path and query string.”
This change means that the referrer header for cross-origin requests will be reduced and you will see the top-level domain (TLD) only in the referral sources of your web analytics.
This is an example of how referrals look like when shown with a full URL path in your Plausible Analytics dashboard:
With this new policy, if I link to your site on
myownblog.com/best-resources/ and someone clicks on that link, you will be able to see visitors coming from
myownblog.com in your web analytics but you won’t see the exact page URL (
So cross-origin navigation from one website to another will no longer reveal the full path or query string information. It will only reveal the top-level domain. It will look something similar to how Facebook’s current referrer sources look like. Facebook referrer only includes the fact that the visitor comes from Facebook. It doesn’t send the post or comment ID where someone clicked.
The idea with this new policy is to reduce the potential of unexpected leaks of personal information as URLs on some commercial websites may contain sensitive user data.
With the old no-referrer-when-downgrade the referrer shown is:
With the new strict-origin-when-cross-origin default, the referrer shown is:
What are the default referrer policies in other browsers?
Chrome is using strict-origin-when-cross-origin from version 85. Strict-origin-when-cross-origin is where the full path is sent if on the same domain but only sends the domain itself if going to another domain. Previously it used no-referrer-when-downgrade.
Firefox is using strict-origin-when-cross-origin from version 87. Same as Chrome.
Edge is using strict-origin-when-cross-origin from version 85. Same as Chrome.
Safari is using strict-origin-when-cross-origin. Same as Chrome.
Brave is using no-referrer where the referrer header is completely removed. It never shares the full URL even for same-origin requests and you cannot even see the domain name for cross-origin requests.
You can read more about referrer policies here.
The issue of dark traffic
As you can see, not every request from a browser will have the referrer specified.
You may be familiar with the “(direct)/(none)” referrer source in Google Analytics, the term “dark traffic” or the fact that your total visitors rarely match with the total visitors of all the referral sources combined.
Dark traffic covers all the traffic where the referrer is not passed. There are many mechanisms where the referrer is not passed:
When a user navigates via a mechanism other than a link on a page such as clicks from emails, clicks from documents, clicks from mobile messengers, bookmarks or by typing in the URL directly into the browser.
Whenever someone is moving from HTTP to HTTPS or vice versa, the referrer header is dropped.
Facebook referrer only includes the fact that the visitor came from Facebook. Facebook never sends the post or comment ID where someone clicked.
Twitter sets the referrer to their link shortener so you can see the shortened link but not the actual tweet that brought the traffic.
Google does not include the search keywords in the referrer so you can see that the visitor is coming from Google search but you cannot see which keyword phrase they used to find you. In Plausible Analytics, you can integrate your Search Console data to see these search queries.
Chrome’s latest change won’t make a difference in the amount of dark traffic that you see but it will create additional “dark traffic” within the specific referrer as you won’t be able to see the exact page the other site is linking to you from.
How can I set the referrer policy for my own website?
Strict-origin-when-cross-origin may be the new default on Google’s Chrome browser, but you can still pick a policy of your choice for your site. If no referrer policy is set by the individual website, the browser’s default policy is used.
Most non-commercial websites have no risk of leaking personal or otherwise sensitive data in their URLs. This includes blogs, personal websites, publishers and so many more.
You can set the new referrer policy with a
<meta> referrer tag which should be placed in the
<head> section of your website. Like this:
<meta name="referrer" content="no-referrer-when-downgrade"/>
Increased importance of tagging the links you can control
The reduced granularity in the referral sources data and the rise of dark traffic increases the importance of tagging the links that you can control.
To minimize the amount of traffic that falls within the “no referrer” category, you can add special query parameters such as UTM tags to your links.
When a query parameter such as the
?utm_source=<value> is present in a link, Plausible Analytics and most of the other analytics tools will show it as the referral source. Same works with the
source query parameters.
Read our guide on how to use UTM parameters to track your marketing campaigns.