New Implementation:
This is really targeted to those of you who (like me) remember the horror stories (or worse yet lived the nighmare) of a painful omniture implementation. Omniture now claims that they are leveraging the experience from deploying SiteCatalyst over 3000 times and have developed best practices which combine business, industry, and technical needs in a process they are calling their Fusion Methodology.
If you are wondering how much easier this is since the "good ol days," consider that Omniture is still suggesting that implementation will take between 4 and 6 weeks- working with a technical contact and includes weekly status calls. It's still not as easy as GA for sure. They have also moved from what they call "G" code to "H" code and offer migration guidelines.
Server Side versus Client Side scriptng also seems to be an important "new" option. It used to be that all the code was on the client side and that was the only option. That is based on hearsay on my part, but my research seems to back that up as well. I never personally implemented under this methodology. The "variables" can now also be contained in a library for reference by the javascript.
This is in no way designed to be an exhaustive list of all implementation methodologies, but suffice it to say that if you have been constantly ruling out Omniture because you don't have the technical resources or the time to implement this robust solution, you may want to look again.
Modifications:
Depending on how your particular instance of Omniture was implemented (and likely WHEN), you may find yourself lacking the flexibility you might "want" in the reporting suite. Traditionally, the problem I've run against is that a website is a dynamic entity which often doesn't resemble itself from one year to the next. Check out the archive.org project and you'll see what I mean. Also- all too often, you "don't know what you don't know" when you first implement any analytics application and that can be a real problem.
Omniture seems to have been adding functionality to help with these issues. Custom dashboards are easier that ever to build and their Excel tools are greatly improved from the past as well. The "Excel Client" has been replaced with the new "Report Builder" which opens up a whole new layer of flexibility. Originally, I was not a fan of "having" to use excel with an enterprise application like Site Catalyst, but it turns out that there is tremendous benefit.
For one thing, most business users are already trained on how to use excel. It's a native environment for them. Also- regardless of your level of experience with Site Catalyst, custom dimensions and metrics can be confusing and you're likely to run into limitations. Report Builder removes many of those limitations. It also provides a means of refreshing the data automatically and can even send reports on a schedule as well.
I recently ran into a situation where the only way I could determine to reasonably get the data I wanted was by using Report Builder. Unfortunately, I needed to request access to Report Builder from the admin of this client- which can sometimes be a problem. It's also kinda hidden- I couldn't find it even when I knew what I was looking for. There doesn't appear to be a way to just download the excel add-in except from the post log in menu and even then, it won't do you much good if you don't have the proper permissions to use it.
Perhaps the biggest benefit to Report Builder is that, based on my unscientific observations, I'd say it would likely dramatically reduce the need to re implement code or even new variables into the library. That removes a ton of hassle and, of course, the need to wait for new data to build- since you can't go back in time with new variables.
Remember- approach your analytics in the right order:
- Strategy
- Implementation (Access)
- Reporting
- Ad Hoc Analysis
Re implement only if you're sure it's necessary...
