Spring is (hopefully) just around the corner here in the northern hemisphere, with warming weather a young man’s fancy turns to that age old question…"what exactly are my users doing with my application?"

We’re familiar with big software vendors including Customer Experience Improvement Program (CEIP) features in their applications allowing them to gather anonymous usage data showing which features people are actually using. Analyzing that data allows them to focus their development efforts on what their users are actually doing, as well as obtaining hard measurements of how features are actually adopted in the wild. As someone whose paycheck depends on meeting the users’ requirements I really like to know how much of my time is being spent developing stuff that people actually want and use. Unfortunately, I don’t have the huge number of person-years and dollars to spend on something that is not directly related to my core application functionality to get a CEIP into my products.

Instrumenting an application to send its usage data back to the free Runtime Intelligence portal hosted by PreEmptive is covered in some previous blog posts (here and here ), but today I am covering a slightly different scenario. While there are great analytics capabilities in the hosted portal, my current needs are only basic usage tracking and that I must store the data at my own facility. As is normally the case in proof-of-concept situations, I have no budget, no time, and am highly visible to non-technical decision makers.

The first problem, no budget, is easily solved by using freely available tools. First, I am going to use Dotfuscator Community Edition 5.0, included in my copy of Visual Studio 2010, to perform injection of the application analytics functionality into my binaries. Since I need to store the usage data at my location I can’t use the hosted free endpoint and reporting portal, but I can use the new open source (Ms-RL license) Runtime Intelligence Endpoint Starter Kit (RI Starter Kit) to build my own application usage listener service, data repository, and basic reports.

The fact that I have no time to implement this is also solved by my selection of tools. Since this is a proof-of-concept, I don’t need to create any extra code to obtain the users opt-in consent for tracking application usage. This means I can leverage Dotfuscator’s post compilation code injection model, similar to IL Weaving in Aspect Orientated Programming, to inject usage tracking directly into my test application binary without changing any source code or recompiling. In a matter of minutes I navigate through my applications structure and define the injection points from within the Dotfuscator user interface. To create a database using either SQL Express 2005 or higher or MySQL 5 or higher only takes a few minutes. Finally, setting up the WCF service project only requires updating the connection string in the web.config. Using the outstanding documentation included in the RI Starter Kit as my guide in less than an 30 minutes I have a proof of concept for tracking how often my application is run and which features the users are actually using.

Finally, I have to show something useful to the non-technical users. I know that application analytics data is being sent to my endpoint and stored in the database. I can easily run a few queries to get a feel for how the application is being used but not everyone is as comfortable with SQL as I am. As I review the source code included in the RI Starter Kit I see that there is also a SQL Server Reporting Services solution that contains two prewritten reports that show application and feature usage over time. A quick update of the data source, a deploy to the SSRS server, and now the business users have an easy way of seeing what our users like best about our products. To add application analytics data to executive dashboards, there’s also a SharePoint Web Part included so you can easily put an application usage graph directly into any SharePoint site (WSS 3.0 / MOSS 2007 or higher).

All in all, I have spent around an hour and no money adding basic application usage tracking and analysis to an existing product and exposed that data to both technical and non-technical users. With only a small amount of code, I easily add an opt-in dialog to my product so my users can choose to send their usage data for analysis.  Now I have the start of my very own Customer Experience Improvement Program.

PreEmptive is always looking for feedback on our products, please take this new solution for a spin and leave us comments, feature requests and ideas on the project’s Codeplex page.