Implementation of Omniture SiteCatalyst isn’t that difficult by any means, however validating that scripts are in place to populate variables in your solution design can be somewhat challenging for those outside of the web analytics community. The challenge is not that it’s particularly hard to debug Omniture implementations, but it can be hard to explain why, for instance, Omniture uses separate traffic and conversion variables. The second challenge is finding tools that support cross-platform testing and validation efforts; the subject of my post today.

Firefox is probably the easiest platform to test because most developers will use Firefox in their development environments when coding. Firefox has a myriad of tools to choose from, but the most popular tools for validating Omniture implementations that I have come across include the following:

  • Firebug, and optionally Omnibug plugin for Firebug:
    If using Firebug, activate the Firebug interface by clicking the bug icon located in the lower right hand corner of Firefox and activate the “Net” panel. Look for image requests starting with “s” and incorporating a long string of numbers, for example, “s1230923w84…” or an image call originating from a subdomain of 112.2o7.net (for third-party cookies) or metrics.[root domain].com. If you opt to choose Omnibug, Omniture image requests are automatically filtered and shown using friendly variable names, which makes life much easier.
  • Fiddler2
    Fiddler is not usually required with Firefox, because Firebug and Omnibug are much easier to use. However if you’re testing different versions of Firefox, some with varying levels of compatibility with Firebug and Omnibug, Fiddler comes in as a strong second opinion.
  • Omniture Digital Pulse Debugger
    It can’t get much easier than this… the new Omniture Digital Pulse Debugger makes validating implementations so much easier, but it comes with consequences. First, it’s not that fast when trying to debug variables while navigating page to page, you have to give it a second to update. Second, I’ve had issues where I had to reload it when switching from one domain to another. Otherwise, it’s a very simple tool to use and share amongst your QA teams.

Gosh, how I loathe Internet Explorer. It’s just so bad, at so many things, that most development teams would prefer to ignore the segment of users entirely than test in old versions of IE. However, versions of IE such as 6, and 7 still represent significant portions of our internet audiences, so we have no choice, we have to live with testing for these *shudder* browsers. It comes as no surprise then, that IE doesn’t have a lot of reliable plugins to test with, so unfortunately your options are to test externally of the browser itself using packet sniffers or proxies.

  • Fiddler2
    Once again, Fiddler is an application that lives outside of a browser, and can make your life testing different versions of IE much easier.
  • Charles Proxy
    A nice little tool that does pretty much the same thing as Fiddler, if you’re only interested in debugging.
  • Omniture Digital Pulse Debugger
    Again, throw the debugging JS into a “Favorite” and testing can be as easy as clicking that favorite in a toolbar.

Chrome is relatively easy to debug with. Check out the built-in debugger that Google programmed into Chrome to look for image requests hitting Omniture servers, or use the same options as IE above.

Mobile platforms are interesting, because many of them still don’t support javascript, but even if they did, debugging them on the device itself is never intuitive. For platforms that supply emulators, debugging Omniture implementations is a little bit easier, but still far from straightforward for most. Luckily, Omniture provided an excellent write-up on how to debug mobile implementations.