Plain and simple, your web app sucks because it doesn't have good metrics. Now I'm not talking about code coverage or anything internal to your operation. I'm talking about summary statistics for the end users of the application relative to how they interact with it. My case is this, developers hold themselves up to a very high standard when developing their apps using frameworks like Test Driven Development (TDD) and Extreme Programming (XP). If you can take some of the philosophies from those frameworks, TDD and XP, and provide measures for your users, we'll see much happier users in the end who will reap large benefits from your application.

Why Metrics Make Sense

• Your Users' Standpoint:Why wouldn't users of your site want the same procedures that developers use to build quality sites?! Continuous feedback, communication, and simplicity. All three are values within XP and are targeted toward increasing productivity. By having a measure to gauge how you're doing, as a user, I can get more value out of using your application and react to any changing conditions.
• The web app owner's standpoint: Let's face it, the whole reason you're writing web apps is to get something back. Whether its money or a learning experience. Let's take the money side of that argument. Analytics and metrics can be a boon for your bottom line. Take Twitter for example. With recent articles floating on the web about it's new BizDev guy, Kevin Thau has said that they'll sell analytics to enterprises to make money. That's a lot of money to make to cover the cost of running Twitter.

General steps that you can take to generate good analytics for your data:

• Define your core user experience. The important part of defining the user experience is understanding the reason why they're using your service in the first place. Are they trying to manage projects, track their finances, or connect with friends? This part may take some research on your end because despite all of our best efforts sometimes the users of our web apps have totally different goals than what we expect. That being said, consider sending out surveys to a sample population of your users or analyze your Apache web logs for usage patterns. If you're still not sure where to start, try holding a focus group on Skype to at least get you going in the right direction for the surveys.
• When trying to summarize multiple observations, consider using nonaveraging metrics (maximums, variance, counts). According to recent research from Shugan and Mitra @ the University of Florida, they found that although averaging metrics may sound great theoretically (like sales per user, or cost per user), most uses of metrics (benchmarking, monitoring, allocating resources, diagnosing problems, etc) require that the metrics provide information (explained variance) about all of the outcomes that you're measuring. For example, a simple count of the number of new products from a company might convey information about a firm's ability to innovate.
• Keep the number of metrics relevant and to a minimum. Although I'm advocating for including some type of metric within your application, I also want to caution against providing too many. A danger exists whereby you can give your users too much information. Users can spend too much time trying to absorb everything that you're throwing at them instead of getting what they need and then reacting to it. Another part of that argument is that the information needs to be relevant, which goes back to defining your core user experience. For example, if I had a project management application, a metric to track how many times all of the people on the team logged into the application is not really a useful statistic when you're trying to finish a project. For further reading on this point, check out Russell Ackoff's article about "Management Information Systems." It's an old article, but still relevant to this day.

If you have an opinion on this subject, I'd love to hear about it! Leave a comment.