on target
User Analytics: How to Collect Data
User analytics can be used to know how your users employ your application: what they usually do, how much data they manage, how they perform different tasks, the difficulties they face ...
In previous posts we have seen the importance of user (usage) analytics and a flexible data model to support your information needs. In this post I will show you how to capture the usage data you need.
The UA record
Usage Analytics (UA) can be collected through a simple record that we will call Usage Analytic Record (or UAR) with the following structure:
Those records are generated (and lately consolidated) whenever a important events occur or periodic snapshot of data shall be collected (see description of “count” field).
You have probably noticed that UAR is extremely simple: the record contains no specific user or counter attribute like user name, location or task type. Such data will in fact be merged at consolidation time. This approach will give you three main advantages:
You can instrument all your applications through a single, shared library.
Applications that use such library will be immediately UA enabled.
You can start collecting data even if you still haven't decided how to analyze it.
You can change your mind about UA requirements without impacting on applications.
So let's now shortly analyze each record field.
Date & Time
Can be conveniently encoded as seconds
(or milliseconds) since say 1/1/1900 local user time. Why
local user time? Because you are not making web analytics or
performance analysis! Your intent is not to determine when server is
overloaded ow when you have a lot of visitors. Your intent is to
understand how your user uses application. What matters here is user calendar and user cycles, not your calendar or your cycles.
Unique User ID
Choose an unique ID for each different
person that uses application. This is usually a natural key like
email or login ID but, if your users are not initially identified
(for example a freeware application) a unique surrogate key can do the job.
Unique Counter ID
This shall uniquely identify what you
are counting: the specific transaction, error and so on. The best way to
obtain such unique ID is to get it from source code: usually the class name of tracked counter as in example below.
Count
The exact meaning of the count field depends on associated counter. In the case of task counters, error counters and similar measures the count field shall simply contain integer value 1.
In the case of snapshot measures (see previous post) it shall contain the collected value, for example the count of open tasks under user responsibility in a project management application.
Instrumenting code
Let's now see how you can instrument your code. We need an “Usage Collector” that will take care of collecting and possibly transmitting at certain interval usage data. In this example I am supposing a RIA Java application collecting data on client machine.
public interface UsageCollector {
void recordUsage(String userId, String counterId, int count);
}
...
public class SimpleUsageCollector implements UsageCollector {
private static SimpleUsageCollector instance = new SimpleUsageCollector();
private SimpleUsageCollector() {
// Initialization here
}
public synchronized static SimpleUsageCollector getInstance() {
if (instance == null)
instance = new SimpleUsageCollector();
return instance;
}
@Override
public void recordUsage(String userId, String counterId, int count) {
// code to write date to local file and transfer at
// day end.
}
public void recordAction(AbstractAction action) {
// Suppose Application.getCurrentUser() return current user ID
recordUsage(Application.getCurrentUser(), action.getClass().getName(), 1);
}
}
In addition to recordAction you can define recordError, recordSnapshot and so on (obviously with different parameters). Then all what you have to do is to add required action listeners or properly wrap Action class.
Once you invest some hours in writing a reusable class or function to produce the UAR you are done. It would not make much sense learning a library for such a simple task.
Recording application usage shall be really very simple, like writing to the log file. A more sophisticated alternative (if
your environment permits) would be crosscutting through Aspect
Oriented Programming (AOP), but I think in most cases that would be an overkill.
If your application is a RIA
application, you shall also, from time to time, transmit usage data to a server (letting user know you are doing that is convenient and polite). This includes GWT, Flex, or Java FX applications that will probably collect data at client interaction.
In next post you will construct a multidimensional application to analyze collected data.
Are you a management consultant?
Would like to try or coach this technique with your clients, do you need any additional or technical detail? Please let me know! Component Bases Solutions has great interest in partnership with business consultants. We can help you automate your proposed solutions in a very short time. We can also help to increase your visibility through links from many management tools we make freely available on the Web. Please contact for more detail.
Did you like this post?
Please, spend a few seconds and click on button below to socially bookmark it or tweet it. It will help to promote this blog and improve its content, Thank you!
|
 |
 |
Posted at 12:00AM Jan 19, 2010 by admin in IT | Comments[0]
