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.