Monthly Archives for June 2009


A Robust SiteCatalyst Implementation Could Fail In Internet Explorer

As you get further along with using Omniture SiteCatalyst, you may begin to receive requests for additional items to track. As the members of your organization start to feel more comfortable with the system, they will begin to explore all of the possibilities of things to report on and will soon begin to ask for more parts of the site to be recorded. Soon you will find your implementation has become pretty advanced. This is when you start need to take a look at one thing that is often overlooked, your image request URL length.

Why do we need to care about this? It lies in an inherent deficiency of Internet Explorer. IE can not accept a URL that is longer than 2083 characters. If your implementation is pretty complex and you are passing in a lot of variables, your image request can easily approach if not exceed that amount. Since Microsoft still commands the lion’s share of the browser marketplace, this is something we need to keep an eye on. If this was a problem with Opera or another third or forth tier browser then we may not worry about it. But this is not the case with Internet Explorer.

I have experienced this error with a site I manage, but lets take a look at one that’s out there that I have nothing to do with. For this example were going to take a look at I’m pretty specific about what I’m looking for so when I visit the site and search for an apartment, I will select a handful of amenities and other items I specifically want. When I finally land on the search results page this is where you can see the error. Here is the page I land on after doing my search. When I launch Firebug and take a look at the image request that was sent off to Omniture, which you can see right here, for me it comes in at 2653 characters. If you try to open this link using an IE browser, you will see that you get an error screen, but try in any other browser and you will get a blank white screen, indicating a successful delivery of the tracking pixel. NOTE: Now before I get any emails, I did this in firefox. If I was originally using an IE browser, I would not have had the &p= element of all of the browser plugins. Removing this and the image request is still at 2373 characters and still will fail in Internet Explorer.

So how do we correct this? The biggest thing one can try is to use Classifications. No need to submit full friendly names for your variables. A simple abbreviation or other nomenclature can reduce your character count. In the example above they could have used 01 for “washerdryer” or 02 for “dishwasher”. Anywhere you can use Classifications you should do it.

Now what do we do when there is nothing left to classify and the string is still way too long? When there is nothing left to do then you may want to consider breaking your image request into two calls. Now this is not the ideal method, but I do have it working successfully. In my situation, I have a classified ads site where I am passing in product id numbers for each product that is shown in my search results pages so I can get ad impressions. My visitors have the option to display up to 100 listings per page. That will blow up the products string to a crazy length, and therefore kill my image request string length. By using a modified version of the Custom Link Tracking, you can fire off a second request on each page that you feel your string length will be too long. Having to make the choice of employing a second server call or not being able to track a main page of your site is not much of a choice at all (in my opinion). If anyone has any other solutions or work around I’d love to hear them :) .

Take a look at your image request sting lengths. You could be missing out on a lot of valuable user data.

Get More From Your Campaign Tracking using the clickThruQuality Plugin

NOTE: UPDATED 7-22-09 Many of us are using the s.getQueryParam plugin matched with the s.campaign variable to track your paid search. You have your paid search click thru URL and your tracking code right on the end, something like and the query string parameter value gets dumped right in to your campaign measurement. This as we know is the preferred method of tracking paid search. You can pull up your campaigns report, add in your conversion events and there you go. You can see which campaigns converted and which ones didn’t. Unfortunately that gives you an all or nothing view of things. What if you wanted a little more? This sounds like a job for the s.clickThruQuality plugin.

What this plugin does is sets an event on each time a visitor clicks through to your site. Nothing exciting yet. But then when the visitor makes it one page past that landing page, it sets a second event. Now you can see which ad group, landing page or campaign engaged the visitor a little more than the rest. You will end up with a report that looks a little something like this:
Click Thru Quality Report
This example is pretty high level, but using individual tracking codes for your keywords this report can really give you a good look at your paid search campaigns.

First thing you need to do is to set one variable, I have it right after the s.usePlugins=true call.

/* CTQ variables */
var i=1;

Next you will need to use two events. A call to the plugin needs to be added right after your campaign tracking code:


In the call to the plugin you need to add in which tracking code you are looking to track, and the two events you want to use. Name one event Click Through and the other Click Past. Then add the actual plugin code into the plugins section of the s_code.js file:

 * Plugin: clickThruQuality 0.8
s.clickThruQuality=new Function("scp","tcth_ev","cp_ev","cff_ev","cf_th", ""
+"if(i<=1){var ev=(',':'');if(s.getQueryParam(scp)){"
+"tcth_ev;if(s.c_r('cf')){var tct=parseInt(s.c_r('cf'))+1;s.c_w('cf',tct"