Web Analytics Land » optimization

Optimize the Time Parting Plugin to get More Detail and Use Less Variables

VaBeachKevin — Mon, 21 Dec 2009 21:12:32 +0000

The Time Parting Plug-in is one of the more popular SiteCatalyst plug-ins available. A standard implementation of the Time Parting plug-in will consume 3 variables. One for Time of Day, one for the Day of Week, and one for Weekday/Weekend. How can we improve this to get more information, and more importantly use less variables? Here is how I have been doing it.

I use a combination of stacking the variables and SAINT uploads. For those of you who are not familiar with SAINT, Omniture describes it as, “…an acronym for SiteCatalyst Attribute Importing and Naming Tool. This tool enables you to download the classifications template, apply attributes to it, and then upload the data, thereby enhancing your SiteCatalyst reports with the new attributes.” This will allow us to upload a lot of detail about any variable you record.

Here’s how I’m doing it on this site. First I am using the 2.0 version of the plug-in and not the 1.4 version that I describe in a previous post. The 2.0 version includes support for Daylight Savings time and globalizes the year. You can find the 2.0 version from the SiteCatalyst Knowledge Base. If you prefer to use the 1.4 version, you can find it on this site.

/* Set Time Parting Variables */
s_hour=s.getTimeParting('h','-5');
s_day=s.getTimeParting('d','-5');
s_timepart=s_day+"|"+s_hour;
s.prop16=s_timepart.toLowerCase();
if (s.visEvent) s.eVar16=s.prop16;

Ok, let me explain whats going on here. As I said before the Time Parting plug-in captures 3 variables. If you notice in my code I am only using two of them. I don’t need to capture Weekday/Weekend anymore. I will take care of that later. The other two, I capture in two blank variables I created, s_day and s_hour. Next I combine the two of them in a single variable I call s_timepart, separated by a pipe. Then to ensure everything is consistent I copy the variable in all lower case to the prop that I am going to use. This next part is a little different. In the eVar I only want capture this value once per visit. Typically a simple getValOnce will be enough to get it done. Well then what happens when the visit extends from one time part into another? In that situation the Time Parting value will be different and therefore getValOnce will capture this as a new value since it has changed. I don’t want that to happen, I only want it once per visit. So this is when I tie in using the get Visit Start plug-in. This guarantees I will only capture the value only one time per visit.

This will return a report that looks like this:

We now have a total of 672 possible options in this report. The next thing we want to do is to classify these using SAINT. I set up 5 different categories to use. Weekday/Weekend (this is why we don’t need to capture it in the code, Day of Week, Hour of Day, Hour Part and AM/PM.

I then created the template to use that contains all of these values.

You can download a copy of the template that I use here.
Upload the template and that’s all there is to it. Do you have more conversions in the bottom of the hour or the top of the hour? How about morning vs afternoon? Which whole hour is the most profitable? Now you have an easy way to break down your time parting with finer granularity, at the sime time saving your self a couple of variables.

Enjoy!

Increase SiteCatalyst Clickmap Functionality with Dynamic Object IDs Plug-in

VaBeachKevin — Tue, 01 Dec 2009 17:58:16 +0000

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.

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.

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;
}
s.getObjectID=s_getObjectID

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

/* To setup Dynamic Object IDs */
s.setupDynamicObjectIDs();

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"
+">=5)){if(s.wd.attachEvent)s.wd.attachEvent('onload',s.setOIDs);else"
+" if(s.wd.addEventListener)s.wd.addEventListener('load',s.setOIDs,fa"
+"lse);else{s.doiol=s.wd.onload;s.wd.onload=s.setOIDs}}s.wd.s_semapho"
+"re=1}");
s.setOIDs=new Function("e",""
+"var s=s_c_il["+s._in+"],b=s.eh(s.wd,'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)"
+"{for(i=0;i=0||c.indexOf('.tl(')>=0||c.indexOf('s_gs(')>=0"
+")x='var x=\".tl(\";';x+='s_objectID=\"'+u+'_'+a[u]+'\";return this."
+"s_oc?this.s_oc(e):true';if(s.isns&&s.apv>=5)l.setAttribute(o,x);l[o"
+"]=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:

s.prop20=s.eVar20="D=oid";
s.prop22=s.eVar22="D=pid";

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.

Enjoy!

Optimizing The SiteCatalyst Page Code

VaBeachKevin — Thu, 19 Mar 2009 16:22:04 +0000

You’ve signed the agreement, you received your username, and you are ready to get started with Omniture SiteCatalyst. Or maybe you have had it a while, and are looking to optimize your installation. You’ve come to the right place. Let’s take a look at one of the two core pieces that make it work, the page code. The other piece, being the s_code.js file is a complicated animal, but the page code is pretty straight forward.

After logging in with admin privileges in SiteCatalyst, you can find the code files in the code manager in the admin console.

Here is the basic, vanilla, out of the box page code file.

There is tons of stuff here that is completely unneeded. Lets try to strip it down a bit and see if we can lighten our page weight. Why? The lighter our page weight the quicker it will load. The lighter the page weight the more of the actual content will get indexed. Believe me, lighter is better.

The first thing we see is a basic introduction:

This is absolutely not needed at all. Not a bit of it. But I do like to keep a small bit around just to keep developers who don’t know what it is aware of whats going on. For this first section I recommend chopping it down to:

Sweet and simple. No need to keep the version number in there either. Keep that in your s_code file where its needed.

Next thing we see is the call to the s_code.js file.

Yank this out too. But wait you say, I need that file, I can’t get rid of it! I’m not saying get rid of it, I just want you to move it. Keep all your JavaScript calls together where they belong, in the head section of your page. Move this call to the top of the page.
EDIT: There are some potential repercussions to moving this out of the BODY section. I like to keep the code nice and neat so I keep all the .js calls in one place but this is by no means without consequence. There is nothing wrong with keeping this line with all of the rest of the code.

Next up is the variable section.

This section is a disaster. You have a huge noscript section that is udderly useless. The very very very first thing I do is to kill that section. I mean Omniture themselves don’t even use it. Kill it and never look back. That leaves you with this:

/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//-->

The big scary “do not alter” message is somewhat important. Well the message itself, not that actual line of text. If I am going to have someone else install the code on their site I have them leave it, so hopefully they won’t touch anything they are not supposed to. If I am putting the code on the page myself then I yank that out too. The line that follows that is the money shot. That’s what makes it work. Don’t touch it. I usually never go near that line. I say usually because there is one time where I will touch it. More on that in a few. The final closing line, yank out the version and that one is good.

Lets take a look at the chopped down page code where we just set a single eVar and event.

Much better. Now I mentioned earlier that I would touch that one ‘money line’ of the code. If I have a site that I really don’t need much info on, and i can get everything I need from the s_code.js file I will hack everything down to the absolute bare minimum. You still need the call to the s_code.js file in the head section, that will never change, but the page code can be reduced to:

A call to the s_code.js file and that single line is the bare minimum that is needed to make SiteCatalyst work.

Look at your page code. Move the call to the s_code.js file to the header, move everything you can to that file, and strip out all the unnecessary junk.