Lars Fløe Nielsen

Here are two often asked questions:

Question 1: How well does Sitecore work with site analyzer tools, such as WebTrends, Google Analytics or Instadia?

All of these systems basically are very generic statistics tools; they offer stats on most requested pages, walkthrough paths, browser types, operation types, pipe lines and success rates for your site. This kind of information is often unrelated to Sitecore; it can be extracted from the IIS log or from a section cookie (e.g. being passed to the server through script).

Every time the web site visitor requests a page, her behavior are being logged; what page is being requested and the previous page, user profile (browser type, resolution) etc. As Sitecore use friendly URL’s by default, you do not need to handle specific URL parsing to drop a logical name in the log, simply log /products/fruits/apple.aspx, and you will know that someone requested the apple documents which resides in the fruits category and which is a product.

Installation is very easy with all of these tools, and is entirely unrelated to your Sitecore installation, though you in some cases will need to add some JavaScript to your web page (see installation section). 

Beside this, some stat systems allow you to set up individual campaigns where special URLs are logged. Sometime these campaigns would also require modification of the web site solution, such as adding a campaign ID to URLs related to the campaign. This has nothing to do with your Sitecore installation but is related to the solution itself. However, Sitecore do allow you to, when designing your solution to add whatever you wish to your campaign.

In other word, Sitecore is very suitable for all major analytics tools, hosted or log parsing.

What about installation?

WebTrends, Instadia and Google Analytics supplies two methods of retrieving data from the web site:

1. Script based instructions (include javascript on your site which on every request sends session/request details to collection server).
2. Log parsing (reads data from IIS Log, not Google Analytics, which is a hosted service only).

Both methods offer benefits and disadvantages:

Using JavaScript

Using the JavaScript approach, you will need to place one or more lines of JavaScript on your web page. The purpose of this script is to pass details on the current user request and user object to the remote (hosted) analysis server. Putting JavaScript on your page potentially raises two problems:

1. User browser may not support JavaScript whereas stats on this user profile group are lost.
2. Putting JavaScript on your page may compromise the accessibility or web standard (such as XHTML) you have chosen.

To be counted on the benefit side is the ability to get your statistics hosted hence simplifying your server architecture and lessen the administration.

Using log parsing

To use a log parser you must usually install some software on your local server which at specific intervals parses the IIS log.

Benefits is that your web page will remain unaffected; as all session state and user state is written to the IIS log, - you are not bound to send this data through JavaScript.

A disadvantage is that you are bound to install the server locally which usually increases maintenance and initial installation.

Do we not need to do anything at all?

You can always choose to enhance your local installation; for example I would love to see some of the readers out there upload a “Google Analytics” extension that would eliminate the Google JavaScript: This can naturally be achieved by adding a pipe line entry to the HTTPRequest pipeline which passes a POST request to the Google server with whatever information they need.

Another idea of extending the integration between traditional major hosting solutions would be extending the Sitecore Content Manager interface to reflect how many times an item in the data structure has been read: User logs on to Sitecore, and browses the data structure; a context menu would display stats on the item.

But really, you do not need to do anything specific if you can live with either a hosted solution (or JavaScript on your server), or if you are to install locally.

Question2: How do traditional stat tools differ from Sitecore StatCenter?

Well, Sitecore StatCenter is unrelated to traditional analytics tools: The traditional tools can pick up generic user data behavior and overall stats such as browser types, screen resolutions, referring site, page statistics etc. This is not something Sitecore Statcenter does very well. If you need this kind of information, WebTrends, Google Analytics or Instadia is much better (and looks much better too).

But StatCenter excels in another field: Statcenter hooks deeply into Sitecore and exploits the knowledge of the user and content. This allows you to see exactly what any user have been doing on the web page, e.g. how many time the user has returned, what pages the user visits and how long the user have spent on the page. Also, it’s possible to see if other users from same IP number have been visiting your web page, and what they did.

You can tag specific Sitecore pages and through the API award pages points. When a certain amount of points have been reached, you can raise an internal event, and e.g. modify your web page according to the user behavior (personalize the page).

So, what would I need?

Some organizations are very interested in the general stats. If you find yourself in this category, you should use one of the excellent 3 part web site analyzers.

Some organizations want to follow and act on the individual user behavior, and do not focus at all on general stats. They should use StatCenter.

Finally some organizations may find interest in both general stats as well as the ability to trace individual user behavior and page behavior. They should consider using both.