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.: 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?

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 http://t.co/xyzxyz.

An Example

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

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.
  • Note that since Pro Webmasters has gone HTTPS-only and the shortened links above are HTTP - the Referer is no longer sent by the browser in the examples above (as noted in the "HTTPS - Secure connections" section). Unfortunately, I cannot edit the answer to either add a note or correct the links as the use of URL shortening services are now blocked across the Stack Exchange network. See: meta.stackexchange.com/questions/64450/… – MrWhite May 18 '17 at 7:54
  • The links should be replaced with a service that supports https (w3dk.com doesn't) since stackexchange is now in https and the referer il lost in https to http redirects – the_nuts May 30 '17 at 7:33

As a reference, this article lists many of the most popular URL shorteners and indicates what type of redirect they use.

http://searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204

  • Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – John Conde Jan 27 '14 at 15:28

It depends.

Under normal circumstances when using a web browser with Twitter or social media in general, clicking on a shortened link will show the original referrer in Google Analytics. 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 even across different protocols.

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:

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.