Web Analytics Tutorial

Appendix A – Making Reports More Usable

Matching Expectations

In presenting your web analytics reports, it is important that the people reading them can understand what they mean. Much of web analytics is built on concepts, terms and units that are not familiar to people in other domains of expertise. Often, when presenting statistics to business, finance or marketing managers, you will need to organize and phrase your conclusions in terms of the business model or design model of your web site, which may not be the same as the request model that is in your web logs.

Some of the simplest things you may need to change are terms. For example, when presenting advertising results to a marketing manager, you may think of the number of ‘hits’ each ad received, while the marketing manager is concerned about ‘impressions.’ As we discussed in Lesson 1 - What is ‘Web Analytics?’ these are about the same thing (with variance for caches). Similarly, business managers may want to know how many ‘page views’ a given page has had, while Summary will list it as Pages or Hits (depending on the report.)

Summary produces many reports covering a broad range of web analytics concepts. This deluge of information can be confusing, especially to readers who are only interested in particular aspects of the performance of a web site. A simple solution in Summary Plus or Summary SP is to disable those reports that are not important to the audience. If you are building subreports you can limit each subreport to only contain the necessary reports. This makes the presentation much easier for the reader to manage.

Figure 1. Sometimes your readers just want a “Dashboard” of important quantities.

Web Server Configuration

Sometimes, you can simplify your task by configuring Summary to reflect the expectations of the report readers. That way, you can just provide access to reports, without having to make custom aggregate ones. One common example of this is when a web server is configured to allow different requests for a give item. The widgetmanager.com site has a /products/ directory that contains information about their products, naturally. To simplify links and reduce log file size, they have set up the web server to map all request to /p/ to the products directory. So a promotion might say to click on http://www.widgetmanager.com/products/new_tool.html, but the site’s links all point to http://www.widgetmanager.com/p/new_tool.html. The log file is full of requests to both locations, but most of the people at widgetmanager.com only think about the pages in the /products directory. In order to make the reports clearer, the site manager can create an Request Alias, in Summary’s configuration to convert all requests like /p/* to /products/$1 (the ‘*’ matches anything and the ‘$1’ puts that into the result – see the Summary manual for details on setting up Aliases.)

There are many more web server configurations that you can use to make up for the difference between what shows up in the logs and how your readers think of the web site. One more example of this is the canonical name of your web site host. In our example company, most people think of the site as ‘www.widgetmanager.com;’ however, the server also responds to ‘widgetmanager.com.’ To distinguish local referrers from remote ones, Summary needs to be told that these are both valid domains for the web site. Because this is very common, Summary asks for the primary domain and then allows others to be listed, separately. If the site manager configures Summary to use ‘www.widgetmanager.com;’ as the primary domain, then all the requests in reports with be linked to this host name, which is what the people at widgetmanager.com expect.

Adjusting Definitions to Improve Metrics

Figure 2. By changing the Request Types Configuration you can match analytics units to your web site design.