Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / web / IIS

Web Session - Monitor, Record, and Video Playback

2.94/5 (12 votes)
6 Mar 2008CPOL6 min read 1  
How to: Monitor, Record, and Playback every visit to a website using very simple techniques and existing technologies.

Introduction

Using JavaScript, a little AJAX, and an HTTP Module, we can record client DOM events by posting them to the server via small AJAX packets, storing the information in XML format for later retrieval. The XML could then be parsed either in real-time, or otherwise to provide a true visual representation of the user's session (in motion or with an accompanied timeline), enabling video playback of an entire visitor's session.

The concept has many applications:

  • Real-time web application technical support
  • This could be achieved by viewing a user's session to identify the issues whilst speaking to the visitor via messenger/telephone etc.

  • Web application training
  • Talk the user through the application whilst you view the session in action.

  • Advanced web statistics
  • Provide almost video playback of each and every visitor to a particular website.

  • Usability testing
  • Generate genuine usability figures by processing the session information captured.

  • Remote assistance
  • With a little tweaking, control could be passed to another session and events relayed to allow an administrator to take over a visitor's web page on request and perform clicks, fake mouse moves etc.

Limited only by your imagination I believe.

Concept Overview

The concept is to provide an HTTP Module that intercepts web requests and records session information in XML format. At the same time, it injects some client-side JavaScript that captures all the events on the page via the DOM. Using a very light-weight AJAX script, it sends information about each event such as tag name, event type, and event date (millisecond resolution) the event was triggered to the server. This information is then stored on the server in an XML structure under the current users session key for later retrieval.

The site administrator would then be able to view a list of all sessions on the server, select a session, and either choose to play back the entire session or view the almost real-time session in process. This could happen by loading a page containing an IFrame to show the pages visited, and the contained page executes a script to retrieve the events and fire them accordingly. To demonstrate the mouse movement, an absolute Div could be positioned over the page at the specified X and Y. Events on the page could be triggered using .fireevent or an equivalent method.

Alternatively, a Flash presentation type application could be created; together with some C# it could read the XML, have C# take a snapshot of the page as an image, load the image, and process events using mouse pointers etc., to demonstrate the events. As each event is recorded with a millisecond timing, the overall time of the session could be calculated and a timeline assigned, thus allowing the user to speed up the session playback or skip sections. Of course, as I have said, this could also be done in real time as the user is using the site.

The applications for this are immense. Why bother recording geo location and page visits when you could have it all together with a video of the entire session? A usability tool could be applied over the top to determine how difficult the user found the site. The point is, once you understand the concept, the possibilities are endless.

You could even transmit events from one session to another, creating remote assistance in the browser. Now, that's smart, right?

Required Elements

  • HTTP Module
  • Captures the session start and creates an application variable with the name of the session key. It then inserts an XML document into the variable as a string that would later be used for storing events. It injects a script file (link) into the page to load the monitoring events. The script file is requested from the HTTP Module and built on the fly, maybe using an embedded resource file as a template. This means we could have an XML config file on the server to allow the administrator to define which events he's interested in monitoring/recording for each visitor. Such as click, mouse move, mouse over, onbeforeunload, keyup, etc.

  • AJAX Layer
  • A light AJAX layer to allow sending of events without refresh. This must be light weight because I just hate all the overloaded frameworks out there, and it would only cripple the solution. The AJAX layer would take events into a local array/stack and push them to the server when possible, ensuring no events are missed. Common sense would need to be used here as we only want to send essential and compact information (so no complete form posts); find another way to do that. It should only be a few bytes at a time. Anything more could mean close to real-time viewing of sessions could be compromised due to the time taken to send/process events. Each event should be bytes in size including the HTTP header posted.

  • Admin Interface
  • Again, embed this into the HTTP Module as it will make the component more portable. Have a username and password stored in the web.config or another config file. Once the HTTP Module receives the request for the said page, it will prompt the user for login, and providing they pass, it will render the page containing a list of sessions sorted by time, with maybe a nice flag to show where each visitor is from. OK, you could go mad here and render them over Google Maps. Actually, that would be impressive - a Google globe map of your live sessions.

  • Playback
  • Again, an embedded resource to make the DLL portable. Provide a page that contains an IFrame tag, and again, light AJAX to retrieve the session XML in fragments. Using the IFrame, load the relevant pages when required. Using a Div with maybe an image of the mouse pointer, animate mouse movements. You could also tweak the IFrame DOM directly to fire the relevant events. (Maybe an elements GID could be created based on the original elements index in the DOM.)

  • Flash Movie
  • XML event information could be passed to a Flash interface. Maybe use C# to return an image of the required URL, and then use Flash to animate the pointer over the image to represent the session in motion. Again, this could be almost real-time.

    For full session viewing, the XML event file could be parsed and all event times processed to provide a second timeline of a session. This would mean the user could skip parts of the session similar to how they might skip sections of FLV videos. Alternatively, they could speed up the replay of the session.

  • Data Analysis
  • Given we have detailed event information in XML format, we could use this to estimate usability trends. E.g., how long it took the user to reach the final goal of the site (ordering a product, for example) before ending the session.

Event recording example (JavaScript)

JavaScript
var oAJAX = new AJAX();

window.onload=function()
{
    //
    // global mouse move
    //
    document.mousemove = function(e)
    {
        // send event to server with X and Y
        oAJAX.send("send Mouse X & Y, tagName " + 
                   "and Current Date/Time to the millisecond")
    }
    
    //
    // global mouse down
    //
    document.onmousedown = function(e)
    {
        // send event to server with X and Y
        oAJAX.send("send Mouse X & Y, tagName and " + 
                   "Current Date/Time to the millisecond")
    }

    //
    // get a collection of all tags
    //
    var aTags = document.getElementById("*");
    
    //
    // the events to be captured could be configured in an XML config
    // file on the server and this script file build on the fly.
    // therefore allowing the site administrator
    // to decide the events/elements to monitor.
    //
    for (var i=0; i<aTags.length; i++)
    {
        var el = aTags[i];
        
        el.onclick = function(e)
        {
            // send event to server
            AJAX.send("send Mouse X & Y, tagName and Current " + 
                      "Date/Time to the millisecond");
        }

        el.onmouseover = function(e)
        {
            // send event to server
            oAJAX.send("send Mouse X & Y, tagName and " + 
                       "Current Date/Time to the millisecond");
        }

        el.onblur = function(e)
        {
            // send event to server
            oAJAX.send("send Mouse X & Y, tagName and " + 
                       "Current Date/Time to the millisecond");
        }

    }   
}

Danger, Danger

There are, of course, many side effects to this concept. If we captured all events on the screen, this would also give us the ability to capture the message you were thinking of posting to a newsgroup but decided to delete, or maybe the chat room message you re-edited before posting. I guess when we get to this level of monitoring, it makes you realise how exposed we really are.

As JavaScript/AJAX are in massive use in today's browsers and applications, this technique could be created and implemented without the visitor ever realising they were being monitored.

Points of Interest

I do hope this makes sense; I would welcome any feedback. I am a behind the scenes type of developer, and therefore have never posted an article, so please don't shoot me down!

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)