Increase SiteCatalyst Clickmap Functionality with Dynamic Object IDs Plug-in

ClickMap. Pretty useful tool. It gives you a neat overlay that shows you what links are clicked on a page and the associated traffic. I wonder how we can make it better? Knock knock. Oh who is that at the door? Why its the Dynamic Object IDs Plugin. Please step right in.

The Dynamic Object IDs Plug-in dynamically adds an object ID to the click thru URL. You can see it using the debugger. It is designed to improve the function of the Clickmap.

Let’s take a look at an example. From the home page of this site, there are 3 links that take you to the Contact page. I click the last one on the page, then open the debugger on the page I land on. Here you can see that the click thru URL has been appended with the number of the order that it happened to appear in on the page. So now when I have multiple links on a single page each one is easily spotted in the debugger, even though they all have the same anchor text and click thru URL.
Dynamic Object ID Plug-in

Now what do we get? If you look at the clickmap report, Site Content>Links>ClickMap, you will now see a number attached to each URL.
Clickmap Report
Now you know exactly which link was clicked.

Here is how I have it implemented on this site. Before the function s_doPlugins(s) I include the code:

/* DynamicObjectIDs config */
function s_getObjectID(o) {
	var ID=o.href;
	return ID;

Then within the s_doPlugins(s) function, I include:

/* To setup Dynamic Object IDs */

And finally in the Plug-ins section I have the plug-in code itself.

 * DynamicObjectIDs
s.setupDynamicObjectIDs=new Function(""
+"var s=this;if(!s.doi){s.doi=1;if(s.apv>3&&(!s.isie||!s.ismac||s.apv"
+" if(s.wd.addEventListener)s.wd.addEventListener('load',s.setOIDs,fa"
s.setOIDs=new Function("e",""
+"var s=s_c_il["+s._in+"],,'onload'),o='onclick',x,l,u,c,i"
+",a=new Array;if(s.doiol){if(b)s[b]=s.wd[b];s.doiol(e)}if(s.d.links)"
+")x='var x=\".tl(\";';x+='s_objectID=\"'+u+'_'+a[u]+'\";return this."
+"]=new Function('e',x)}}}s.wd.s_semaphore=0;return true");

To see this code in the s_code file running this site, you can check it out here.

Ok great. Now what else can we do with this plug-in? Lets say I want to track how many contact form submissions I received from clicking the third Contact link that appears on the Home Page? Well I could add a custom onclick function. I could add a tracking code on the end of the click thru URL. But how can I use this new plug-in to track this?

Recently there was a post on the Omniture blog about using Dynamic Variables. Using these variables we can now grab the value of oid, which is the click thru URL with the new object id added to it, and you can get the pid which is the page the click happened on. I have it set up on this site:


Now with a simple subrelation I can get what link was clicked on what page and what events occurred, all without adding any additional code to the page.


Omniture Image Request Counter

A little while ago I wrote about how A Robust SiteCatalyst Implementation Could Fail In Internet Explorer. In the article I point out that IE does not like any URL’s that are over 2083 characters. Recently I have had some issues with a few sites where I think they may have been running into this problem again. I would always use Firebug or Tamper Data to look at the actual image request, copy that and drop it into one of the various free ‘character counting’ tools that are pretty abundant all over the web to make sure that the Omniture image request URL is not over 2083 characters. This can get pretty time consuming. I figured there has to be an easier way to do it. Behold the Omniture Image Request Counter.

Omniture Image Request Counter is just a simple JavaScript bookmark, very similar to the Omniture Debugger tool. What this does is takes a look at the image request and counts how many characters are there. Very quick, very simple.
Omniture Image Request Counter

Download a copy of the code here
View a copy of the code here

Here is how to use it:
1. Take any web page and create a bookmark (or favorite depending on what you call it).
2. Right-click the favorite you just created.
3. Click Properties.
4. Delete all text from the URL field of the Properties window.
5. Paste the following code into the URL field of the Properties window.


6. Click OK

Now navigate to any page that has Omniture SiteCatalyst code and click this new bookmark that you just created. You will get a pop up that tells you how many characters are in the Omniture image request. If you are using Internet Explorer and the image request is over 2083 characters then you need to review your web analytics code and make some changes to your SiteCatalyst implementation.

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.