When Written: Aug 2013
So you have built your killer website and set up some way of examining of user activity on it either by analysis of the logs or by using Google Analytics or a similar system that requires you to put code on every page you wish to track. Ideally you will be using two or more systems as reassurance that the figures are similar, although this is not always the case in my experience.
Whilst these systems provide useful information I find that clients frequently have difficulty in fully understanding these stats, often because they are bombarded with information in differing and sometimes contradictory forms. Other clients want to track specific things, perhaps even in real-time and, whilst Google Analytics real-time display goes some way to achieving this, it doesn’t allow any customisation of what is tracked. It was because of these limitations that when a client wanted to launch a redesigned site with a paywall added they felt that they wanted to track what the logged in users were looking at in an attempt to improve the service. The solution was to write a class object that sat on the web server and this would be called on a ‘page_load’ event. Passing some parameters about which page was called and who was logged in when it was called, the class would then write this information into a database table and some simple admin pages were written that showed who was currently logged in, the last 100 transactions and the activity by the logged in user.
Obviously this can be extended but there are a couple of limitations that make this technique only really suited to web sites with a small amount of traffic. One is that each page access means an record in the database table and this will grow and needs to be purged from time to time to save it running out of disc space, and then there is the obvious issue of performance, since you are asking the server to complete a couple of database additions with every page access. I limited this by only recording logged in users rather than anonymous users and search engine spiders as the client was only interested in the registered user’s activity as they were the ones paying or looking to pay. Having completed my code and feeling fairly pleased with myself I got an email from Jane Lee who runs an independent PR company, Dexterity (http://www.dexterity.co.uk/ ) asking if I would be interested in a product called ‘User Replay (http://www.userreplay.co.uk ) that monitors a web site and enables its owners to analyse data in a very detailed way to the point that they can ‘play back’ a particular user’s route through the site to work out how any problems the user might have with the site might have occurred. It was suggested that this product was like a ‘Black Box recorder’ for web sites, I was immediately interested and an-online demo was arranged.
I can’t say what it is like to use for real as we were only using demo data but the product was certainly interesting as it allowed all departments to use the web site transaction data to extract specific information that was relevant to their jobs.
User Replay provides a clear view onto your web server activity for all departments to use.
So Sales could see what people were looking at and buying, Marketing could check the effectiveness of an advertising campaign and Accounts could analyse sales versus cancelled transactions for example all through an easy to use and understand web application. The idea is to capture every bit of data, but to present it in a way that non-techies would understand and also to enable someone to drill down on any particular transaction to see what went wrong if for example a user contacts them about a failed order. You can even recover ‘lost’ shopping baskets should the customer contact you about a transaction that went wrong. Having the ability to monitor your web site closely in this way can be very important.
All too often a web site is built, made live and left to run, perhaps the logs might get looked at when the bill for hosting come in so some justification can be made, but the web site can be a significant part of your businesses revenue as more and more companies are turning to the on-line supply of products and services. Thus it must be more important than before to have a way of keeping a close eye on things and being able to examine the transactions when things go wrong. For instance maybe a new browser version will start to cause problems with your site which results in lost sales, but how would you know by looking at traditional logs? Perhaps an examination of the user paths through your site might reveal a problem? But so often this is left to the over-worked IT department to look at. With this system the Sales department can not only examine the data this closely but also send the information to the IT department and they can then re-play it to see what the exact issue is. No longer is it a case of ‘your site is broken in my browser’ replied by a ‘well it works here’. The subsequent frustrations on both sides are removed. Before my demonstration, my first question was a concern I had about performance, if you were going to collect and store all this data then surely it would impact on the web server?
User Replay captures a copy of all traffic in and out of your web servers so there is no performance hit.
The solution to this was beautifully simple, using a special network switch, a copy of every bit of data was sent not only to the web server (or farm) but to a separate data collection server(s) and it is this server(s) that would be interrogated which also means that any analysis of the data is done away from the web server, again removing any performance hit that would occur. User Replay is not cheap as it starts at around £15,000 per site per year but if, as seems likely, it can help detect fraudulent transactions and claims as well as help detect lost sales opportunities then the case can be made that it could pay for itself.
As the system captures data flowing between the client and the server then any client based app, perhaps an AJAX based shopping basket would have to be re-coded to send data back during the different stages if a reasonable granularity is required, but this is the case with most if not all web analytic systems so not a criticism of User Replay. Because it requires custom hardware to be installed in the same room as your web server User Replay is not of any use to smaller web sites that use shared hosting, and how it would work in a Cloud environment like Azure is uncertain; however, they do have a solution for Amazon Web Services. So unless you use AWS or have your own rack in a machine room then I suspect that the only way you would be able to use User Replay is if your ISP installs it and offers it as an enhanced service to its customers. The fact remains that it is a clever and well implemented idea.
Article by: Mark Newton
Published in: Mark Newton