In one of the first blogs that I ever wrote, I remember quoting a favorite adage of my founding partner, Joel Hadary, that “a fool and a tool is still a fool.” The saying came forcibly to my mind as I considered the topic for this blog: using automated tools to port your HBX tag to Omniture SiteCatalyst.
Why? Because automated tag conversion is one of those seemingly attractive ideas that ultimately hides problems and damages your business. In this post, I’m first going to show how trivial is the task of tag conversion. Then I’m going to discuss why automated conversion tends to hide the real challenges in converting to Omniture. Finally, I’m going to discuss why some measurement/IT organizations might use such a tool and what their business clients ought to think about it.
Porting Your HBX Tag to Omniture
There are really five main sections to an HBX tag: the main section that includes account and page name, the action settings section, the segments and funnels section, the campaigns section, and the custom variables section.
None of these is the least difficult to convert to Omniture unless you have custom code. And if you have custom code, no automated conversion tool will work anyway.
In the main section of HBX code, you typically need to translate your account variable and your page name variables into Omniture equivalents. Setting accounts in Omniture is pretty much identical to HBX. Page Name strategies may differ slightly. In Omniture, the pagename variable is set using the s.pageName variable instead of the hbx.pn variable. There is no concatenation of hierarchy. Many Omniture sites choose to add the hierarchy into the page name string. If you have a breadcrumb (a friendly text string that tracks the location of the page in the site hierarchy) you can often use this.
Unlike HBX where many sites rely on the pndef and ctdef options, in Omniture you’ll populate the page name directly. It is generally trivial to replicate any HBX option in simple JavaScript using the document or location objects.
There are some separate Omniture variable for the content category (s.channel and s.hier) and while it is less important than in HBX each (particularly channel) is worth setting. You would typically set s.hier to a string essentially identical to your HBX mlc variable. Channel strategies vary (in ways that cannot be handled by automation), but many organizations set channel to the first level of their hierarchy.
Now for the action settings section. Most sites do nothing with the HBX action settings except set link handling to “auto.” By default, Omniture simply uses the most common HBX setting (auto). If you are using the HBX link “name=&lid=customLinkName” construct in your links, you’ll have to adjust this for Omniture. Instead, you’ll add an onClickHandler to set the OID – it looks like this:
onClick="s.tl(this,'o', ‘Main Page - Sign In');
In this handler, s.tl is the Omniture custom link call. The only parameter you’ll change is the last one – which assigns the link name. Note that an automated tag conversion tool probably won’t do this for you anyway.
A few HBX sites will set the download filter.
hbx.dlf="n";//DOWNLOAD FILTER
You can provide Omniture with a list of types using the linkDownloadFileTypes variable.
Here is a sample:
s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,wmv,doc,pdf,xls,xml";
This will provide identical functionality to the hbx.dlf list.
Next up is the Segments and Funnels section. There are no tagged funnels in Omniture and it’s a rare site that uses them in HBX. Similarly, Omniture has no Population Segments. However, you’ll probably want to set Omniture eVars with a text equivalent to whatever population segments you’ve defined. So if you have a population segment in the first slot (#1) that is customers, you’d change this:
hbx.seg=”1”;
to
s.eVar1=”Customers”;
What about the campaigns section? Omniture has no equivalent to tagless campaigns so there is no automated strategy for porting tagless constructs. Tagged campaigns in Omniture function almost identically to HBX. Omniture provides a little plug-in (a javascript snippet) that will automatically look for “cid” as the campaign string. If you want to use something else, you type over the “cid” string in the plug-in. This replaces the entire range of HBX campaign parameters including “cmp,” “dcmp.” “dcmpn,” etc. Response attributes are not handled via the tag in Omniture, they are handled using SAINT (upload of campaign hierarchy and attributes based on the key). This may cause you to rethink your campaign assignment system but it won’t change your tag.
The last section in a typical HBX tag is the custom variable section. This includes the hbx.ci variable (customer id) and the HBX custom metrics (hbx.hcX). These all should be set as Omniture variables. In general, you’ll want to set them as both “prop” and “evar” variables. So if you have line like this:
hbx.hc1=”Logged In”;
it will change to something like this:
s.prop2=”Logged In”;
s.eVar2=”Logged In”;
Wow. That’s it. You’ve pretty much just ported your HBX tag. Total Time: perhaps 1-2 hours depending on how careful you are.
So why would you ever want to buy a tool for automating a one-time task that will take you less than 2 hours?
We’ll talk about that in a bit.
Why Automation Hides - not Solves - the Real Problem
But here’s the real problem with automation – no matter how perfect the automation is, at the end you don’t have a good Omniture tag. A direct translation of your HBX tag to Omniture will work, but it will leave off all of the things that actually make switching to Omniture worthwhile.
Most HBX implementations use few if any custom metrics. They use a single custom event (for internal search). Good Omniture implementations are completely different. Omniture provides 100 custom variables (50 each of propVars and eVars – which accomplish rather different functions) as well as 20-30 custom events (which have no direct corollary in HBX). If you don’t code these, you’ll be getting an impoverished implementation. But there’s no way to code them in an automated fashion from an HBX tag because HBX didn’t have those capabilities.
Let’s face it, the real work in an Omniture implementation isn’t the trivial coding that typically goes into a javascript tag. It’s figuring out what should go into that coding. And it’s making sure that with Omniture’s somewhat different bag of tools that you can support the reporting and analysis you are used to. Using an automated tool may save you an hour or two, but it’s much more likely to blind you to the actual work you should be doing. It’s tempting to think that you’ve run the program, so you’re done.
That’s why I described tag automation as something worse than useless – it’s a technique likely to damage your measurement program not support it.
So Why Would an Organization Buy and Use a Tag Conversion Tool?
Central measurement organizations supporting lots of sites they don’t think are very important are the obvious buyers for such a tool. By automating the tag conversion, they minimize interface with the business and technical owners of sites and they ensure a simple, very inexpensive implementation. Centralized measurement groups tend to fall into one of two camps: those who take measurement very seriously indeed and want everyone else to do so as well versus those who want to minimize their support hassles.
If your support organization fits into the latter category and they don’t believe your site is worth measuring seriously, you’re a likely candidate for tag automation.
Which raises the question – could they be right? Are there sites that aren’t worth measuring seriously? I suppose there are, but I’d have to ask why – if that’s the case –it makes sense to bother with an Omniture implementation at all. A free tool like GA provides functionality very similar to what you’ll achieve with a base Omniture tag of the type you’ll get from an automated port. GA is easier to support and has a simpler interface. And, of course, it’s free.
So if your IT or central measurement organization is using an automated tool to port your tag, you should probably be asking yourself these two questions. First, do I want serious measurement? If the answer is yes, you should be thinking about customizing your tag. If the answer is no, you should be asking yourself the second question. Do I really want to pay anything for a bad Omniture implementation?
Comments