: Is traffic coming from URL shorteners treated as direct? Traffic coming form shortened URLs like bit.ly, do they show up in Google Analytics as direct or do they keep their real referrer? Ex.:

@Twilah146

It depends.
Under normal circumstanses when using a web browser with twitter or social media in general, clicking on a shortened link will show the original referrer in GA. However, since many users are using a mobile phone and social media apps instead of a browser, you'll end up with direct traffic. If you filter your ga data you will likely see a lot of direct traffic from mobile.

How to solve this?
It is actually quite easy. Add campaign tracking variables to all your urls before you shorten them. Then you can see everything correct in ga. With campaign tracking I mean adding utm_source, utm_medium and also utm_campaign url variables. That is the best way of solving this no matter what shortening service you are using and ever across different protocols.

Vote Up Vote Down

@Rambettina238

As a reference, this article lists many of the most popular URL shorteners and indicates what type of redirect they use.
searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204

Vote Up Vote Down

@Alves908

The URL shortening services bit.ly and goo.gl (see note about tinyurl.com below) return a 301 Moved Permanently HTTP status - ie. a URL redirect. The browser then sends a new request to the new (ie. long) URL, passing the referer again. AFAIK this is the same for most mainstream URL shortening services.

If the service performs a 301 redirect (as it should) then the browser repasses the referer. In this case I can see no reason for Google Analytics to not show this referer in its reports.

Note, however, that the browser itself can be configured to suppress the HTTP referer, or even send something completely erroneous.


Traffic coming form shortened urls like bit.ly, do they show up in
Google Analytics as direct or do they keep their real referrer?


They keep the real referer. This might also be "direct", if indeed it was a direct request.


Ex. If someone types in a bit.ly link it counts as direct, but if
someone clicks a bit.ly link from Twitter, it counts as referral
traffic from Twitter?


Yes. Note that twitter now wraps all its URLs in its own URL shortening service, so the referring URL is of the form t.co/xyzxyz.
An Example

The following shortened URLs all redirect to a page that shows the HTTP referer.

bit.ly/checkreferer http://tinyurl.com/checkreferer (see important note below regarding tinyurl.com) goo.gl/7AJgP

You can see that by following any of the above links, the HTTP referer is passed (providing your browser is set to do so). If you copy and paste the URL in a new browser window then no referer is passed - it is a direct link.

tinyurl.com (Updated 2015-08-08)

I don't know if this is something new, but I've just noticed that tinyurl.com only performs a regular 301 redirect (and sends the HTTP Referer) on the 2nd and subsequent requests made by a user!? On the very first request tinyurl.com appears to load an intermediary page and then issues a (JavaScript?) redirect! This results in the first request returning a 200 OK status and the referer being set to the shortened "tiny" URL! (And does something peculiar with the browser history.)

However, on the 2nd request you get served a standard 301 redirect and the expected HTTP Referer is passed (this will also be cached). (I guess this might be determined by a tinyurl.com cookie that is set during the first request?)

2015-08-09 : I previously tested the above using a new incognito window in Google Chrome, however, it now seems to be resulting in a 301 redirect regardless - so, not exactly sure what is going on with tinyurl.com, was it just a "glitch"?!

HTTPS - Secure connections

Just an additonal note about links from secure content (HTTPS) to non-secure content (HTTP) - this affects any kind of link, not just URL shorteners. In this case the HTTP referer header is not set by the browser.


Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.


Source: RFC 2616 Section 15.1.3

JavaScript Redirect

However, a JavaScript redirect will destroy the original referer. No Location header is set and you only see 200 OK HTTP Status Codes.


This page does a JavaScript Redirect to the same page as above (which shows the HTTP Referer). But instead of passing the original Referer (ie. this page), the HTTP Referer is the intermediary page that contains the JavaScript redirect.

Vote Up Vote Down

@Jamie184

I did some research and found that; the traffic categorized by Google Analytics will be vary by URL shortener website.

Refer to this link for more information:

www.fathomdelivers.com/twitter-url-shortener-google-analytic/

Vote Up Vote Down