The final directive you may want to configure is the expiry time for the cookie. The expiry time helps determine the difference between “sessions” of the same user. As long as the user keeps using the Web site, the session will be updated, but when he leaves the site, the cookie will eventually expire and a new one (and corresponding session ID) will be generated on his next visit the site.
You must therefore configure the expiry time to enable a user who visits the site to take breaks, if necessary, while he answers the phone or attends a short meeting. Choose a timeout period suitable to identify the difference between visits to your site. For example, for a news or shopping site, a timeout of an hour would probably suffice, but an intranet site intended to be used all day might benefit from a 12-hour timeout.
The default option is for the cookie to remain active until the current browser session is terminated (i.e., when the user quits the application). Alternatively, you can set a specific time either in seconds or by using an explicit declaration in years, months, weeks, days, hours, and minutes (e.g., “2 weeks 7 days 9 hours”). If you use this format, be sure the directive parameter is enclosed in double quotes.
The CookieExpires directive configures this option. To set a timeout in seconds, specify the number of seconds as an integer:
CookieExpires 3600 |
The above sets an expiry time of an hour.
The final configuration directive is where the information will be logged. Our preference is to record this information as part of the standard access log. The %{Cookie}n log field contains the cookie information (hostname and cookie ID), which can be added to the standard common log format definition:
LogFormat "%h %l %u %t "%r" %>s %b %{Cookie}n" common |
We recommend putting the cookie information at the start of the log, rather than the end:
LogFormat "%{Cookie}n %h %l %u %t "%r" %>s %b " common |
Alternatively, you can configure a customized log for cookie data by putting a CustomLog directive in the site definition:
CustomLog logs/clickstream "%{cookie}n "%r" %t" |
Once the user track information is configured, try using the site and viewing the log. The log below is a standard access log with the cookie detail added.
polarbear.mcslp.com.1106159183940914 polarbear.mcslp.com - - [19/Jan/2005:18:26:24 +0000] "GET /mcslp.css HTTP/1.1" 304 - polarbear.mcslp.com.1106159183940914 polarbear.mcslp.com - - [19/Jan/2005:18:26:23 +0000] "GET / HTTP/1.1" 200 7970 polarbear.mcslp.com.1106159183940914 polarbear.mcslp.com - - [19/Jan/2005:18:26:24 +0000] "GET /weather/images/symbo l_10.gif HTTP/1.1" 200 2019 polarbear.mcslp.com.1106159183940914 polarbear.mcslp.com - - [19/Jan/2005:18:26:24 +0000] "GET /weather/images/symbo l_24.gif HTTP/1.1" 304 - polarbear.mcslp.com.1106159183940914 polarbear.mcslp.com - - [19/Jan/2005:18:26:26 +0000] "GET /contacts/ HTTP/1.1" 200 14671 |
It’s easy pull out the necessary information from the log to identify which pages this individual has been viewing — we now have a suitable tag (the unique cookie ID number) to start summarizing and reporting information. The basics of log reporting have been covered in previous articles.However, at its most simple, extract the cookie ID (as shown here), and then use it as another key for summarizing log data.