Blog posts are like shoes: some are sexy and some are practical. This post falls on the far side of practical, not unlike orthopedic clogs.
Here’s the premise: Say you’re currently tracking your site with Webtrends and you’re considering a switch to Omniture. If you’re happy with the content hierarchy logic that you’ve built into your Webtrends implementation, how much of it will be portable to Omniture? Here are the most important factors to consider:
1) Webtrends Profile = Omniture Report Suite
The Webtrends profile and Omniture report suite both represent the top-level segments for a site. Assuming a given Webtrends profile genuinely maps to a visitor segment that requires full reporting it should be recreated as an Omniture report suite.
In some Webtrends implementations I’ve seen (especially log-based systems), administrators will create lots of profiles simply to obtain unique visitor counts for partial slices of populations. If this is the case it may be possible and appropriate to get the required metrics in Omniture without recreating every single profile as a report suite, since Omniture has more unique visitor reporting flexibility. Omniture also offers a free report suite roll-up feature; there’s no direct match for this in Webtrends.
2) Webtrends Directory Report ≈ Omniture Channel
The Webtrends Directory Report lists out visits by first-level directory based on URL structure. The Omniture s.channel variable serves a similar function, although it’s more likely to be based on business rules which may or may not match the literal file path. If the site has a clean URL structure this would be a simple and easy translation.
3) Webtrends Content Groups ≈ Omniture Hierarchy
In Webtrends most of the business-level content hierarchy reporting is managed using content groups. In my experience, ALL usable Webtrends implementations have at least a few content groups defined. The closest analogy in Omniture would be the s.hierN variables.
Keep in mind that Webtrends content groups go 2 levels deep (i.e. content groups and sub-groups) while Omniture hierarchy reporting goes 5 levels deep. Another important difference is that Webtrends has no strict limit on the number of content groups you can create, while a standard Omniture contract includes just 5 hierarchy variables (each with 5 levels). A migration would involve not only a mapping of content groups to hierarchy variables but a reassessment of whether the 2-level structure designed within Webtrends makes business sense now that you've got 5 levels at your disposal.
4) Other ConsiderationsIn general, Omniture implementations tend to be more complex – and more flexible – than Webtrends implementations. Anyone considering a migration should take their Webtrends setup, translate functionality where parallels exist, then look to the additional Omniture features available to them.
What do you think? Am I right? Am I wrong? Am I missing something? I welcome your feedback, especially if it’s practical.