Moving from HBX to SiteCatalyst – Part 1

Ok, we’re finally at the point where we are about to start thinking about moving from HBX to SiteCatalyst. I think I’ll keep an updated version of this going every week just as a catalogue of what is going on. Also as we move site by site we’ll be able to see all the things that we did wrong (yep there’ll be lots of them) and all the things that we did right and wanted to keep on doing (yep there’ll be lots of… what? Eh? Oh). I think I’ve said on here before that moving analytics solution is not an easy business.

Ok this is how you start:

1. Select your sites for the pilot
2. Set up your SiteCatalyst Accounts
3. Set up your cookie
4. Give Developers code for pages and requirements document
5. Test vigorously
6. Release running at the same time as HBX
7. Check that you are collecting everything you want to use
8. Give Developers new requirements document
9. Test vigorously
10. Compare to HBX

That almost looks like a ten step plan. It isn’t because some of these steps will run ad infinitum (specifically 7, 8 and 9). Tagging a site isn’t a one off thing with HBX or SiteCatalyst. You have to do a series of steps so that you can get your tagging right (make sure you are collecting everything you’ll need to use). Even then you will have to continue monitoring the tagging because the site will change and hence so will the names of pages (either deliberately or accidentally).

For us it was a relatively simple set of choices for our sites. Firstly we have a number of different platforms, so we needed one that spanned across them all. Our obvious choice was Farmers Weekly Interactive. Why? Because it has:

• A section on the main server for all our articles
• A section on the main server for all of the classifieds
• A section on Movable type for the blogs
• A section on Community Server for forums and photos
• A section on our custom built Job Service

This means that in theory if we can come up with a solution for this, we should be able to copy it across all of our sites.

Remember that theory’s are all too easily proved wrong. All of our sites are very customised and have large sections which we haven’t taken into account. We have a large image gallery that sits separately on one site and several large directories on others. Top tip here is make sure you don’t think that you could do this just on one site and then copy it across all others. Make sure you test all pages and make sure they have all got the right (and unique) tags on them.

We’ve also got a couple of other types of site sitting around that we are going to tag as well. Firstly we have a subscription site which we will probably use Gazetteers. Although this is yet to be decided. It will allow us to work out what we want to do with our users who log in and what sort of data we want to get out of them (if any).

Finally because they are a big search B2B engine, we are going to look to see what we can do with KellySearch. They also have a nice little section on their site under each advertiser allowing them to see the usage of those pages, so we are going to have to come up with a solution for that, although that may not be in the first take.

This sounds simple enough, but remember this:

Each of these sites has a set of priorities for things they want developed. If you run in a Agile or scrum methodology which seems popular these days, then this is something that you’ll need to get added into a sprint. That means bumping something else out and making someone unhappy. The trouble with web analytics implementations is that they do take developer resource away from real changes to pages and when you already have a web analytics system working, people often wonder why the changes are being made.

I’ve got around this one by claiming to the Business stakeholders that the move to SiteCatalyst is enforced. This is a slight white lie – we’re not being forced to move from HBX (yet), but this is something that is advantageous for us to do now rather than later.

The next two steps are critical. We’ve identified sites, we’ve looked at their development schedule and worked out when we can get this pushed in and now we are going to start the whole process. Steps two and three in the list above should not be underestimated. Creating the cookie and the CNAME change associated with it (more on that next week) will take time and needs to be scheduled in before the sprint for the developers start. More importantly we need an account to play around in so that we can see the changes. Getting your Omniture rep to set these up is key to getting this working on time.

I think the last point I want to make is that this is not just a simple process of moving tools. We have a system set up at the moment that looks at metrics from HBX and has a structure about it. I’ve done numerous training programmes on how to use HBX and how to use the data that comes out of HBX so colleagues can do their job. It was part of my reason for setting up this blog 8 months ago. The steps after this are going to be doing part of that process again – showing the staff where to find things, what it means, how to use it. And for those that only wanted to see unique users and page impressions it’s also going to be a case of setting up a series of dashboards and scheduled reports.

As one of my colleagues put it this morning “Jesus – you’ve got such an interesting few months ahead.”