This post is one in a series where I slowly assemble a Maven workflow for large javascript projects. If you came here via google, I recommend starting at the beginning: Designing a Javascript Maven Plugin. Alternatively, you can just go directly to the js-maven-plugin project on github. Since there’s no sense in rebuilding something that [...]

With the release of Google Chrome last week many of our (and  your) clients are starting to wonder exactly what Google’s entry into the  browser market means. The release of any new software package, especially by a powerhouse  like Google, can often have broad and far reaching impact, and everyone wants  to be forewarned about what’s coming down the pike.

Two years ago, my colleague Isaac went to SXSW, and came back with a presentation on Mobile Development. In it he said that one of the greatest challenges is getting a mobile application “on deck”. “On Deck” is the term used for an application that’s available on a provider’s mobile platform, that place you goto online when you browse applications, ringtones and such, and to get something on there used to take an Act of God. Why? Because all billing had to be handled through the provider, all sales had to be done though your phone bill, and payments to third party companies had to be set up through their system (and usually required a hefty premium). In short- more trouble than it’s worth. Fact is, this is largely still the case. Yes, with greater adoption of mobile web browsers these things are becoming a lot easier, yet getting an application onto a phone remains problematic, especially if the consumer isn’t aware that you have it. The best option these days seems to be building a Mobile website, which is a far cry from a good user experience.

A few years ago I took what must have been one of the most entertaining courses of my graduate career: Business Game Theory. It was run using the Harvard Case method, but with no supporting textbook and no explanatory lectures before a case was assigned- we simply received a problem and were expected to solve it by the next lecture. The problems themselves were simple: we were given a situation and asked a fairly straightforward question. Should Company B enter a particular market, how will a competition play out, can you predict the next step in a competition given certain parameters, things like that. Most of us got the first problems blatantly wrong- the tacit requirement to do our own research didn’t sink in until after the first discussion- yet after that reality check it became one of the most engaging classes ever: The problems were challenging but not beyond rational analysis, and though I spent hours at a time bending my brain around decision making in a risky environment and other situations, I can still name the topics and methodologies for every case.

As a result I was practically giddy when I recognized a real world example of Judo Economics, a situation where a player uses the strength of their opponent against them. Consider a simple case: There exist two markets for a single product and two companies that can produce said product. The first market is large, however serving it comes with a high cost and therefore a low margin. The second market is small, but serving it is cheap and therefore comes with a high margin. The first of the companies must serve both markets, has deep pockets, while the second is considering market entry, but can only serve one of the two. Each company can only set one price against both markets. The question posed is: What will happen?

Web analytics is a way in which individual visitor action can be easily tracked within a site, and the aggregate statistical data derived from this can often lend remarkable insights into the effectiveness of your design, how ‘sticky’ your content is, and what your users are actually looking for. Unfortunately, extending this paradigm into flash has always been tricky, because it doesn’t adhere to the page-based paradigm on which most Analytics packages are built. Once a flash application or widget is loaded, the server loses most knowledge about what the user is actually doing within it.

Usually this isn’t really a problem- flash applications have not been too complex and not many people care where on the banner you clicked, just that you left the site as a result. Yet now with the strong growth of Flex and Ajax our web applications are becoming more and more complex, and marketers and usability experts are now demanding this tracking data in spite of the paradigm limitations.

If you really think about it, what we really are interested in tracking is a user action, rather than the page loads we are collecting right now, which means that the largest part of an analysts job is turning these page events into meaningful user actions, rather than interpreting those users. There’s been some attempt to set metrics to individual places within a page flow, yet nobody has yet thought to rethink the paradigm. But I digress…

Most Metrics providers have since opened their API’s enough to allow a developer to pretend like a new page refresh has occurred. While this is hardly optimal, it does allow us to track user events from inside of flash, but the fact that each provider has implemented their API a different way means that implementing metrics for each is still a string of unique problems to solve.

To that end I’ve written the Metrics package, which is intended to provide a common metrics proxy that any developer may use, which relies on a common library of connectors that can be swapped out as needed. In this article I go over the details of how to use it, and touch on how individual connectors might be written.

The Metrics package was designed to provide a simple, reusable, extensible and flexible interface to any web metrics package, including Google Analytics, Urchin, Omniture, WebTrends and more. It supports multiple connector management, instantiating only those registered connecters that are successful at autodetecting their environment. If a developer does not know in advance which metrics package his client is using (or whether his client might change his mind at a later time), he may safely add several connectors secure in the knowledge that the package will do the heavy lifting. Additional functionality allows you to “hot-swap” connectors should that become necessary, though I myself don’t exactly know why you’d want to do that.

At this point in time, the only connector published with this library is the UrchinConnector. Google Analytics and WebTrends will follow shortly, however due to my employers’ client agreements I find it prudent to not release connectors for API’s that are considered proprietary (such as Omniture) unless I have a formal letter granting me legal permission to do so.