Julie Craig from Enterprise Management Associates published a very interesting article entitled “The End-to-End Challenge“. In this article, she reveals some disturbing statistics, among which were the following (I am paraphrasing here):

Gartner released their June 2008 version of their venerable “Magic Quadrant” ranking for E-Recruitment Software.

Six of the eight leaders are already Coradiant customers.

This is a clear indication that leaders in this burgeoning field are taking End-User Experience Management seriously.

Coradiant is consistently chosen by leaders in online HR and in a number of other industries whose business relies on web applications.

With Coradiant TrueSight, businesses know how they are treating every single one of their web visitors, whether they are a small business interfacing with a few high valued users or a large enterprise interacting with hundreds of individuals online every second.

Leaders in E-recruitment software and HR Software-as-a-Service businesses are all focused on providing a high-quality end user experience. And Coradiant is the overwhelming choice among the leaders for End User Experience Management. Gartner ranked leading vendors on the completeness of their model and on their ability to execute.

Copies of Gartner’s E-Recruitment Software Magic Quadrant report are available from Gartner, Inc. (www.gartner.com).   

The holy grail of web monitoring – whether for real user experience or web analytics or any other purpose – is to be able to reliably recognize users.  You can only accomplish this goal by inspecting the traffic itself.   However, as I pointed out in a previous posting, you will always be as blind as your own applications.

Naturally, applications will only inject such identifiers when they are interested in identifying the user in some fashion.  Not all of them are.  Moreover, due to the undisciplined nature of web development, some of them are horrendously inconsistent in their intentions.There are really three levels of user awareness:

• Identity: an application is identity-aware if they require the user to authenticate themselves in some fashion.  This is typical of on-line banking, insurance sites, etc.
• User: an application is user-aware if they track the user’s session but cannot actually identify the user.  For example, most on-line stores allow anonymous users to buy items from a catalog, requiring a session state so that the site can remember the contents of the shopping cart.
• Anonymous: these applications do not track the user specifically and they do not place anything in the unique in the traffic.

Most sites that are interested in tracking users believe that they are either identity-aware or user-aware.  In fact this is frequently not the case.  Some applications appear to be user-aware because they use cookies to remember preferences or state.  However, none of those cookies are unique to a given user, so those applications are actually entirely anonymous.  Most other sites are at least partially anonymous, failing to place anything unique in the traffic unless absolutely required.  Thus, users are allowed to remain anonymous through large sections of those sites, only becoming traceable when they enter a transaction or log into the application.

Anonymous users cannot be tracked.  The HTTP protocol does not do it natively and the evolution of the internet is only making that more apparent.  If you are allowing traffic to be anonymous, then you must either accept that you cannot track that traffic reliably (you can make reasonable attempts using things like the client IP, but it will be seriously flawed) or you must alter your applications to build in the level of awareness that you need.

The Web Analytics industry is in the midst of a debate about how to identify and count Unique Users.  Some people are starting to suggest that we should abandon the idea of Unique Users in favor of counting something easier.  At the heart of that debate is the question of whether we will ever be able to uniquely identify users on the web.
 

Surely I can trust the client IP?

The problems with the client IP have been public knowledge for a long time.  This is an excerpt from a tutorial about Web Analytics, published by Summary.net (a log analysis tool) back in 2002:
“The majority of Internet users connect through dial-up services of some kind. In order to preserve IP numbers (there are a limited number available right now), the dial-up providers will assign each user a number when he connects and then reuse the number when he is done with it. So a dial-up service may have 100 IP numbers that they select from and use to serve 2000 users. This gets even more complicated with caches and proxies that many providers now use to improve performance …”
With the introduction of mega-proxies (like AOL), this problem gets even worse.  Mega-proxies will spray their traffic across multiple gateways.  Since the internet was designed to treat each hit as a stand-alone transaction, this means that every request making up a single page can be routed through a different client IP and port.  So, instead of a one-to-many relationship between the IP and the users, we have a many-to-many relationship.
Entities like corporate firewalls are rendering the client IP extremely weak and unreliable as a user identifier.  Mega-proxies completely destroy its reliability.
 

What about the user agent?

A lot of people choose to set aside the concern about mega-proxies and talk about combining the user agent with the client IP as a differentiator.  The problem with this is that there are a finite number of user agents in the world.  Admittedly, they number in the thousands.  However, these user agents are shared by millions of web users, which means that tons of users are being represented by the same user agents.  In fact, this understates the problem since most people are running the same browsers and plugins on the same basic operating systems, reducing the pool of popular user agents.  Combining IP and user agent will still result in users that are sharing the same combination.
If you are expecting to use this as a means for identity tracking – as in “this is Bob” – then you are going to be disappointed.  Since the user agent contains information about the browser and the OS, it can easily mutate over time as users upgrade their browser, download plugins, install service packs, etc.  Moreover, users are not limited to one browser – I use Firefox but am occasionally forced to use IE on specific sites – or one system.  I surf from my laptop, my wife’s computer and my iPod, so I’m using three different platforms as well as three different browsers.
 

Enter the plugin

At this point, you may be thinking that the user agent will at least improve your odds.  This would be true if it weren’t for plugins.  Plugins within a browser are allowed to request their own resources from the server.  When they do so, they send a user agent and it does not have to be the same one used by the browser.  The Java plugin is a classic example.
 

Grab your bootstraps and pull

This problem – as with all others – begins at home.  If you want to track users, do not expect the HTTP protocol to help you.  It was originally designed for anonymous traffic.  Deploy your own tracking IDs that are tailored to your needs.  Most web servers have mastered the art of injecting user awareness into the traffic (via cookies or URL-rewriting).  If you need identity awareness, then you need to take the next step and have your developers build that into your application.
There is no magic bullet.  You need to solve this problem for yourself.