What’s the Deal with Your Direct Traffic, and How to Fix It

2
406

If you see that your Direct traffic Described by Google as "users that typed your URL directly into their browser, or who had bookmarked your website" is higher than 30%, do not rush to pop some champagne and celebrate your company’s great popularity. It’s possible that Google Analytics has attributed some website visits to Direct traffic, where they don’t really belong.

Why does this happen? The reasons may be technical (broken sessions, redirects, etc.) and technological (unidentified traffic coming from mobile apps, emails, messengers, etc.).

What does this lead to? You won’t be able to correctly evaluate the efficiency of traffic sources that were mistracked as Direct.

In this article, you will learn how to find and fix causes that distort the statistics on traffic sources in Google Analytics.

Why are sessions showing up as direct traffic in Google Analytics?

This is how Google Analytics tries to identify a traffic source, step by step:

  1. Checking if there are any Adwords/DoubleClick parameters ( gclid Google AdWords auto-tagging parameter. This parameter is added to the landing page URL when a user clicks over to the website from an ad / gclsrc GoogleClick Search auto-tagging parameter ).
  2. Looking for UTM parameters Snippets of code that are added to an URL to send additional information about traffic sources to web analytics systemsUTM parameters (UTM_source/UTM_medium etc.). If you’d like more information about tagging your URLs with UTM parameters, see our blogpost.
  3. Checking if any HTTP referer One of the header fields in the HTTP Protocol, containing the URL of the webpage where the request originated was sent.
  4. Trying to identify a user by clientID or userID. Google Analytics checks for a match in the last 4 hours, and associates the hit data with the prior user’s session. For example, a certain user clicks a paid ad to visit your website on a mobile device, and within 2 hours makes a purchase at a brick-and-mortar store. The purchase data is sent to Google Analytics via the Measurement Protocol , and a user is identified by userID. This means that the hit (transaction data) will be associated with the user’s previous session that already has a traffic source (in our example, google/cpc).

Any of the above parameters would be sufficient to determine the traffic source. If none of the above is found, the traffic will end up being reported as Direct. A detailed data processing flow chart is given  in this Google Analytics support article.

In a nutshell, Direct is Google Analytics’ own smart way of saying "I don’t know".

In our experience, up to 15% of visits in large projects are reported as Direct, while not actually originating from there. The reasons for that can be divided into three groups: session breaks, session with no referrers, and other causes. Let’s take a closer look at them.

A referrer isn’t passed

HTTP Referer is an HTTP header field that contains the URL of the webpage from which a link to the requested page was followed. When a user clicks a link on a webpage to go to another webpage, the Referer of the latter will contain the address of the previous webpage.

Referrer data isn’t passed in the following cases:

  1. When links are clicked in offline documents: PDF, Word, PowerPoint, etc.
  2. If links are clicked in mobile or desktop apps: Skype, Viber, Facebook, VK, Google Search, etc.
  3. When links are clicked in email clients: Microsoft Outlook, Thunderbird, etc.
  4. Should data be sent via the Measurement Protocol without source/medium parameters set.
  5. If users are redirected, and neither HTTP referer nor UTM parameters are sent. For instance, when a user follows a link to site.com and gets redirected to site.net. In the case that neither HTTP header (including referrer data about the previous webpage from which a link was followed, eg. https://facebook.com), nor UTM parameters in an URL (eg. yourwebsite.com/?utm_source=facebook&utm_medium=cpm) are passed, the traffic will be reported as Direct. This error most often occurs if the redirect is made on the client side (using Javascript).
  6. When links on HTTPS webpages lead to HTTP webpages and have no UTM parameters. For example, if your website is HTTP (eg. http://my-website.com), the link leading to your website is placed on an HTTPS website (eg. https://www.youtube.com) and isn’t UTM-tagged, the traffic will be reported as Direct. The encrypted connection doesn’t allow for passing referrer data, as provided for in paragraph 5.5.2 of the RFC7231 Internet Standard.
  7. If users browse using Incognito mode or use script-blocking extensions such as ScriptSafe.
  8. When there are errors in the code. In some cases, cookies might be deleted because of errors in the script. As a result, the traffic will be reported as Direct. Also, referrer data won’t be sent if  a ‘rel=noreferrer’ attribute is used in the <а href=..> link code.
  9. Should it be that a browser does not pass referrer data. For instance, this happens with IE8, when redirect methods Javascript:location.href and Meta refresh — 0 are used. Also, Internet Explorer does not pass referrer data when users click links with window.open JS method, or when a link is clicked in a Flash app.
  10. Campaigns have incorrect UTM parameters (eg. UTMSource instead of UTM_source). If an URL has UTM parameters in it, Google Analytics ignores the referrer. If the parameters in your URLs don’t meet those prescribed by Google Analytics, visits via those URLs will be tracked as Direct.

Broken sessions

User sessions can be broken in the following cases:

  1. When there’s no GA/GTM code on the website’s landing pages. When the page has no Google Analytics tracking code and a visitor to the page goes to another page of your website, the first page’s URL will be tracked as a referrer, and there won’t be UTM parameters. If your website’s domain is excluded from the Referral Exclusion List, Google Analytics will report such sessions as Direct. In other cases the traffic will be reported as Referral.
  2. When users sign in with social networks by going to the network’s webpage instead of signing in via a popup window.
  3. If Google Analytics tracking code takes a long time to load, and a user leaves the webpage before the code fully loads.
  4. When the length of an encoded URL exceeds 8 kilobytes. The data won’t be sent to Google Analytics, resulting in a broken session.
  5. If cross-domain tracking is set up incorrectly.

Other causes of inflated Direct traffic

Your company’s employees visiting the website directly. This traffic can be excluded by IP addresses, by special cookies on corporate/intermediate pages, by using browser extensions or by filtering data in Google Analytics.

When website traffic is generated by bots. Bot IPs can be found in website logs, or using OWOX BI Pipeline, We recommend identifying bots:

  1. By on-site behavior, including: time spent on-site is less than 2 seconds, no transactions are generated, the bounce rate is high.
  2. By User Agent (browsers, providers, location, devices). For example, one common provider (site.com), one region (Mesa, USA).

Brief recommendations on troubleshooting

By identifying problems with Direct traffic, you will be able to see the correct statistics on traffic sources and, therefore, calculate your ROAS more accurately.

How to solve issues with sending referrer information:

  • Make sure all your URLs are UTM-tagged (read more about tagging in our " How to Use UTM Tags" blog post).
  • Create a hit-level custom dimension to store the referrer value, and analyze that data in Custom Reports.

How to find issues with broken sessions:

We have prepared a detailed troubleshooting guide to help you tackle issues with Direct traffic, and we hope you’ll find it useful. Just enter your email address, and we’ll send you the guide.

You might also like