Omniture Site Catalyst variable declaration and naming convention

[admin]

So what's the big deal?
I continually get to look inside the Site Catalyst implementations of various companies as they struggle to extract value from the product. Those implementations are usually done in such a way that future upgrades are extremely painful and time consuming, if not virtually impossible. Javascript page tagging is messy, but you can make it much cleaner by following the tips below.
Standard Practice and why you can do much better
Most web sites have a block of Omniture variables declared in the page code. For example, somewhere in the body, you may see something like:
s.pageName="site:some page";
s.prop12="calculator";
s.eVar14="widgets";
s.events="event2";
Lets say that prop12 is looking at tool usage and eVar14 is looking at product category affinity. The above will work fine, the variables will be populated in the scode and sent with the request as expected. But what happens when a developer comes back in 2 years time and wants to switch the usage of eVar14 or prop12? The variables are hard-coded everywhere, they appear in lots of templates, a few microsites, and are straight hard-coded on some custom pages, it's a complete nightmare.
The Solution
Call the variables something meaningful to you instead, don't use the Omniture naming convention in your HTML, this makes future changes very messy. Once you have your own variable names you can then transfer the information to the relevant site catalyst variables in the scode file.
Useful naming convention has several benefits:
1. It makes sense to the developer and hence they are less likely to screw it up
2. If you later want to make a change, that's fine, you simply make one change in the scode file and all the old usage will cease immediately as the new usage takes it's place. Switching a variable for your whole site/s can be done in minutes.
Example:
On page:
s.pageName="site:some page";
scToolUsage="calculator";
scCatAffinity="widgets";
In the scode, inside the s_doPlugins(s) function:
s.prop12=scToolUsage;
s.eVar14=scCatAffinity;
In the scode, outside the s_doPlugins(s) function (this makes sure the variables are declared in case they are not declared on the page):
scToolUsage="";
scCatAffinity="";
What about events?
Many events are page related (i.e. a registration event is triggered on the registration confirmation page). So why declare it on page in the variable section? You may want to change it later. Again this is something that can be easily dealt with in your scode file. If you use good s.pageName notation, you can trigger events specifically when certain pages are loaded. Below is an example using the s.apl plugin to append event2 to the s.events variable whenever the pageName contains "registration-thank-you". If you later decide to change the usage of event2 you can once again make a single change in the scode file and you're done, you don't have to worry about searching for code across your site/s.
Example code inside the s_doPlugins(s) function:
var scRegistration=new RegExp("registration-thank-you");
*** if (scRegistration.test(s.pageName)) {
*** *** s.events=s.apl(s.events,'event2',',',1);
*** };In short, centralise all the code maintenance you can in your scode file, this makes your developers jobs easier and also provides the freedom and flexibility to make changes quickly moving forward. Secondly, the pageName variable should be your one constant on-page declaration, use it wisely and it can be very powerful. For more tips on s.pageName convention best practice, see http://blog.datalicious.com/top-five...iture-site-cat For more information on Site Catalyst deployments, drop me a line at hogilvy@datalicious.com

Permalink | Leave a comment »



More from the Datalicious Blog...