Making the Switch – Transitioning Your Excel Reporting From HBX to Omniture

Part I: Implementation and Interface

So you’ve looked (hopefully), leaped (bravely) and landed on your feet (hopefully).  You’re now a proud Omniture client, with data coming out of your ears, new platforms to play on and an endless ocean of analytic possibilities.  But before you even begin contemplating your first Omniture based deep dives a series of email pour in, all with the same gist – where’s my daily/weekly/monthly Excel report?  These come in from people who didn’t know about the Omniture acquisition of HBX, that your company has transitioned from tools or exactly how to define a single access visit, the just want their freakin numbers. 

If you haven’t considered how to rebuild existing reporting until the “where’s my report?” emails roll in, you’re already too late.  You have already failed those dependent on you for reporting.  After “looked” and before “leaped” is when you should begin laying the framework for rebuilding existing reporting in Omniture’s Excel Client.  Here is a list (in time relevant order) of steps and considerations for transitioning your HBX reports, especially those of the automated variety, to Omniture.

1.    Its important to realize that many of the HBX interface tools that you can utilize to get reporting data (campaigns, active segments) won’t exist in their same form.  In general, Omniture reports require more forethought and planning because they are more dependent on tagging and less dependent on an interface customization.  Without active segments or campaigns (the HBX kind) to lean on, you’re going to have to start thinking about how they can be replaced with a combination of custom metrics and correlations/subrelations.  It will require a major in shift in thinking going from having a hand full of custom metrics to a boat load of them. And it’s your job to interweave important reporting metrics in the implementation of custom metrics. Often custom metrics for reporting would have been tagged as props or evars anyway, but not always.  Metrics tagged as props are slightly (or vastly, depending on your implementation) different from evars, so be careful when deciding if your metric will be a prop or an evar.  If you have the slots to spare considering doing custom metrics as both, so you get the best of both words.

2.    The other main tool you must consider (A.D. active segments) is correlations and subrelations. Although, these are enabled by calling Omniture, you need to consider them before tagging.  Prop correlations must be set on the same page or a correlation simply isn’t possible.  Subrelations, however, are more flexible since they do not need to be set on the same page and will most likely be integral to your future reporting.  Obviously subrelations/correlations cannot exist in vacuum so as your stretching your mind thinking about your new found wealth of custom variables you have to stretch it further to consider how you want them correlated/subleased and with what.  Personally I’ve always liked puzzles, I hope you do too.

3.    Anyone who spends a lot of time with Omniture will find the words “turned on” and “enabled” seep into his or her frequent vocabulary.  Once your implementation is in place you should make sure to enable visits and visitors for metrics where they are necessary for reporting or might be necessary in the future.  Doing this in advance of needing them will save you a ton of grief.

4.    Once your implementation is in place, correlations/subrelations are connected and visits/visitors have been turned on, spend some time with SAINT.  With Report Builder you might have been using Excel equations, like vlookups, to sum groups of pages or translate page names, but with SAINT this no longer has to be the case.  If your page groupings or lookup tables change more often than each month it's probably easier to continue using Excel equations, but if they are more static take advantage of SAINT.

5.    Even though you lack active segments in SiteCatalyst, Omniture throws you a bone of five ASIs.  You may or may not choose to use these for reporting.  If you do be aware that the bigger the segments population or the more complex the segment the more lag you’ll get on the ASI data.  In general, it’s a bad idea to rely on any ASI for time sensitive reporting in any form.  However, ASI are a powerful tool to help recreate HBX reports in Omniture and if you plan on using them in delayed reporting they should be built as early as possible.

Stay tuned for Part II where differences between HBX Report Builder and Omniture’s Excel Client will be discussed along with the changes you will need to make in your Excel report building technique.  Additionally in II I’ll discuss what the best practices are when you cannot fully automate a report with the Omniture tools available.