Web analytics packages, Google, Coremetrics, Omniture - they all come with a price, performance. Websites make money by being the easiest to find and the fastest to load. Let's look at the second half of that statement.
Clearly there is value in tracking and reporting usage data. Without this information, including return visitor metrics, determining KPI improvement for any change in marketing, content, user interface, features or technology would be incredibly difficult.
In the beginning of the web, server-side log analysis was the only means available. Applications like Urchin and WebTrends improved upon this in the early 2000's with more sophisticated reporting and additional dimensions of data collection. Ecommerce was still not fully reported on until later in the decade with Coremetrics and Google's Analytics providing additional tools like goal funnels, real time reporting and cross domain capabilities. However much of this became tangled up with Javascript implementations to allow for SaaS rather than server-side logging and desktop applications for reporting.
Javascript embedded in the page is the devil in the details of how analytics tagging/tracking can impact site performance. Back in the early 2000's when Javascript tagging became popular, it was one of the few scripts running on any page with any rich media being handled by Flash primarily. Now in the present day, this is no longer the case. Many sites now run on little else but Javascript and as a result tracking scripts are slowing down those sites with 3rd party requests and latency and filling up the global namespace with objects which creates a larger memory footprint and slows down all other scripts in use.
There are ways to mitigate the impact. You can use asynchronous loading which is standard for GA (Google Analytics) now but not necessarily for other packages like Coremetrics (not sure about Omniture, it's been a few years since I've had to do an implementation). This works somewhat. You no longer have the script itself blocking requests or loading of content directly. However as these scripts still use an image pixel as a beacon to send data back to the reporting system and that image is being loaded dynamically, it is still blocking the page from loading (and kicking off the oh so important onload event) and depending on your connection latency, this could be as much as a second of unnecessary overhead.
So, what else is there? We've covered server side, which is still valid but is out of favor at the moment, so good luck finding support, not to mention that it is tricky when you have a load balanced system or worse a completely virtual system in the cloud. Imagine running your site off of Amazon or even just a hosted Wordpress blog - you're just not going to be getting any server logs to work with. We've covered javascript based systems and all the trade-offs there. Now let's talk about the most interesting option to come around in the last few years... packet sniffing.
You heard me, packet sniffing. It was hot in the 90s much like server log systems but of course it's come a long way since then. Back in the 90s it likely had little advantage over server logs and when javascript came along was an even harder sell due to the hardware and software requirements over and above the webserver. Now, however the advantages are starting to look a lot more compelling. With built in support for AJAX, no need for elaborate tagging strategies to capture events that should just be a reporting dimension by default - capturing packet traffic and saving it for later analysis looks like a very good thing indeed.
A few of the vendors out there now:CloudMeter looks to be the company with the largest community and is the fastest growing business. Their PION product is a hardware appliance or an application on your own hardware, that sits behind the firewall and captures a copy (non-interfering) of all network traffic going to and from your webserver/appserver. This data is then analyzed based on matching rules using regular expressions or other logic to populate a database. You can of course add markup or really any kind of content to make the rules simple eg: var category = 'Watches'; - could be used to match against a rule looking for that meta data.
With packet sniffing you have no script loading or evaluating. No beacon pixel requests and their inherent latency issues (they still happen but the appliance sends out the request external to the website. Same can be done with affiliate tracking pixels). No complicated tagging logic to get content already on the page into a format suitable for sending back to the reporting tool unless you just want to make your matching rules easier. There are a few other advantages but they are only useful for niche applications so I'll leave that as an exercise for the reader (hint: one use is for applications with no front end!). Finally, PION is reporting tool agnostic. It can send data to Google or Coremetrics or Omniture using their standard methods (beacon calls) or an in-house reporting tool like Crystal Reports - it also has a built in reporting tool.
What do you think, has packet sniffing come back around as the new killer analytics solution?