Posts from — July 2008

When you click on Re-Analyze, you get the warning “Any previously analyzed data will be lost.”

Let’s make that little warning really clear. It means: Should you go ahead with a re-analyze, ALL previous processing will be erased, along with all WebTrends-controlled backups. Your configurations stay, but WebTrends deletes all statistics and all backups and starts analysis over with the earliest raw data it can find.

This is the place where you can suggest topics or questions. In the comments, we mean. Go for it.

Suppose somebody on your site searched for something (using on-site search) and then left the site directly from the results page. Wouldn’t you want to know what the search term was? This is a semi-easy custom report that will give you just that — a list of search terms for site search results that were followed by an exit.

If you’re analyzing data for a web site that’s available to the public, you probably don’t want your own company’s traffic in the reports. (The situation is quite different if you are analyzing traffic on your company’s intranet.) Filtering out your coworkers’ visits to your web site isn’t always straightforward. Here are the two most common situations and the solutions.

Javascript analytics tags like WebTrends’ SDC tags generally don’t track error pages, i.e. 404s (page not found), 500’s (server errors), and so forth. Server log files do. Most people accept the absence of error tracking as one of the tradeoffs of using tagging, outweighed by tagging’s many other advantages.

It’s actually easy to track error pages even if you tag your pages. It’s done by getting your site’s server to return a tagged page whenever one of these client or server errors happens.