Gathering user statistics from FSI Pages

An easy way to gather statistics from FSI Pages, is to have FSI Pages pass a parameter in the GET request, when the user clicks on a link in FSI Pages. This parameter can be processed by a server sided script, e.g. to count the pageviews of a certain article in the onlineshop generated from within FSI Pages.

 

Getting the amount of pageviews within FSI Pages itself can be achieved with the FSI Pages logging features, available since version 4.1.3. The setup for FSI Pages is very easy, and consists of only 4 parameters that need to be defined, but it relies on some server sided script to take care of the logging. We will explain 2 alternative ways to log the pageviews within FSI Pages in this tutorial, one uses google analytics and the other one uses the open source log analyzer awStats.

Setting up FSI Pages logging features

To enable the FSI Pages logging feature, your .xml configuration file should contain the following parameters:

As you can see above, each configuration file should have a different UniqueID set. This helps you assigning the pagehits to different catalogs on your website.
Please use characters and numbers for the UniqueID value only and do not use any of the following characters : [Space] ~ % & ; : ” ‘ , < > ? # ..

Parameters explained

The PageLogDelay parameter defines the delay in milliseconds, before the URL defined in PageLogURL is requested in the PageLogTarget.

The PageLogTarget’s default value “_internal” defines the request to be done in the background, but can be any valid HTML frame target, e.g. “_blank” for debugging the script (see below).

The PageLogDelay value in milliseconds should not be defined too low. We suggest a value of about 3000 ms, which will require the user to look at a certain page for 3 seconds before the pagehit gets logged. This will prevent the log from being flooded with entries from people just flipping through a catalog quickly to reach a certain page.

The PageLogURL needs to call a serverside script, which will take the parameters and store them in a database. The placeholders in square brackets […] will be replaced with valid values by FSI Pages at runtime.

FSI Pages will replace the following parameter values before performing a log request:

[pagenum]:The pagenumber being viewed
[totaltime]:The time the user has been viewing the catalog so far (incremental)
[instanceid]:A unique value, identifying a certain FSI Viewer instance
[uniqueid]:The UniqueID configured in the .xml configuration file identifying a publication.

Please note: The PagelogTarget Parameter must be set to “_self” when using JavaScript functions calls.
If the PagelogTarget is set to “_internal” the JavaScript will not be executed.

Saving hits to the database

Collecting information with the page log feature, enables you to detect, which pages are being viewed most often in which catalog by counting the pagenum requests and how long a page gets viewed, as this can be calculated from the totaltime. Using the instanceid you can also collect each users behaviour anonymously.

A skeleton script for saving the requests to the database could look like this:

This script would use the class “log” to store the information in a database.

Tracking hits with google analytics

Another way to keep track of the pageviews in FSI Pages is using goolge analytics. The following code can be used with the PageLogURL defined as javascript:trackFSIPageView(“[pagenum]”,”[totaltime]”,”[instanceid]”,”[uniqueid]”);.
The JavaScript function must be included in the HTML file containing the FSI Pages instance.

After you changed the UA-XXXXXXX-X to match your google tracking account identity, you can see the statistics in google analytics in the format of e.g.:

URLPage ViewsUnique Page ViewsTime on Page
catalogs/fashion/230029000:00:45
catalogs/fashion/330029000:00:33
catalogs/fashion/428027000:00:30
catalogs/fashion/520018000:00:40

Google analytics has it’s own algorythm to determine the time a user spent on a certain page, so the totaltime and instanceid parameters could be omitted.

Tracking hits with awStats

If you have a working installation of awStats (or any other log analyzer), you can track hits in almost the same way:

 

This JavaScript function uses the Image.Src property to generate the request that is needed for awStats to parse the log files. Using a JavaScript function gives you the opportunity to run JavaScript based browser detection or retrieve custom cookie related information if needed.

If you don’t need to do further user or browser detection or process other data, you can also shorten the above JavaScript function to generate the request directly. In this case you need to set the PageLogURL to http://logger.domain.com/catalogs/[uniqueid]/pages/[pagenum]
which will reduce the requests being sent for logging to only one request.

A sample awStats configuration file is available for download here:

 

Tracking hits with awStats is achieved by a little trick.
The request in this awStats example (e.g. “http://logger.domain.com/catalogs/fashion/pages/5”) does not exist on the webserver. This would result in the error 404 being logged by awStats.
For proper logging and tracking these supposedly generated 404 errors, we define a virtual host in the apache.conf, to log these requests.

If a subdomain is set up to log the HTML Code 200 for requested items not found, awStats can parse the access log and display the hits for each page:

 

The ErrorDocument “/dummy.html” should not contain any content in this case, at it is usually hidden when the PageLogTarget is set to “_internal” and the document is loaded on each request, which could result in unwanted serverload on high traffic sites.
For additional information on setting up virtual hosts see the Apache documentation.