SiteCatalyst compared to HBX
Ok, I’m not going to go into too much detail here, but I’ve been playing around with SiteCatalyst today to see what it is like. Given that we use HBX at the moment we are probably in a similar boat to many other people in that we are looking around and thinking about our options. In fact I have blogged in the past on the options that HBX clients are facing. This is the progress report that I have sent up top from basically just one days use with some dummy data:
- Reports easier to create in the user interface – can select your own columns (as well as having standard forms)
- Can create calculated metrics (eg bounce rate) and put them in any report
- Reports can be added to dashboards in a much easier way and can be viewed in a more efficient way to HBX
- Not as big issue on the table lengths (they start at 1million whereas HBX started at 1,000 or 10,000)
- Dashboards/reports can be automatically emailed in pdf, excel, word etc and can be set up to be emailed on a regular basis (or via ftp)
- Funnels can be set up on the fly for any amount of data (looking at historic data and new data)
- Content hierarchy has been replaced with custom events (effectively – although there is a hierarchy option) – not necessarily a negative but may take a while for RBI staff to get head around
- Some reports not that intuitive – many will need to be built into dashboards in advance
- Segmentation options not readily available until Discover 2 (not even like the active segments we have in HBX) – they all have to be coded onto the page in advance
- There may not be an ability to measure the number of pages viewed if a user comes from a particular source (eg a search engine, email campaign, )
- Much of the nomenclature is different to HBX
Questions to ask
- How SiteCatalyst works with first party cookies across many domains?
- How SiteCatalyst works with campaigns where we have a url rewriting system?
- How we can run reports for multiple sites using the excel client?
- I haven’t seen anything on the administration of the tool (setting up users, etc).
As I have mentioned before one of the areas that always gives me the greatest concern is that we have a large volume of users of the tool and very few analysts. What we’ll need to do is to find a solution that fits both of us. One of those solutions might be to hire a few more analysts – which will give us more scope to help do analysis as well as training.
Anyway – back to the original point – what are the main differences for the users:
HBX ran most things in standard ways using the content hierarchy and the page name. You could then use either report builder to help you with common elements within names, the active segmentation module or the available custom metrics if there was something not already captured.
SiteCatalyst has a very simple naming structure and likes to put things in ‘channels’. The hierarchy then is set not in the page level, but in custom ‘props’. The ability of SiteCatalyst to do much more detailed segmentation and report building in the user interface means that you may not need the active segments. However this is very dependent on implementing correctly in the first place.
However I have always said that one of the hardest things about web analytics is setting it up properly in the first place. Hopefully though with the HBX experience already existing, you will be able to take some of that information and put it into SiteCatalyst.
How? Well you get paid a fortune to be told that – but let me start here. You can put each of your content levels into these props and then drill down to the pages that way. You can easily assign entries to these reports because you can build the reports on the fly and this will show you areas of the site that are driving the most traffic.
Concerns? A couple – as you can see from the questions. I’m also not quite so sure about how scalable it is across a company with 65 websites that does lots of central reporting.
What I like most? I like the idea of Genesis and being able to plug in the email suite (if not the ad suite yet). One reporting mechanism saves a whole load of heartache.
Interesting times ahead, as I’m sure you’ll appreciate.