An interesting question was posed to me recently while several coworkers were building custom reports in our proprietary e-commerce engine, PowerShop, to meet client requirements. As an organization, we always encourage CMS-integrated analytics as this provides substantial inherent value. As a business analyst, my favorite aspect of this setup is increased accuracy in reporting. Most analytics packages leverage JavaScript implementations and as I’ve come to find in the 5 years since I’ve been in this field, JavaScript requires attention to detail to reduce (not eliminate) reporting discrepancies. Even then, I always recommend using these tools to see patterns or trends (e.g. – “Have orders increased or decreased month over month?”).

This sounds like I’ve digressed! The point I get to is this: I encourage clients to leverage DB queries or in-system reporting when you absolutely must have actuals. So, clients sometimes request additional reporting to meet requirements for actuals. This led to our discussion about session. How do you define a session in an e-commerce engine? Do you need to factor in registrations and logins? Do you need to consider idle-time? Well, I’m a big fan of keeping things simple and what it comes down to is that when using terminology that’s common in the analytics community, you want to adhere to what other packages offer as best as possible otherwise this can get extremely confusing when reporting on metrics that have the same name but mean different things.

So what is a session? A session is a visit. Don’t worry about factoring in session length, logins, etc. because these elements can be saved for other reports. Indeed, if I have 5 visitors in a day where 3 visited twice and 2 visited once then if I pull a sessions or visits report, I should see…8. If you don’t force the metric to include those other factors, I can then ask:

1) How many of those sessions included a login attempt?
2) How many login attempts were successful?
3) Did visitors log out?
4) What was average session length in minutes?
5) As a composite metric, what was session length in pages for unauthenticated visits?
6) Also as a composite, what was session length for those visitors that logged in?

You may find after answering these questions and analyzing visitor activity that some site functionality is not as intuitive as you initially thought and revisiting your site’s usability can improve the quality of visitor experience. In saying “Sessions are defined as an authenticated or unauthenticated login regardless of whether or not the browser was closed and if idle time is less than 20 minutes” you’re doing yourself a disservice.

The moral of the story is this: If you find that there are many requirements factored into building a report, try breaking the requirements into discernible parts to see if these would make sense being their own report. Always and where possible, allow for breakdowns of a type of report to empower management with the information to make intelligent business decisions (e.g. – “How many sessions included a login attempt?”).

As one last aside, make sure that your requirements are actionable. If something is a “like to have” and not actually a “must have” then keep things simple and don’t include the requirement. If you can’t answer any business questions then don’t invest the development time and energy as these resources can be better spent on other actionable items.