TROUBLESHOOTING TOOLS AND CONSIDERATIONS
The JavaScript - based Debugger allows you to view the parameters sent in an image request. It supports Microsoft Internet Explorer, Mozilla, Firefox, Safari and other Web browsers. For more information on installing and using the JavaScript Debugger, refer to the JavaScript Debugger white paper, available in the Site Catalyst knowledge base.

Other Debugging Techniques
Another option for debugging the SIte Catalyst code on your pages is to use Web packet sniffer to view the request, along with the parameters. If you do this, you will still need to know the parameter names, as they appear in the Debugger.

A few examples of packet sniffers are:

  • Wireshark - (www.wireshark.org, formerly Ethereal).
  • Charles - (http://www.xk72.com/charles).
  • Fiddler - (http://www.fiddlertool.com).
These tools are especially useful for debugging Flash and custom link tagging, because Flash and links are not shown in the Site Catalyst Debugger tool. They can also be used to catch multiple image request, in the case when a page is double-tagged (different from Multi-suite Tagging). The image request is a GET request using HTTP as the protocol and is displayed as the following (if using third-party cookies):

      http://reportsuiteID.112.2o7.net ...

Troubleshooting Considerations
In most cases, if the image request is sent to Site Catalyst, the basic stats (page views, visitors) are captured. You should be most concerned with custom implementation issues such as conversion tracking, flash tracking and custom campaign tracking.

Problems are typically cause by the following:
  • Variables & Values syntax: Lack of knowledge regarding how to use specific variables and functions.
  • New pages on site: Process not in place to include Site Catalyst code on new pages.
  • Code Modifications: Sudden change of implementation someone changes the page without considering the Site Catalyst tag.
  • JavaScript JS File: referenced wrong or nonexistent Common Problem Countdown.
The following problems are the most frequently encountered during the implementation process, starting with number 5 and working down to number 1:

5. Variables not set correctly - using wrong syntax.
Avoid things such as:
    s.pageName=”document.title” - Shouldn’t use quotes.
    s.pageName=Home; - Should use quotes.
    Case sensitivity issues (i.e., evar should be eVar).
To prevent incorrect syntax, use the Debugger to check all variables values are passed in correctly.

4. s.purchaseID not used on purchase pages.
To prevent duplication of orders, revenue, and units, always use the purchaseID variable for purchase.

3. JavaScript file nonexistent or referenced wrong.
If the JS is not available to the page, the code will not execute correctly and the variable will not be sent into Site Catalyst. To prevent this issue, ensure the JavaScript include file is accessible to ALL tagged pages. If you are going to use a relative link to the JS file, make sure that relative link is valiad for all pages.

2. Setting the wrong report suite ID.
You may use the Debugger, and see that variables are set and should be populating the reports. But then when you go into the reports, there is no data. This may be cause by the wrong report suite ID being referenced. To prevent this issue, check your list of report suite IDs and ensure the s_account variable is set correctly. To get out of it, monitor traffic after go-live to ensure the page names are correct.

1. Placing the “code to paste: in the tag.
If you have placed the Site Catalyst code between the head tags, instead of between the body tags, you will not get an image request sent to Site Catalyst. The Debugger will show no values, reporting that is couldn’t fine the image request. To prevent this issue, ensure that the code to paste in within the body section of the HTML page. It is often recommended to include Site Catalyst code in a global “header” or “footer”. This is great, as long as it is placed with in the body section of the HTML page.

Another issue that is noteworthy is that occasionally there are page names that don’t make sense, but they are very few when compared to total traffic levels.

And One More Thing ....
Occasionally you will notice values is reports that don’t make sense, values whose origin is a mystery. This could be be strange page names, site section names, values in custom reports, etc.

These values could be a result of strange browsers that don’t understand the logic on your page that is populating variables. They could also be a result of values replaced by parental software, or any other software, including viruses on the visitor’s computer, etc. The point of this is that you need to decide if it is worth your time to figure it out. If the numbers are very low for this strange value, do you really need to spend your time running it down, just so you can get it out of your report? May be it would be better to ignore it, since you are not going to change anything on your site based on the strange value.

However, if the strange and unexpected values represent a sufficient percentage to throw off your numbers, or if you just need them out of your reports, you can use the Debugger to troubleshoot your site, testing different pages and checking values. You can also contact Omniture Support and discuss options for tracking down these values and why they appeared.