Defining KPI's - Update

I thought a little bit more about how I described the process for defining KPIs - and I came to this realization...

While it is true that you have to know what your business objectives are in order to tie your web measurements into group-, division-, or company-wide goals, often times it's easier to start at number 3, Describe desired visitor behaviors, and work your way up (toward connection to management objectives), and down (toward KPIs and contextual data) from there. The end result is still the same - the ability to illustrate to management how what's happening on the web site is directly connected to the larger goals that management cares about.

Here's what that looks like applied to the top down approach described by Schiff in his post on KPIs.

Optimization Tip - The order of states in an address form

Checkout Jared Spool's post on this topic in his Brain Sparks blog. This is the type of minute detail that you have to focus on when you're optimizing business performance on your web site. This is especially relevant to retail (billing and shipping addresses) and retail banking and financial services (account applications).

If you want to achieve the greatest possible return from your investment in doing business online, leave no stone unturned when it comes to performance optimization. Seemingly small changes can add up to millions of incremental dollars annually. I know. I've seen it happen.

Measuring the Right Things [part 2] - Defining your KPIs

I've been thinking about this post for a few days now, trying to figure out just the right way to approach it. What's got me thinking about it is that I'm getting ready to engage with a new client to help them define a Key Performance Indicator framework they can use to enforce a more disciplined approach to site management within the organization. Additionally, they want a framework with which they can document the business value of the site to executive management.

Conceptually, defining KPIs is extremely simple...

1) Understand your Root Goal or Overarching Business Objective
2) Document the efforts you'll undertake or approaches you'll use to try to achieve those goals
3) Document the desired visitor behavior to result from your efforts
4) Express the ratio or data-point that lends insight into the scrutinized visitor behavior (this is a KPI)
5) State the individual measures that create the ratio or provided needed context to understand the KPI

What end up on your scorecard or dashboard is nos. 4 and 5. Numbers 1 through 3 you use to provide the overall business context when you write up your analysis of overall website performance for management.

Where most client-side analysts or site managers tend to fall down when deciding what to measure is failing to explicitly state and understand the Root Goal that 'efforts' and 'behaviors' are derivative of. Most of the time when I ask a client what their goals are they tell me about desired behaviors or eff0rts to affect behaviors, but they don't talk about the high-order objectives -- the Root Goal. As is true with any business, you need to understand your goals before you can understand your performance, or even what you need to measure to understand performance.

Here's an example of a fully defined KPI for a retail banking site:

1) Root Goal: Grow new account revenue 20%
2) Effort (or Approach or Method): Improve attach rate (cross sell performance)
3) Desired Visitor Behavior: Complete application with accessory products
4) KPI: % applications with accessory products
5) Contextual Data: # of applications, # of applications with accessories, AVG Revenue/Application (without attached accessory), AVG Revenue/Application (with attached accessory)

A colleague forwarded me this post from Craig Schiff while I was working on this post. In it, Craig does two things nicely (aside from being a smart guy): he provides a nice graphic illustrating the top-down definition of KPIs; and he clearly demonstrated to me how web analytics is just a little slice of BPM (Business Performance Management). We're working on exactly the same challenges, just on a different scale. The wording in his process is slightly different from mine, but they both get you to the same place.

Here's Craig's illustration:


One other note about Schiff's process -- I liked step 5 so much I included it in mine. I had not explicitly called out the needed contextual data separately. Instead, I was just including the contextual data as part of Step 4. It's much clearer when you call those out separately.