More Thoughts on the Acquisition of Visual Sciences by Omniture
Today should be my last lunch of leftover turkey. I can’t wait to go back to burgers and burritos! I’m just not a leftover guy.
But I do have a topic left over from before Thanksgiving. I promised more thoughts on the Omniture acquisition of VS and the implications for existing HBX customers. I also want to set the table for Ask Semphonic – our upcoming webinar – both for listeners and my fellow Semphonic panelists.
Almost lost in the shuffle before Thanksgiving was the exit of Tim Kopp from WebTrends. Tim follows the rest of the Management Team out the door – further testimony to the speed of change in our market. It’s a development that casts a huge cloud over their future. When you are evaluating enterprise software, the replacement of a company’s entire management team is a nearly insurmountable black mark. It’s all too easy to look at the VS experience – where there was a plausible alternative management team in-place – and see how precipitously the market can shift in the wake of such changes. Enterprise software decisions are about a lot more than technology – and it would take something more than guts to choose WebTrends as your enterprise solution until you see firm evidence that there is a Management Team, that you know what it stands for, and that you believe in the company and the direction. Having a good piece of software is just one of many requirements to be a good enterprise alternative.
I don’t know how big an impact that has on decision-making around transitioning out of HBX. Most of our customers are clearly leaning toward the Omniture path anyway. Their concerns are primarily about the economics of transition and the technology effort involved – not too many seem inclined to go down the vendor evaluation path.
I think Omniture will make the economics of transition very reasonable. And I believe they will do all they can to make the technology effort as small as possible. But I think HBX customers need to temper their expectations around the technology effort – and should expect and plan for a considerable implementation effort regardless of what technology Omniture provides.
Why?
Based on our experience with many Omniture and HBX implementations, there are fundamental differences between good implementations in each that no automation can solve.
In the last two (good) weeks before Thanksgiving, we added three new Omniture clients (four really - but I don't have the data for the the fourth). One is a startup in beta. One is a mid-sized, established online retail business. One is a very large media company.
It is striking to look at the broad shape of these fairly typical implementations and compare them to what we usually see in the HBX world.
The startup has 26 prop vars (custom metrics in the HBX world), 30 evars (equivalent to the new eCommerce custom metrics in HBX) and 25 custom events (no real HBX equivalent except Search) defined. They have 1 ASI defined (equivalent to Active Segments in HBX).
The mid-size company has 50 prop vars and 50 evars defined. They have 16 custom events. They use no ASIs.
The big media company has 47 prop vars, 40 evars, and 27 custom events defined. They have 3 Active Segments defined.
We don’t have any new HBX implementations in the last two weeks - surprise. But I can pull similar sites from our client list. For HBX, a similar startup would probably have 1 Custom Metric, 7-8 Active Segments and possibly 1 Custom Event (Search). The mid-size company would have probably have had 2-3 Custom Metrics, 20 Active Segments and 1 Custom Event (Search). The big media site would usually have 4 Custom Metrics, 1 Custom Event (Search) and 40-100 Active Segments.
The Omniture implementations are fundamentally different in structure than typical HBX implementations. They have far more custom metrics, eCommerce variables and custom events. They use far fewer Active Segments.
Beyond the simple fact of being different, however, what’s important to understand is that you can’t manufacture decisions about Omniture custom variables and events from thin air. They are business driven. Nor do they map in any potentially automatable fashion to Active Segments. And while it’s true that any Custom Metric in HBX would almost certainly become a propVar and/or eVar in Omniture, that would still leave an impoverished Omniture implementation; an implementation that is far below the common standard when done from scratch.
The bulk of the work in any Omniture implementation is figuring out and coding your custom variables, eCommerce variables and Custom Events. This limits Omniture’s ability to transition a client from HBX to SiteCatalyst without essentially redoing the implementation.
Suppose, for example, Omniture rolled existing HBX data into SiteCatalyst and revamped their gateway so that HBX image requests were mapped into SiteCatalyst requests. A solution like this would instantly roll every site currently using HBX to SiteCatalyst and would require absolutely no work or retagging. Your only change would be to open SiteCatalyst instead of HBX.
Sounds great. And, in one respect, it is a great solution – one that looks seamless and appears to meet any conceivable objection. Except that it will leave you with an Omniture implementation that doesn’t take advantage of any of the best features of the product you are now using.
Bottom line – you should expect to put some real effort into re-designing and re-thinking your tag when you transition to SiteCatalyst. And you should plan for this regardless of whatever technology solution Omniture provides. Indeed, the technology Omniture provides for the transition will be almost entirely irrelevant to the effort – since the bulk of the effort is unrelated to mapping simple variables like page name from HBX to SiteCatalyst.
So I’m betting that contrary to conventional wisdom, waiting for Omniture transition tools is pointless, because the best you can reasonably hope for is a minor automation saving. The time-consuming parts of the transition are things that simply cannot be automated. That’s why I’d recommend that most companies seriously involved in web measurement think about transition sooner rather than later. The longer you delay, the further behind you’ll be when you finally make the switch.
Coming from a company that has ALWAYS been loath to ask anyone to switch tools, this may seem paradoxical. But in this particular case, the future is clear and the question is when not if. The longer you stay anchored in the world of HBX, the longer you’re going to be eating leftover Turkey.
Interesting post - however when I spoke to my MD about this recently his response was "There was a reason we didn't choose Site Catalyst in the first place, which was because it was more expensive." Although he was right, the other reason was that 400 users of HBX that we have meant that you only needed two analysts (although 400 people who think they are analysts).
With Site Catalyst, you may (although I don't know) need more analysts to set it up for the 400 users who have enough trouble understanding something simple like HBX in the first place.
I don't think it is as simple as just signing up for Site Catalyst - holding on to HBX for as long as possible is good for the 400 people who don't know that it is going to be discontinued in 24 months and don't use half the features anyway.
Not to mention the two analysts who have just painstakingly gone through training 400 people what they need to look at and where to find it, only to discover they have to implement a new solution and train those people all over again with a new tool with different terminology.
Having said that, if they run out of support or stop product development, a new tool implementation is going to have to happen sooner rather than later. As with a good joke - I think this one is all about timing.
Posted by: Alec Cochrane | November 26, 2007 at 01:20 PM