Andy Beal of the Marketing Pilgrim has tagged me for a new blog tagging meme that has just started. Andy was sweet enough to play when I tagged him for the personally tag game so it is only fair that we play along for his game!
The 2007 Predictions tag game was started by Mashable. I think it is more dangerous than the personal blog tag game because in this one you actually have to come up with something intelligent (and one’s “performance” can be measured at the end of time!).
It took me six minutes to write this and I am sure it will have turned out to be a career limiting move! My 2007 predictions for our beloved Web Analytics universe:
- 2007 will be a banner year for Web Analytics education (books, blogs, seminars, conferences) and Web Analyst salary improvements (of course I have to say that!).
- We will see increasing sophistication of and availability of “free” web analytics tools in the market (welcome Microsoft Gatineau). This will be good for current vendors: more people to sell to and move up-market. This will be bad for current vendors: will have to create more obvious differentiators, than just number of reports.
- Pay Per Click (sometimes called SEM) analytics will continue to be important but cede mind-share and control to Search Engine Optimization analytics (which is in a rather sorry state in all current web analytics tools).
- WebTrends MarketingLab and Omniture’s Discover will release updated versions of their “data warehouses” that will be closer to (and hence more integrateable) standard business intelligence data warehouses (allowing us to do deeper and richer end-to-end analytics with other data in our companies).
[Important: I have no knowledge of either company’s product road-map.]
- More Analysts and Web Decision Makers will realize the futility of torturing clickstream data to get into the heads of their visitors and embrace qualitative measurement options (surveys, testing, usability and so on). No totally radical changes but steady progress towards the Trinity mindset.
One Bonus:
- More website business owners will realize there is this thing called Social Networks and panic when they can’t be measured. Rest assured, targeted solutions will follow in 2007.
In turn I’ll tag our esteemed world leader Mr. Peterson to offer up his top secret list of 2007 web analytics predictions (I am positive it will be super!).
Do you agree with the list above? Is it achievable? Is it too conservative? What trend does it ignore? Please share your own predictions via the comments field.
[Like this post? For more posts like this please click here.] 
Occasionally we revisit a well established / standard metrics or report and take a fresh look at it. The first metric we look at was Visitors (Visits, Unique Visitors). In the second one of the series we will look at a very standard metric Exit Rate and one specific report, Top Exit Pages.
All web analytics tools contain the Top Exit Pages report. In terms of mechanics the web analytics tool take the last page viewed in each visitor session and the report simply shows that pages that appear most frequently (by a raw count) as the last one in visitor sessions.
On paper this metric (remember it is different from bounce rate though some practitioners are confused about bounce rate for a page) is supposed to show “leakage” of your website: where do people exit from once they start their session. It should illustrate pages that you should “fix” to prevent “leakage” and get customers to buy more or sign up more or get deeper into the site or generally do what a website owner would have customers do.
Is it worth it?
For the most part you should not care about this metric, for most websites it tends to be a hyped up metric that tells you little while, on paper, claiming to tell you a lot. This is especially true if the report is at an aggregated level (as in the above screen-shot which shows top exit pages for All Visitors of the website). If you pause for a moment and imagine a typical customer experience on a website you’ll see that this is not telling you much, if anything at all.
Yet it does seems obvious that if you knew where people were exiting from on your website that you could simply fix that “page” and all would be kosher. In reality visitors come to your website for a whole bunch of purposes and it is often ok that your top exit page on the website is the page that shows your best selling product (it will be that page) because a big chunk of visitors want to read about the product and buy it in retail. Just as an example.
Another factor going against making this a valuable report is that the conversion rate for most website (e-commerce or otherwise) is around 2%. That means approximately 98% of the traffic will exit at places you don’t want them to exit (examples of good places to exit: checkout page or lead submission page or a support faq page). When such a huge amount of traffic is exiting (leaking) from your website, and most likely from your most viewed pages, it is extremely difficult from the raw exit rates on those pages to parse out success or failure.
So if 50% of people who see your product_details page exit, what percent of that is “good”, those that read reviews and will buy some place else like a retail store, and what percent is “bad”, those who came to buy and you upset them with tiny six size font on that page? How do you know from simply the exit rate number?
It is often, not always (see exceptions below), a futile exercise and you are better off at using other mechanisms (for example surveys or Usability) to figure out why people exit your site at different locations.
Is it ever worth it?
As always there are exceptions to the rule, atleast two in this case…..
1) Segmenting this report for various traffic streams or campaigns or customer types can redeem it a little bit and potentially highlight trends that might shed some insights. If you get micro nuanced enough in your clickstream to focus on a small group of visitors whose Primary Purpose on the website would be obvious through clickstream data then this report can be of some use. (And only because in such micro nuanced detail it is knowing intent that makes the difference.)
2) The only solid exception to the rule are structured experiences that are of a “closed nature”. For example the Cart and Checkout experience. You add to cart, you click start checkout, you fill out your address and credit cart, you hit submit and see the thank you page. In this structured experience it can be insightful to measure which page is the top exit page and why might that page causing “leakage” and how to fix it (multivariate testing to the rescue!).
Conclusion:
As a general matter of habit we should consider avoiding the aggregated top exit pages reports so easily available in our standard web analytics tools. More time to spend on other stuff that might be more valuable.
If you really do need to understand why customers exit from your websites then consider deploying other listening mechanisms that are available such as Surveys or other Qualitative Analysis options.
Your turn.
What do you think? Do you agree? Disagree? What’s missing from the above analysis? Have you found the top exit pages report to be valuable? Please share your critique and feedback via comments.
PS: If you have suggestions for other standard metrics or reports you would like addressed then please email me (blog at kaushik dot net) or leave a comment.
[Like this post? For more posts like this please click here.] 
There are many different options at our disposal when it comes to collecting web clickstream data. We can use web logs, web beacons, javascript tags and packet sniffers. Each methodology comes with its own unique set of benefits and challenges.
[Read this entry in wikipedia for pro's and con's of web logs and javascript tags, Dr. Stephen Turner has done a great job there. Aurélie's post and Juan's post have great insights into packet sniffing as a source of clickstream data.]
But if one takes a quick pulse of the Practitioner conversations around data capture it becomes clear very quickly that the largest number of current implementations (shear volume) use either web logs (usually due to history) or javascript tags (usually due to recent evolution of most vendors simply abandoning all other methods except this one).
The secondary level pulse is around people debating which of these two methodologies is “better” and hence which one should they be using. There are lots of conversations that outline benefits of one methodology or the other. There are even more technically nuanced geeky conversations by one party bashing the other.
What is missing is someone risking their neck and going out on a limb to make one recommendation when it comes to choosing web logs or javascript tags (assuming that you have ruled out the others). Never one to miss the opportunity take a unnecessary risk I’ll go out and make a recommendation:
You should use JavaScript tags as your weapon of choice when it comes to collecting data from your website.
The only assumption is that you don’t have a website that is so amazingly unique that there is no other website with a web serving platform on the planet like yours.
Here are four important reasons for picking a side (that has not hurt Fox News and I am hoping it won’t come back to bite me either, their slogan is: We Report. You Decide):
Separating Data Serving & Data Capture (gaining efficiency and speed):
With web logs data serving (web pages with data going out from your web servers upon user requests) is tied completely with data capture (as the web pages go out the server logs information about that in web log files). Every time you want a new piece of data you are tied to your IT organization and there ability and structure to respond to you. In most companies this is not a rapid response process.
With javascript tags data capture is separate from data serving. Web pages can go out from any where (from the company web server, from the visitors local cache or from a akamai type, or ISP, cache farm) and you will still collect data (page loads, javascript tag executes, data goes to server - asp or in-house).
The beauty of this is that the company IT department and website developers can do what they are supposed to do, serve pages, and the “Analytics department” and do what they are supposed to do, capture data. It also means that both parties gain flexibility in their own jobs, speaking selfishly this means the Analytics gals/guys can independently enhance code (which does not always have to be updated in tags on the page) to collect more data faster.
The reliance on IT will not go down to 0%, it will end up around 25%, but it is not 100% and that in of itself opens up so many options when it comes to data capture and processing.
Type and Size of Data:
Web logs were built for and exist to collect server activity, not business data. Over time we have enhanced them to collect more and more data and store it with some semblance of sanity to meet the needs to business decision makers. They still collect all the technical data as well as the business data (often from multiple web servers that support a single website each of whom has a log file that then needs to be “stitched back” to give the complete view of each user).
Javascript tags were developed to collect clickstream data for business analysis. In as much they are much more focused about what they do and only collect data that they need (though admittedly not all the javascript tags running around are smart and they do collect unnecessary data). What this means is that with javascript tags you have a much smaller amount of data to capture, store and process each night (or minute or hour or days) and it can be a much saner existence (logically, operationally and strategically).
Innovation:
For better or for worse most vendors are moving away from supporting versions of their products that support web logs as a source of data. Many only offer javascript tag (or packet sniffer) versions of their products. History will decide if this was a good thing but the practical implication of this is that most innovation that is happening in terms of sophistication of data capture, new ways of reporting or analyzing data, meeting the needs to Web 2.0 experiences etc are all happening in the javascript data capture environments.
This presents us with a stark choice of having to build and own our own company only customized means of capturing this new data and keeping pace with other innovations or relying the on the expertise that is out there (regardless of which Vendor you prefer) and keeping pace with all the innovation.
Often this is a easy choice to make of any company that considers its core competency to be to focus on its business and not developing web analytics solutions (though admittedly if you are Wal-Mart you can absolutely do that - for example they have invented their own database solution since nothing in the world can meet their size and scale).
Integration:
Increasingly we are heading towards doing a lot more measurement and customer experience analysis beyond just clickstream. Two great examples of this are experimentation and testing (especially multivariate testing) and personalization / behavior targeting. In both cases “add-on” solutions are tacked on to the website and testing / targeting happens. Often these solutions come with their own methods of collecting and analyzing data and measuring success.
But as we head for a integrated end to end view of the customer behavior, for optimal analysis, we have to find ways of integrating data from these add-ons into the standard clickstream data (else you are optimizing just for each add-on which is not a great thing).
Integrating with these add-on solutions (which often also use javascript tags and cookies and url identifiers) is significantly easier if you use javascript tags. It is easy to read cookies in web logs etc, but he pace at which you can integrate and the ease at which you can integrate is faster if you are using javascript tags.
It is important to point out that you should consider your choice in the context of your own unique needs. Please read carefully for detailed pros and cons of each data capture methodology (because javascript tagging does have important con’s that need to be considered carefully, web logs also have their benefits, including obvious ones like they are the only place your find search robot data).
In the end though if you have to make a choice between web logs and javascript tags and 1) you need some “advanced non-standard” considerations you should think through then they are above 2) if you want someone else to make the choice for you then it is above.
If you love Web Logs, what’s wrong with the recommendation above? If you swear by Packet Sniffing, is it superior to tags in the four ways outlined above? If you can’t live without JavaScript tags, what else is missing above? If are are confused and this helped, please share that via comments!!
[Like this post? For more posts like this please click here.] 
