Building on what we learned during day one and day two of the Omniture advanced implementation class, day three covered new material and finished with an exercise implementing the basics on a sample site. At this point, we felt we knew how to ask the right business questions to be answered by web analytics and that we had the know-how to implement the right solutions.

It’s worth staying for the entire session until 5 PM. Toward the end of the day a senior implementation consultant came in to answer questions that came up during the three days that the instructor couldn’t answer. Some participants left early to catch flights, but I’m glad I stayed until the end even though that meant taking the red eye home.

Here are my takeaways from the final day of class for those of you already familiar with Omniture.

• If you are rolling up multiple report suites to a higher, global report suite, each suite must use the same time zones for the data to work properly. For example, if you have sites in Los Angeles, Chicago and New York–each with its own report suite–and you want to roll up the data to an overall report suite (total organizational performance), you must select the same time zone for all the reports; if that’s Eastern Time because your most important stakeholders are located there then your LA report is going to be in Eastern Time.
• The SAINT application uses the same database as the campaign manager, although the two appear to be separate.
• How do you use clickmaps overlays on older pages where the design has significantly changed? Save a local version of the web page to your hard drive as an archive. You can then turn on the overlay to see what happened during that time period. Better yet, use your content management system to archive the changes or keep back copies on your server. For instance, imagine that your home page one month has a three-column layout, but that you later change it to a two-column layout. Your clickmap overlay will no longer “see” some of the links that are no longer there in the new design. By going back in time to your archived copy–and changing the reporting period accordingly–you can once again see which area’s of that page were getting the most clicks. Make sure your JS file uses an absolute, not relative, link for this to work.
• Use S_Object ID to track rotating ads that use separate URLs through clickmaps. For example, if your home page always has an ad in the corner, but it points to a different message and URL throughout the day, this variable will let you count how many clicks you’re getting in the corner. Now when it’s time to track internal campaigns, you’ll use a separate evar to determine which of those ads were the most effective. This one-two combination lets you track position (are visitors clicking in the corner?) and individual ads (which ones work?).
• Import your old log files or previous analytics package data into a separate report suite. You can’t mix and match with your new Omniture data, but the reports will be familiar when you want to look at historical data. So, if you moved from the WebTrends logfile analyzer to Omniture at the start of the year, then your December and earlier data from WebTrends could be imported to a separate report suite. Your day-to-day reporting would take place in your main report suite, but you’d still have access to your older data.
• If you have multiple domains or add your tracking code to third-party sites that do some of your hosting (such as for a promotional campaign, fundraiser or contest), make sure to specify these domains as internal within the Admin tab under Edit/General/Internal. If not, supposedly you’ll have some page names show up as “other” in the reports–in which case you’ll have to call Omniture to find out what those pages are. However, I had a case where I hadn’t identified a third party as an internal domain, yet the data came through fine; the senior implementation consultant who came to the class couldn’t explain this. Nevertheless, I’ll set the internal domains going forward.
• The Omniture debugger does not work on custom link tracking; use Ethereal, an open source packet sniffer, instead.

This class also included a hard sell for Discover 2, an expensive (even by Omniture standards) option that gives you real time access to the full, non-normalized database of your analytics data. It’s like Omniture’s Data Warehouse product without the multi-day wait for data. For performance reasons your data is normally chunked up and only the relationships and correlations you requested/configured ahead of time are available. If you think of some relationships you want to explore down the road, those have to be set up in SiteCatalyst and are available only going forward. Discover 2, however, gives you every combination right away.

Next: Optional day 4: certification

With the foundation set during day one of the Omniture implementation class, we turned to more hands on activities and working through the code. Here are a few points that stood out for me.

• What’s the difference between and evar and an event? Evar = who or what triggered an event; events = how many times. So, an evar would indicate what made someone sign up for your newsletter, with the successful registration counted by your event variable.
• Don’t use “categories”; leave blank (or, technically, use a semi-colon); once a relationship is set, you can never turn back; use classifications instead to show categories
• No commas in product names; that’s the delimiter for the next product if you’re putting multiple items in a product variable
• Use purchase ID to dedupe events on final purchase page; otherwise, you could inflate totals if someone reloads or later returns to that page. For example, you complete a purchase at home; the next day at work you go back to that page to print out the receipt for reimbursement–the page and visitor count has increased even though the purchase is final
• Call Omniture to turn on cross-category merchandising — that’s when you have products that fall into multiple areas; for example, you might sell a children’s Bible under Gifts, Kids and Bibles; this lets you set which area of your site gets credit for the sale of an item that appears in multiple lcoations.
• Internal campaigns — another case where you must call mniture to turn on this feature so thatit gets a separate line item in the commerce/conversion report
• For A/B testing, use an evar to check conversion effectiveness; for example, evar4=”Home Page Design 1″ or “home Page Design 2”; since this isn’t multivariate testing, you’ll need to test but one item at a time
• To track Flash, use ActionSource
• Get QueryParam can support multiple campaign indicators — you can choose CID and PID and SRC, etc.
• If you want to track the success of your forms, call Omniture to turn on Form Analysis Plugin; it is not set by default

Here are my top lessons learned and next steps from day one of Omniture SiteCatalyst Advanced Implementation training held at Omniture’s headquarters in Orem, Utah. The class was probably a little larger than usual with more than 20 of us attending, not including a few no-shows. Some students were brand new to the Omniture web analytics package, but most were like me and had some experience. A few seemed pretty advanced. It wasn’t unusual to hear of attendees coming in to fix botched Omniture implementations, including one company going through three failed attempts.

If you take the class, take a look at the training videos and be familiar with the report interface. Better yet, show up with the specific business objectives and conversion events that you want to track.

Key Points and To-Do’s from Day I

• Set the debugger
• Version 13.5 is now available – start using it
• Make sure all users log in under their own accounts so they can personalize it, remember favorite reports, etc.
• Version 13.5 can now display more than 50 line items at a time! Yay!
• Create full spreadsheet mapping business requirements to reports to Omniture variables
• Call Omniture support to turn on daily uniques and visits for your most important s.props (this isn’t turned on by default)
• Continue to test and tweak your code in the development report suite; go “live” in production (I had been instructed that development was for when you first implemented, but after that you always worked in production; in fact, you can set up multiple report suites for whatever purpose you want)
• No charge for multiple report suites; you might want ones for different countries, companies; or for a church and a school). If you want data populated in more than one report, though, then it costs extra.
• Omniture doesn’t officially support Firefox for reporting, but it’s working fine for me; with Firefox, you can use FireBug for debugging.
• In the Admin tab, go to report suites and edit settings to turn on props.
• Internal search terms – use toLowerCase(); script to change values to all lower case in order to combine like values

Day Two»