Since Yahoo traffic is quickly turning into “direct traffic,” it seemed like a good idea to re-post this (see item 18). This post is one of the most frequently-cited posts we’ve ever done.
“Direct Traffic” is a legacy label that no longer makes sense. Once upon a time, in long-ago simpler days (approximately 2003), the absence of a referrer in log files could only mean that somebody typed your site’s name into the browser’s address window, or used a bookmark, which amounts to the same thing.
Here’s our current list of reasons for an empty referrer field, a.k.a Direct Traffic, or as it should be called, “Unknown Referrer Traffic.” (Webtrends 10 does call it “Unknown Referrer,” I’m happy to say.)
Although this list will help you find ways to reduce your Direct Traffic to more realistic numbers (i.e. closer to just reporting on #1), Direct Traffic is still a mess. Or, as Jacques Warren once said, “I, for one, never use Direct Traffic in my reports and analyses anymore. It’s full of unreliable crap.”
- Somebody really did type in the address, or used a bookmark to get to your page.
- They clicked on a link in an email. (Recently, this includes webmail servers also. They don’t pass “mail.yahoo.com” and the like any more.)
- The link was in a document, Excel workbook, or PDF
- The link was in Skype, GTalk, or AIM
- The link was in a mobile app and opened your site in a (mobile) browser. For example, clicking on a URL in a tweet viewed in a Twitter app or client, or a mention seen in a Facebook app.
- The link originates at a secure (https:) page and your page is not secure (http) (this sometimes includes web mail servers)
- The link originates at a secure (https:) page and your page is secure (https:) for certain browsers, but not all
- Spiders and bots were working from a list of URLs from a previous crawl (this one mostly applies to server logs, rarely to SDC)
- Spiders and bots may be programmed to suppress the referrer information (this one mostly applies to server logs, rarely to SDC)
- The link to your site is from within a Flash application (mostly a problem with IE) (there are a lot of ways to do this in Flash so there may be exceptions)
- Your landing page redirects to another page via a 302 temporaryserver-side redirect
- The link was on an intranet or some other web site behind a proxy or corporate gateway that was set up to strip referrers from requests
- The visitor has made changes to their browser that suppresses the referrer information
- The visitor has set one of your pages as their browser’s home page or a pinned tab. This is especially a problem where you’re a big company and your employees have the site as their home page … but you should be filtering out your own company’s IP addresses in the first place.
- Another site has put your page content into an iFrame and coded the frame to suppress the referrer, in order to make it difficult for you to find out who is framing your content
- Certain A/B situations where visits directed to the B page group are redirected via 302 from the control page (A) to B too quickly for the tag to fire on A. Check with your A/B vendor about whether this might happen with their product.
- Starting early 2014, they came from any Yahoo Search, if your landing page is http rather than https. The complete anonymization of Yahoo Search traffic will be complete March 31 2014.
- Starting early 2014, they came from Bing secure search (secure search is optional to Bing users at this time, but may in the future follow Yahoo’s lead).