Ok, I’ve been slack lately on writing about web analytics on the Diary. It takes me just a little longer to formulate thoughts, etc as opposed to writing about the trials and tribulations of grad school. That being said, I do have some ideas in queue. The first of which is along the lines of helpful advice to those out there in blogistan that are interested in implementing Omniture (or really any web analytics solution). I am still in the midst of deploying it fully across Lenovo, but I can already throw out a couple of points to think about before sitting down to deploy a solution. So here we go with “Lessons Learned with implementing Omniture Vol.1”
1) Think through how you want to categorize the data. This really gets into the report suites concept used in Omniture where you have the traffic, etc of a site or sites roll into one datamart to do analysis on. For a small company this probably wouldn’t be a big deal as you’d just dump all in one place, and use variables to create subsections.
With Lenovo, we have thousands of sites to worry about, so lumping it all in one report suite probably isn’t the best scenario. Try to think of logical ways the traffic should be viewed. I’ve opted with siloing the data by countries for our Public Sites. This would work really well, if it weren’t for the fact that a lot of our countries share pages, such as eSupport. So in my case the way it is architected now, if a visitor is on www.lenovo.com/us/en and clicks ‘Support & Downloads’, they will essentially be treated as an ‘exit’ off the US Public Site, because eSupport is being tracked in a different report suite than the US Public site. There are ways around that problem but involves some work, which I am digging into at the moment. But be cognizant of how exits and entries will look in your reporting, by how you section off your traffic in report suites, as it can have dramatic effects.
2) One of my biggest pain points has been the fact that I have had to come up with ways to track our commerce engine. In this case, Omniture won’t touch your code. So its up to you. In our case, my team (essentially Esteban and myself) have come up with the complex scripting to pull the necessary values and attributes out of the html to populate the commerce variables in Omniture. That is a process made much more difficult since we couldn’t code pages individually, but had to use a global script to do a ton of if-then statements to figure out what type of page it is to execute the rest of the scripts for commerce variables. Not fun work. And I took down our commerce engine multiple times in doing so. So it was not a bloodless exercise, and I still don’t have full functionality…yet.
I am alerting you to my pain, not to scare you, but just to illustrate there might be some effort needed to make it work for you. Once you have the commerce tracking in place, Omniture is extremely powerful in its ability to corelate to marketing tactics, etc.
3) Sit down and plan out ‘Success’ events. Essentially, why do you have a web site, and what are you trying to accomplish? The reason is to pinpoint what events you need to be code as events within Omniture. Things like purchases and shopping cart opens are prebuilt. But what about registrations or lead generation pieces of the site? Those need custom events set up within the implementation. And the catch is you basically have 16 custom events you can use, so it takes some upfront thought to make sure you have the right events set up before running out of the allocated spots. You can expand the functionality of the events by using them in conjunction with eVars (the clever title for Commerce variables). But again a lot of thought should go into what those success events should be. I would be lying if I said I took the right amount of time thinking that aspect through, and its caused me a couple of headaches along the way.
4) Understand limitations of the tool by reading the documentation. The implementation guide is over 200 pages long. Did I read it all? Nope. Should I have? Absolutely. I would have found out things like how ClickMap has a 100 character limit of capturing links. Therefore if your urls are longer than 100 characters, and the first 100 aren’t unique it can give you screwy data when looking at site navigation through ClickMap. For those that don’t know ClickMap is the visualization plug-in that shows where people are clicking on a page.
6) Take your time implementing. Rushing it will cause errors and you’ll need to do big changes to correct them in some cases. No one in your company will believe how complex some of the thinking that is needed to architect it correctly, so take the time in making sure you know how you want to go about doing this. It is not a trivial exercise for a large company.
All that being said, my experience with Omniture has been pretty positive as it is lightyears beyond anything we’ve had in the past. Again, I just wanted to highlight some of my pitfalls and some advice. I have a couple of more Volumes of Lessons Learned in queue, so look for that.
In the next few months, I plan on taking it to some new extremes and integrating it with some of the offline business as well to make it truly a one stop shop for our metrics. Slowly we are moving to my dream of making our business decisions based on fact as opposed to intuition and guesswork. This is the first step in a marathon to change a corporate culture.