 |
 |
 |
|
11.11.09 Addressing Issues That Plague Web Application Measurements  By Gary AngelOnline Applications and highly-interactive web sites written in full-on programming languages are becoming the norm on the web, not the rare exception. Measuring these applications is challenging for a whole host of reasons. In my last post, I talked about the importance of automated testing to bring measurement fully into the application development life-cycle. In today's post, I'm going to cover an issue that plagues application measurement, video and most other rich media measurement – how to balance cost vs. coverage when it comes to measurement. The problem of cost in measurement springs from our basic model. With SaaS implementations, each server call you make to your measurement system costs money. Not a lot of money, of course. And for web sites, there has been little doubt that the knowledge gained from page measurement more than offsets the per-page cost of collection. On most web sites, a typical visitor might view six to ten pages. A really engaged visitor might view twenty to thirty pages. In an online application, however, the number of user interactions (every click, zoom, and setting) can be much, much higher. Without a clear paradigm for a unit of measurement (such as a page view), it's unclear which of these interactions should be measured. Capture every one, and you'll likely find that the cost of measurement outweighs the benefit. As I mentioned, we've seen similar issues with video measurement. Many of our media clients went from measuring almost nothing about video to detailed measurement of how far viewers penetrated into each and every visitor played. But to get that measurement, they usually had to make multiple server calls per video – sometimes as often as every 10 seconds. For a 2 minute video, that means a full-play results in 12 server calls. That's a lot of measurement expense relative to the value of tracking abandonment per 10 second interval. In fact, a lot of that more detailed measurement ended up getting pulled. We've seen similar pull-backs when clients over-measured flash experiences – tracking roll-overs for example. After awhile, most companies find they aren't using that level of detail about user interactions very effectively and the cost of measurement isn't justified. In an earlier post, I described a framework for measuring applications that included four core concepts: units-of-work, application state, rest-states, and performance. Part of the reason I settled on these concepts is that they provide a reasonable balance of measurement vs. cost. A unit-of-work is a function within the application. The unit-of-work would typically encapsulate a single use-case (like getting driving directions for a mapping program or paying a bill in an online bill-pay system). The measurement system would make a call whenever a unit-of-work is initiated. With this call (and all calls) it would pass an application state. The application state is a set of variables that capture all the important settings a user might have (like sort-order, filters, zoom level, tab open, etc.). The goal of application states was to be able to tie application settings to important actions (units-of-work) without having to pass measurement calls every time a state is changed (like a sort). Now I'm going to add a new concept – milestones. Milestones would be way-markers within units-of-work. A milestone could be named and sequenced if desired. Whenever a milestone within a unit-of-work occurs, the measurement system would fire off a call. Every unit-of-work would have at least two associated milestones – an abandon milestone and a completion milestone. Using the milestone concept, developers could control how much measurement is being done within a unit-of-work. Continue reading this article. About the Author: Gary Angel is the author of the "SEMAngel blog - Web Analytics and Search Engine Marketing practices and perspectives from a 10-year experienced guru. |
||||||||
|
| ||
-- TheDevWeb is an iEntry, Inc. publication -- |
