In the web world, 'redirection' is a double-edged sword. While it can be great for purposes of easier user navigation, it can wreak havoc when it comes to web analytics. In this article, we'll talk about the different ways that redirection can be used and which of the methods best lend themselves to analytics.

(Note: This article is best enjoyed with a strong cup of coffee and some time to really think through the information we're providing.)

So, first off, what is redirection? No, it's not the technique that magicians use to fool you, although it can be tricky. It's actually a technique used to 'redirect' a visitor from one web page to another -- automatically. In other words, it's the process by which traffic that is destined for one location is sent to another.

Still with us? Great! Let's keep going. When it comes to redirection, there are three major types:

1. Client-side redirect

2. Meta refresh redirect (which is a special type of client side redirect)

3. Server-side redirect

Both the client-side redirect and the meta refresh happen after the web page has loaded (therefore occurring on the client machine). So, the idea here would be that once a visitor comes to a certain page, a JavaScript (or some other scripting language like vbscript) snipit or a meta tag (HTML), will magically transport the visitor to another page. Ultimately, the result is two page requests in the log file: one for the original page on which the redirect resides (or the redirector page), and one for the destination page after being redirected.

The third type of redirect is the server-side redirect. This kind of redirect is performed by the web server itself, meaning either via an .htaccess file or the server-side scripting (ASP, JAVA, etc.). The result is the same as the client-side redirect except the request is logged as a 300-level redirect, which has special implications for user and spider navigation (see below). So, now we have one 300 level status for the redirector page and one 200-level status for the destination page. (Notes on 200-level status and 300-level redirect are at the end of the article.)

What Redirection Means to Analytics

What does it all mean when it comes to Web analytics? Glad you asked. All this redirection can confuse most Web analytics tools and posed a challenge for the ClickTracks' Navigation Report -- especially when your links point to URLs that are redirector URLs. Why?

1) If the redirector page uses a client-side redirect then all works well. For example, if you're looking at the home page in the browser view, and on the home page there is a link to a redirector page that uses a client-side redirect, ClickTracks can correctly display the number of clicks to that link. This is because the URL that this link is pointing to will be logged as a standard page request (200-level status).

2) If the redirector page uses a server-side redirect, it gets a little more complicated. For example: Imagine that once again, you're looking at the home page in the browser view, and on the home page there's a link to a redirector page that uses a server-side redirect. This page gets logged as a 300-level status and therefore is invisible to the Browser view.

The fact that this page gets logged as a 300-level status means that no request was made to this page; Therefore leading ClickTracks to display the number of clicks to this link as 0 clicks (0%), which is true since the browser view counts page requests.

Ultimately, You Want to Know Who's Reaching the Destination Page

Not to worry--this is what the "Path View" is for (bottom frame in the Navigation Report). In the "Next Page" section of the Navigation Report, ClickTracks displays all of the possible next page destinations from the home page. You'll find the destination page that the redirector page redirects to in the Next page section of the Path View. Why is this? Because the destination page results in a 200-level page request.

For the foreseeable future, redirects will continue to be used to simplify URLs and guide visitors using more logical paths. While this can potentially confuse Web analytics, use of the Path View in ClickTracks can give the Web site analyst a more accurate view of visitor behavior on the Web site.

Definitions

200 - FOUND OK
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

Check Server Headers - 200 HTTP Status Code Checker Admin Note: The 200 Status-Code means that all is okay. This is what should be returned if the requested resource is valid.

Example of HTTP Status Code 200:

Server Response: http://www.seoconsultants.com/w3c/status-codes.asp
Status: HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 30 Jun 2003 05:31:00 GMT
Content-Length: 25468
Content-Type: text/html
Cache-control: private

10.3.3 - 302 FOUND
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

Check Server Headers - 302 HTTP Status Code Checker Admin Note: From my perspective, a 302 should not be used when parking domains or capturing type-in traffic. The server is returning a 302 Found (temporarily moved) which is not correct.

If you 301 Moved Permanently a resource, then the spider is instructed to ignore the current location and redirect to the new location. In Google's instance, you would be effectively transferring PageRank to the new resource.

Comments (1)

Subscribe to this comment's feed

Name

Email

Title

Comment

smaller | bigger

I have read and agree to the Terms of Usage.

Add Comment