Self-referrals in your reports are one of the most common red flags that indicate a problem with your code installation. However, it’s common for a small number of self-referrals to show up even if the implementation is done correctly.
If you see your own website under the All Traffic or Referrals report in Google Analytics, it may be a symptom of bad or missing code on your site. If the number of self-referrals are too high, they could be inflating your data and masking your referring sources. In addition to the recommendations in this article, you should also use web log analysis software in conjunction with Google Analytics so you’re not 100% reliant on tracking code.
Why are there self-referrals?
Self-referrals are caused by the tracking code seeing a new traffic source for the visit, usually because it rewrites the cookies. This could be due to the cookies expiring or the cookies not existing on the current domain.
Small numbers of self-referrals
The most common scenario for “legitimate” self-referrals is when a visitor comes to your site and then goes idle or works in other windows for more than 30 minutes before coming back to your site. At that point, the visit has expired. If they click on a link on your site, it will start a new visit, and it will appear that the page they were idle on was the source of the visit. If the number of self-referral visits is a small percentage (< 5%) of overall visits, it can probably be ignored. Such a small number is not impacting the overall numbers enough to warrant the time and energy it would take to track down an issue that might not even exist. Multiple domains
If you are using multiple domains in your site, you need to have cross-domain tracking set up. If you already have that set up, and you still see self-referrals, it probably means that some pages aren’t coded correctly or got missed altogether.
In Google Analytics go to Traffic Sources -> Referring Sites. Find your website listed there and click on it. You’ll want to look at two things.
Referral paths: The table it brings up will list all of the referral paths from that site. This is the page the visitor came from to get to your site.
Next, change the Dimension dropdown to Landing Page. This shows you all the pages on your site the traffic came to.
You are looking for specific pages that have really high numbers. That would indicate that the code is wrong or missing just in specific places. If the referral paths all have correct code on them, make sure the landing pages also have correct code. Most notably, they both need to have _setAllowHash(false) and _setAllowLink(true). And the referral page should have each link tagged with _link().
If your site uses multiple subdomains, the tracking cookies could be written to a specific subdomain. In this case, they won’t be recognized when the visitor moves to another subdomain. This can even happen if the visitor goes to mysite.com and then to www.mysite.com.
Use the same method as for multiple domains to see if specific pages are the culprits. Then fix it by adding _setDomainName(‘.mysite.com’), with no subdomain specified.
If visitors have a tendency to keep your site open in the background for long periods of time, their cookies will time out and their next click will start a new visit as a referral from that page. This is common on news sites or blogs that are frequently updated throughout the day or that a visitor might read in their spare time. If the Referring Sites report shows an even distribution of referral paths and landing pages, this is likely the issue. Confirm this by looking at average time on page and average time on site. Very high numbers would also indicate that visitors are getting interrupted while reading your site and then coming back to it.
The best solution to this would be to increase the cookie timeout. One of our clients was a major newspaper, and we recommended that they increase their cookie timeout to as high as 90 minutes. This way visitors who get interrupted but keep the site open in the background will still count as a single visit.