If you’re using Universal Analytics, including Mobile App Analytics, it’s unlikely you’ll see many self-referrals in your reports.
Background
When a user arrives on your website, Analytics works to determine where they’ve come from - their traffic source. The source may be classified as direct, organic (unpaid), campaign, or referral.
Referrals are generally defined as traffic to your site from another website. With the Referrals report in the Acquisition category of reports, you can analyze this type of traffic.
How do I know if I have self-referrals?
A self-referral in Analytics is a condition where you see your own domain(s) show up in the Acquisition>All Traffic>Referrals report. For example, if your website is www.example.com, any entry you see in this report that lists www.example.com is a self-referral.
If your Analytics implementation is configured to measure sessions across multiple domains and/or subdomains, a marginal level of self-referrals may be natural.
However, many self-referrals may be a symptom of an issue with your Analytics implementation, and may be skewing your metrics and obscuring the actual sources of traffic to which key events and other engagement on your site should be attributed.
Determining the origin of self-referrals
analytics.js
If your pages are tagged with the analytics.js snippet, then you need to make sure that you have added all of your own domains (including subdomains) to the Referral Exclusion List for your property:
- Sign in to your Analytics account.
- Click Admin and navigate to the property you want.
- Click Tracking info.
- Click Referral Exclusion List.
- Click + ADD REFERRAL EXCLUSION.
- Enter the domain you want to exclude, then click Create.
ga.js
If your pages are tagged with the ga.js snippet, then unfortunately there is not a single common cause of self-referrals; in fact there are many different scenarios that can lead to a self-referral. What this guide will attempt to do is give you a list of the most common causes which we have seen on client websites. Follow this guide as a checklist to narrowing down the underlying cause of your own self-referrals.
To assist you in locating the potentially problematic sections of your own content we have included the following view filter and custom report which we have found useful when troubleshooting self-referral issues. Expand each section for details:
View FilterTo help narrow down the cause of self-referrals, navigate to the Acquisition>All Traffic>Referrals report.
When you see an entry for 1 of your own domains, drill down into the row to view the referral path dimension. These referrals paths could be pages on your site worth investigating further.The referral path dimension will tell you a little bit about the page someone was on before navigating to your site. However, by default the referral path does not include the query parameter portion of the referring URL, which can be valuable information. To see the full referring URL, including query parameters, we need to create a view filter.
Take the following example referral path:
/path/sub-path/?query=123¶meter=456
By default the referral path report will only show:
/path/sub-path/
Use the following view filter to restore the full referral path in GA reports:
Warning: Before applying any filter to an Analytics view, we strongly recommend creating a new test view (learn how to copy a view). You should always keep an unfiltered view for reference, which can act as a raw data backup and as a source for you to make sure your data collection is working properly.
The filter we commonly use can be constructed as follows:
View Filter Attributes
- Filter Name: Show Full Referring URL including parameters
- Filter Type: Custom Filter => Advanced
- Field A -> Extract A: Campaign Medium, ^referral$
- Field B -> Extract B: Referral, ^https?://[^/]+(/.*)
- Output To -> Constructor: Campaign Content, $B1
- Field A Required: Yes
- Field B Required: No
- Override Output Field: Yes
- Case Sensitive: No
Common causes and solutions for self-referrals
There are several common reasons for self-referrals. Expand each section for details:
Tracking Code Missing or Not Working on Landing PageA common cause of self-referrals is landing pages or pages on your website that are not tagged with the Analytics tracking code. The Google Tag Assistant plugin for Google Chrome can help you discover problems with missing and or non working tracking code.
You must ensure that all pages of your site have the Analytics tracking code installed on them.
Use the custom report and view filter mentioned above to help you narrow down the page(s) with missing or broken code.
One of the most common causes of self-referrals is caused by tracking code configuration inconsistencies. The following methods alter the way Analytics cookies are set and stored for your domain(s).
It is extremely important to call these methods consistently across your entire website. If you call these methods inconsistently on the same or even different pages of your website, this can cause Analytics to either reset or create a new cookie set. In either situation Analytics tries to determine the campaign source, it is at this point that a self-referral often occurs.
Let’s look at a few examples where this can occur:
Sub Domain Tracking Example:
Sub domain tracking is a common configuration, you can learn more about it here. However some websites utilise multiple template files and require the Analytics tracking code to be inserted in multiple places (i.e a global include is not used throughout the entire site). In cases such as these check each of your template includes to ensure they contain a consistent Analytics tracking snippet.
Assume the above example where the homepage and product pages utilises 1 template and the shopping cart pages utilises another.
Incorrect
Homepage: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Shopping Cart Page: (basket.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push([‘_trackPageview’]);
In the example above, users who move from the homepage to the shopping cart page will have 2 cookie sets (utma, utmb, utmz) created for their session(s). 1 set under each domain:
- example.com (home and product page)
- basket.example.com (shopping cart)
Not calling _setDomainName has the same effect as calling _setDomainName(‘auto’). Using the document.domain method will cause ga.js to create cookies for basket.example.com.
In order to prevent self-referrals in this situation, you want Analytics to read from 1 set of cookies regardless of weather or not the user is on the top level domain www.example.com or the sub-domain basket.example.com.
To ensure 1 set of cookies is used for your parent domain and its sub-domains. Include the _setDomainName line in your Analytics snippet across your entire website.
Solution: Ensure your tracking code consistently calls methods that alter the way the Analytics cookies are defined.
Correct
Homepage: (www.example.com)_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);Shopping Cart Page: (basket.example.com)
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);
Multiple Analytics Tracking Code Example
A popular but generally unsupported configuration that many clients use is multiple tracker configuration. This is used to send information to multiple Analytics accounts simultaneously.
A common misunderstanding of this configuration is to assume each tracker is a separate entity (or object), but in actuality cookies are set at the domain level and not tracker level, so all tracker objects on the same page share and read from the same cookie set.
Therefore consistency with your tracking code across multiple tracker objects is just as important as being consistent across all pages of your website as in our sub-domain example above.
Incorrect
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], ['secondTracker._trackPageview'] );
Notice how the secondTracker has not called the _setDomainName method? This will potentially lead to self-referral issues for both trackers and web-properties UA-XXXXX-1 and UA-XXXXX-2
Solution: Always ensure that all tracker objects on the same domain call the same methods i.e are configured the same to prevent the chances of causing a conflict between trackers. In the following example _setDomainName is called consistently for both trackers.
Correct
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], [‘secondTracker._setDomainName’, ‘example.com’], ['secondTracker._trackPageview'] );
Cross-Domain Tracking Example
Another common configuration of Analytics is tracking user activity across multiple top-level domains. Learn more about cross-domain tracking
When you have 2 domains eg: www.example.com and www.otherexample.com and you wish to track activity as users move between these domains, you are required to use 1 of the following methods:
These methods allow Analytics cookie data to be passed between domains. The method you use will depend mostly on the way users move between domains i.e they click a link or submit a form, open an iframe etc..
However a common problem we see is that not all links, forms or iframes are tagged correctly in order to pass information between the different domains.
Example HTML page (on www.example.com)
Incorrect
<html> <head></head> <body> <a href="http://www.otherexample.com/" onclick="_gaq.push([‘_link’, this.href]); return false;">link 1</a> <a href="http://www.otherexample.com/page2">link 2</a> </body> </html>
In the above example link 1 is configured to pass Analytics cookie information to otherexample.com, however link 2 does not contain the onclick attribute.
Users who click on link 1 will be tracked accurately across domains. Users who click on link 2 will register as a referral from example.com
Solution: You should ensure all links are appropriately tagged to pass cookie information from example.com to otherexample.com
Correct
<html> <head></head> <body> <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a> <a href=”http://www.otherexample.com/page2” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 2</a> </body> </html>
Tip: If you have multiple links leading to another domain, you can leverage a Javascript framework (eg: JQuery) to listen for onclick events that pass users to your other domain(s).
This will save you from tagging each link manually and is the unobtrusive and preferred method of handling cross domain links.
Redirects between domains
We will cover redirects in more detail later in the article, but another common cause of self-referrals with cross-domain tracking is when a redirect removes the cross domain cookie information before Analytics ga.js has a chance to read this information from the URL on the receiving domain.
Referring to our previous cross domain HTML example again:
Example HTML page (on www.example.com)
<html> <head></head> <body> <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a> </body> </html>
The _link method will generate a Analytics cross domain URL like below:
http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
However if a redirect occurs on the home page:
http://www.otherexample.com/
and it forwards users to:
http://www.otherexample.com/home
The redirects may neglect to include the Analytics cross-domain information and pass it to the redirected URL.
http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
Redirects to:
http://www.otherexample.com/home
Note: The absence of the Analytics cross domain parameters (?__utma=......).
This often happens because many server side based redirects fail to take into account the query parameters present on the previous URL. The redirect rule simply moves users from 1 URL to the next but doesn't preserve these cookie parameters during the redirect.
Solutions:
-
Ensure the redirect carries the Analytics tracking parameters to the next URL eg:
http://www.otherexample.com/home?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
-
Alternatively you could also remove the redirect or update the link on the previous domain(s) to point to the new location so no redirect is invoked.
Do you use a mobile sub-domain or do you have a mobile dedicated version of your site on the same domain?
A common practice is to create a mobile version of your website that is accessible from a sub-domain eg: m.example.com
If you have configured the mobile version of your website to use the server side Analytics tracking library (PHP, JSP, ASP.NET, and Perl) - commonly referred to as WAP tracking and users have the ability to navigate between the mobile version and full version of your website, you may see self-referrals from your mobile and primary domains.
If your mobile pages do not use the regular ga.js tracking code, the effect is the same as having untagged pages on your website.
The primary purpose of the WAP tracking library is to allow tracking of low end mobile devices i.e those devices with limited support for cookies and / or javascript.
However many of the latest smart phones now support javascript, cookies and images just like regular desktop machines. Due to increased adoption of smart phones, we recommend migrating your mobile pages to use the regular ga.js tracking snippet instead of using the WAP tracking library.
Do redirects cause self-referrals? For the most part redirects should not cause self-referrals - for an exception see the cross domain section of this document. Let’s look at a few examples of redirects and their impact on campaign setting in Analytics.
301/302 redirects
This type of redirect is a server side invoked redirect and sends the HTTP status code of 301 or 302. Your webmaster will have implemented such a redirect and the most common reason for doing so is that a page or group of pages has moved location.
301/302 redirects should preserve the original referral information.
Example:
In the above diagram a user on some-other-website.com clicks on a link pointing to your homepage at example.com, a server side 301 redirect takes place and forwards users to the new URL for your homepage /home.
In this scenario the 301 redirect should preserve the referral information (captured via the javascript document.referrer) from some-other-website.com.
meta refresh and javascript based redirects
Non server-side invoked redirects such as the meta refresh html tag or javascript window.location methods may hide or obscure referrer information from Analytics, therefore we don’t recommend using such methods on any page that is likely to be a landing page.
To learn more about the impact using iframes with Analytics and the potential for self-referrals refer to the following article on framed sites and Analytics.
Do you leverage the Flash Tracking APIs? When working with this tracking library you will ideally wish to use Bridge mode as opposed to AS3 mode learn more here. Using Bridge mode allows the Flash tracking library to communicate with the same cookies as the regular ga.js tracking code. This means that activity within a flash object can be traced back to the correct campaign source i.e the source used to find your website.
When using AS3 mode the library will use Flash cookies. To determine campaign source the library will look for the referring URL used to open the flash object, this is usually your own website (parent page) eg: www.example.com
