As part of our research to find ways to improve the WebAbacus interface, we’ve been taking a look at some of our competitors’ latest offerings. Today, my colleague Sebastien took us through Omniture SiteCatalyst 12. Here’s a (fairly unstructured) summary of his findings. I’ll probably write this up as a proper document in due course.
General interface layout
The SiteCatalyst (SC) interface is quite nicely laid out, with the usual reports down the left side and other stuff across the top. Each report features a toolbar across the top (much the way WebAbacus does), which provides quick access to things like report download and A/B testing. Because of the amount of stuff in the SC interface, though, things are a little confusing on first glance – and there’s a lot of stuff crow-barred into the reports menu on the left which perhaps could have been treated differently.
Home Page
SC has quite a nice home page for when you first log in, with big chunky links to the main report areas, and best practice & support information from Omniture. WebAbacus just drops you into your default report.
Report Views
I don’t know whether it’s a universal function (I don’t think it is), but certain reports can be viewed a number of different ways – ‘ranked’ (a simple table of values ranked by some metric or metrics on the RHS), ‘improved’ (a rather odd term referring to period-on-period analysis, i.e. a comparison of one period with another) or ‘trended’ (the top n values from the report compared day by day over a period of time, such as a month). The WA approach to this is currently to offer the option to generate separate reports for each of these. Functionally there’s no difference (i.e. you can still get the data from WA), but the SC approach is much more accessible.
Data Drill
Not sure if this is the official Omniture term for this, but you can click on any entry in a report and see summary data for that entry. For example, you can click on a search term and see summary info about the visits that were generated by that search term. WebAbacus has this functionality in its filtering, with the difference that, in WA, the filter is persistent, whereas it isn’t with SC. As it turns out, this tends to cause more problems than it solves for users of WA.
There’s also a little context menu alongside each entry in an Omniture report which allows you to segment what you’re seeing by other metrics. This is something we’re planning to do with WebAbacus. At the moment with WA, the segmentation process is a bit back-to-front; if you want to break product interest down by country, say, you first have to go to a country report and filter on the country you’re interested in, then go back to the product interest report. Users find this rather counter-intuitive. It’s better to do it the way most of our competitors (including SC) do, which is to allow the segmentation to be selected within the report, and the results to affect that report, and that report only (as opposed to the persistent filtering model we have now).
The SC functionality does this, but misses a trick which we can employ with WebAbacus. With SC if you segment, by something (e.g. country) you get the entry you asked for as the top-level of a new ‘category’ (in WA parlance) report, with the segmentation data underneath as sub-category information. What we should be able to achieve with WA is the ability to dynamically build a full Category report in the interface with users defining the first, second, third and subsequent category fields there and then. It’s likely that in introducing this we would drop the idea of filtering altogether (or at least background it to a significant extent).
Creating metrics
SC supports the process of creating a ‘metric’ (a definition of a single measure of something, such as conversion rate) as an independent entity that can be used in other places, such as reports and dashboards. We will do this in WebAbacus – it’s a strong and useful idea. I’m confident, though, that we can bring WebAbacus’s traditional strengths of flexibility to bear in this situation, and support the creation of any kind of metric using the underlying data (Omniture just allows you to total things and then perform arithmetic operations, which is somewhat limiting).
Report builder
SC has quite a nice report builder with a wizard-like quality to it (or at least a progressive display) . But in truth the report builder isn’t terribly powerful – it really just allows the user to build a specific ‘view’ (in our terminology) of an existing report. Indeed, inside the report builder you’re asked to select the report you want to use, which seems like a counterintuitive recycling of terminology to me. There are some nice features, such as being able to send the report you’ve built via e-mail (without having to save it permanently) or adding the report (as a ‘reportlet’) to a dashboard.
At the moment, building and customising reports in WebAbacus, whilst powerful and flexible, is much harder than it should be. In WebAbacus 6 we’ll be separating the presentation logic from reports and making them available as ‘views’ which users can create (and save) and use to view the data from a specific report. But we’ll also be exposing the configuration of the reports (which will themselves be simplified – more on this at another time) so that users can create and employ new metrics at the report level.
Path analysis
SC has strong path analysis, in the form of three key reports: A pathways report, a ‘fallout’ (funnel) report, and an in-and-out report (I should be able to provide the names of these reports, but I don’t have them to hand unfortunately). Together these do provide a powerful suite of reporting about the paths users have taken, and there are some very nice configuration options to allow users to focus on the paths that are of interest. We felt that there was a bit of a missed opportunity in not making the path definitions more reusable, but Omniture may feel that its users will only create one or two paths, so surfancing another entity (a ‘path’ entity, effectively) would probably only serve to confuse. But this is likely to feature in the approach we take with WebAbacus 6, although the issue of complexity is one we’ll be paying a lot of attention to.
Nice descriptive buttons
This seems really trivial, but is an important aspect of a well-designed user interface. In SC, many of the ‘Go’ buttons are marked with things like ‘Save this new report’ – which just provides that bit extra information about what will happen when you click the button. Something we can learn from.
That’s it for the moment. Of course there’s much more to both tools than this brief comparison of their interfaces implies. But we have a pretty good feeling that WebAbacus has good functional parity ‘under the hood’ – i.e. in its primary data processing capability – and is an extremely flexible tool. But we know the interface could use some improvement. In future posts I’ll provide a comparison of WebAbacus and other well-known tools; HBX is the one most likely to feature next.