Google Analytics is great about categorizing traffic from various sources, so you can see it at a glance. How much of your traffic comes from social networks, versus how much comes from organic search, versus how much comes from email referrals? All you have to do is click the acquisitions tab, and under “all traffic,” just click channels. You’re even given a nice pie chart if you want.

There’s one particular referrer, though, that will eat up a lot of your pie chart and it provides virtually no information. It’s labeled “direct traffic” and it’s the most frustrating thing. So what is direct traffic, where does it come from, and what can you do to learn more about it? It’s similar to the Unknown traffic sources, but a different issue.

What Is Direct Traffic?

Direct traffic is, actually, exactly what it sounds like. It’s just a difficult concept to intuitively grasp if you’re not immersed in analytics data. Essentially, it’s traffic that comes directly to your site without passing through another referrer. If a user clicks a link from your Facebook page and lands on your site, that’s a referral from Facebook, which is categorized as social. If a user runs a Google search and clicks your link in the results, they’ll show up under organic search. If they see a sponsored ad for you in their search results and click that, it’s paid traffic.

What happens, then, if someone opens up their browser and, from a new tab, types in your URL? They arrive on your site, but they carry no referral data with them, because they didn’t arrive from another site. That’s a direct view.

Now, if you’re seeing 25%, 30%, 40% or more of your traffic coming from direct sources, you’re probably skeptical. You don’t have THAT many people just typing in your URL, do you? Well, no, you don’t. Very, very few sites have that high an amount of direct referrals. Facebook might, because they’re commonly bookmarked or typed in, not linked to. They’re the referrer, not the referred.

The way Google Analytics works, though, provides more examples of visitors categorized as “direct sessions”, some of which are minor bugs, and some of which are unfortunate side effects of the way Google handles sessions.

• If a user types in your URL into a new tab or window in their browser, you’re getting a direct session. This is the ideal way of recording direct sessions.
• If a user opens your website via a bookmark, they are visiting direct. Bookmarks are just shortcuts to typing out URLs, so there is no functional difference between a bookmark and a typed URL.
• If a user clicks a link from an email, it may not pass referral data, depending on the email provider they’re using or the software they’re browsing their email through.
• If a user clicks a link to your site that is embedded in a Word document, Excel spreadsheet, PDF, or other non-web file, that document or file is not going to pass referral data. This creates a new direct session. This means active links in an ebook you provide aren’t going to pass data, and will count as direct traffic.
• If a user clicks on a shortlink, it might not pass referral information. Some shortlinks do, like Twitter’s t.co, which will show up as Twitter under social.
• If a user clicks on a link within an app on a mobile device, that may create a new session that does not have referral information attached. A mobile app needs to take special care to implement referrals, and most do not.
• HTTPS, the secure SSL-based version of browsing the web, often strips off referral data. Going from one SSL page to another SSL page will pass data, but going from a HTTPS URL to a HTTP URL will often strip referral information.
• Occasionally, Google will straight up fail to report referral information from an organic search link. Bing has this issue as well, as do all of the other search engines. Groupon actually did an experiment and found that as much as 60% of their direct traffic may actually have been organic, just misreported.
• If a link is encoded through JavaScript or another sort of obfuscation, it won’t show up normally, and thus clicking it won’t trigger the normal actions like producing referrer data.       This means links hidden in scripts may not have referrer data at all and will show up as direct.
• Using the search term exclusion list in Google Analytics will exclude search terms from your organic search results, which cleans them up somewhat, but it also causes traffic coming in from those search terms to be shunted to direct traffic.

With all of these various issues contributing to direct traffic, it’s no wonder that it can take up a significant percentage of your reporting. Unfortunately, direct traffic doesn’t give you a lot of information on its own. It’s hard to sort, filter, or categorize, because the usual information you would sort by is missing. Fortunately, many of the above issues can be solved.

Fixing Direct Traffic

One of the easiest fixes for some direct traffic comes from that last bullet point. If you have any search terms excluded from your reporting, you’re going to want to remove them. Yes, I know, it makes your organic search results more cluttered. If you were filtering branded mentions, for example, so you could see organic searches, that’s removing a lot of information. Give a review to your search terms exclusion list and see if there’s anything you want to remove.

You can find the search terms exclusion list in Google Analytics, under the Tracking Info section. You can add and remove terms there. You can also read about how the feature works and what it does via Google’s help center.

One thing to note is that any change you make via Google Analytics will take time to roll out going forward. Google’s filters and changes do not apply to data retroactively, they only apply from the moment you make them. If you remove a search term exclusion and then go check your data, it will be the same; you don’t have new data with the new measuring yet.

The second change you can make is, if you haven’t already, is implementing sitewide SSL. You lose referral data from HTTPS sites if they link to you and your page is HTTP only. By implementing HTTPS, you maintain that referral data.

There are pros and cons of site-wide SSL, but be careful when you research it. A lot of the search results come from older – as in 2010 and earlier – threads, where it was a lot less common to see HTTPS sites, and many of the issues hadn’t been worked out yet. It’s a generally good idea these days to use a secure connection throughout your site. Plus, Google has started using HTTPS as a minor ranking factor. If you want a minor boost to your search ranking, you can get it by implementing HTTPS.

Plus, SSL is security. It helps prevent hacks and attacks on your site. That’s never a bad thing.

The third thing you can do is make heavy use of Google’s UTM parameters. UTM parameters are add-ons to links that pass referral data mechanically, rather than requiring that the referring site make that data accessible. It also doesn’t override the data from a referrer. For example, if you post a UTM-site link on Facebook, but someone shares the link as-is on Twitter, you will see that link as coming from both sites. You have the Facebook referrer from the UTM source, but you have the t.co shortlink version as well. This might get messy if you have a lot of cross-sharing, but that probably won’t be the case. The benefit of getting more of your direct traffic properly categorized is much better.

To add UTM parameters to a URL, you need to use Google’s URL builder. You can find the tool and its documentation here.

For reference, UTM parameters are insanely useful for a lot of different purposes. In addition to minimizing your direct traffic and properly categorizing your user sessions, you’re able to use it for conversion tracking and a whole host of other purposes. We’ve written about using UTM parameters for conversion tracking in detail here.

UTM parameters solve several issues at once. If you use a link with UTM parameters through a URL shortener, you will still maintain those parameters, and get referral data. Use the link on a file like a Docx or a PDF and you get that data passed as well. Likewise, add UTM parameters to links you send out via email and you’ll have newsletter links categorized properly as well.

Another issue that can arise that leads to direct traffic is simply forgetting to apply analytics code to your landing pages. If you have a landing page that links to your main site or to a product page, that landing page really needs to have analytics code on it. In fact, there’s no reason every page on your site shouldn’t have analytics.

If you have a page on your site that doesn’t have analytics code, and a user clicks an internal link, the referral will be your own site. Since that’s identical to directly typing in the URL of your site, it shows up as direct traffic. Even if they came from some other source, like a paid ad or a social link, that referral data is stripped by the page that lacks analytics.

You may want to go through your site and make sure your Google Analytics scripts are functioning properly. If you haven’t done a full site audit in a while, it’s possible that something hasn’t been functioning properly. It pays to check it out.

A related issue is the placement of the analytics code. If you place Google Analytics anywhere other than your site header, it will load after everything above it has loaded. If a user clicks through your content quickly before the script loads, it’s the same as if they had landed on a page that didn’t have tracking code at all. No referral data is passed along or recorded about their session.

Another site audit thing to check is any redirects you may have implemented in the past. 301 redirects are fine; as permanent redirects, they act in analytics as if they don’t exist, passing all referral data along the pipe. 302 temporary redirects, though, or script-based redirects, may not pass data. This can be an issue with direct traffic as well.

One direct traffic issue you can’t solve on your end is users who browse the web with scripts turned off or with NoScript blocking them. Blocking Google Analytics from running means that the analytics code won’t run. Depending on how you have things set up, a different script might still run and record data, while Analytics won’t. Thankfully, most of the time these sessions are just invisible, they don’t show up as direct traffic or as anything else. It’s only when you have different analytics scripts and only one of them is blocked that you encounter data discrepancies.

Another issue might be if your company has its computers set to use your live homepage as the browser homepage that loads when a user starts the browser. This will count as direct traffic, even if the user doesn’t care about browsing your site because, you know, they work there. These will often count as bounces, too, so eliminating this issue will do wonders for your stats.

One final edge case is if you have different subdomains, like blog.example.com, store.example.com, and normal example.com, you may have used each one as its own web property in analytics, using its own analytics code for each. This means each of them will pass odd or different referral data, much of which will show up as direct, or at least not as internal as it actually is. If you’re using more than one analytics property for one site, consolidate them all.

Note: this doesn’t mean you should consolidate one analytics property for several sites. If your sites are distinct, they should be distinct properties. It’s only for subdomains that this implementation may have come up.

Join the Discussion

No comments yet. You could be the first!

Built for advertisers.
Set your budget, target your visitors, get traffic.

Drive thousands of targeted visitors to your website, online store, or affiliate links, and use powerful geolocation and interest targeting. Track your campaign daily in our reporting dashboard. Change your URL at any time and split test between multiple pages to see which performs best.