on target

« User Analytics: Why... | Main | Charts & Graphics:... »

Tuesday Jan 12, 2010

User Analytics: the Information Model

In previous post I explained the importance of User Analytics and I promised a flexible model to measure application usage. This post is about such model and how to implement it.

A classic approach

The first attempt would be a typical multidimensional model:

Time dimension

Month

User Dimension

User

Age range

Skill

Measures

# of tasks executed of type 1

# of tasks executed of type 2

# of records inserted

# of errors of type X detected

# of errors of type Y detected

Size of database (not additive along time)

Time spent on application

This model responds to all our questions, for example we can quickly assess usability by dividing the number of errors by the number of performed tasks and trace evolution along time.

We can also identify churn (users that reduce application usage) and assess how vital our application is by looking at daily task count and database evolution.

This model can be mapped to a classic star schema:

But that model has a major drawback: our set of measures is highly dynamic causing constant update of fact table. Whenever we add a new task, we shall add a column to the fact table. The same happens for errors or whatever new count we need. Applications are so dynamic in practice that almost each week we discover new measures.

There is a secondary drawback too. If you decide to compare the total number of errors of skilled vs. unskilled user you shall use multiple operands (one for each error type) like:

[count of task 1] + [count of task 2] + ... + [count of task n]

There shall be a better way ... let's try an alternative!

A better approach

Happily all stored measures we need are basically counts: count of transaction, errors, records, seconds.

Using this principle we can reformulate our multidimensional model in this way (scales are from Thomsen notation, arrows mean aggregation):

We employ a simple measure (Count) and introduce a dimension to identify what we are counting. This lead to the following star schema:

This unorthodox approach can seem strange and possibly wrong at first glance (a model with a single stored measure?) On the other side, this is exactly how many multidimensional models are implemented, including MDX (multidimensional standard like SQL is the relational standard): all measures pertain to a "measure" dimension.

This approach works in practice very well. Suppose we decide we shall know how many login were made to application. We simply add a new row (counter.name = “login count”) to Counter dimension and we are ready to collect and analyze it.

We can also aggregate different counts with ease, for example errors by severity, tasks by module and so on, without those tedious additions we like in previous example. That would be impossible if we used distinct measures.

Snapshot Measures

This model also allows the analysis of “snapshot measures”. Let's suppose you are measuring a project management application and need to measure the count of active tasks for a certain manager along time. You take a periodic snapshot of such count and store as “Open task” counter for the given user and date.

Snapshot measures are non additive along time, and this shall be clear to analytic users if they dispose of self-service tools like PISA: summing active tasks along time because it wouldn't make sense. You have a single measure (count) that can be aggregated or not depending on one dimension!

Now you have a flexible model to collect your User analytics. In future post we will look at code instrumentation to systematically collect such data.

Interested in partnership?

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 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!