Filed under: Web Analytics Business Process | Tags: business continuity, data availability, data backup, disaster recovery, SLA, web analytics, web metrics
From the moment that your company start doing some serious web analytics, it will become more and more dependent on WA information. And that has some profound consequences:
- your role will become more and more steering and in time you will giving feedback on online strategy proposals
- the company will become more dependent on you and your job
- trended numbers and comparisons with the past will gain in importance
- data safety becomes a crucial issue, but is mostly overlooked
- permanent data availability should be in the SLA that you have with your WA vendor
- continuity of the web analytics business process must be ensured
Data safety and availability
- Do you own your WA data?
- Is your data hosted by the vendor, or by you?
- Either way, are there frequent backups, and how long does it take to restore a backup?
- Is historical data preserved? If so, are very old data compressed or reduced in any way, or are they just as easily available as current data?
- Is 24/24 7/7 data availability guaranteed in your SLA? If not, what response times do you want to enforce with your vendor in case of data unavailability?
- And what if you switch vendors….
Business continuity
Imagine that, from one day to the next, you suddenly are unable to do web analytics:
- is there documentation describing WA business requirements per site?
- is there documentation describing the WA implementation per site (wich tags are placed where)?
- is there technical documentation describing per site in which wCMS templates for instance the tags are implemented, which include files are all involved, where the .js master file is stored and who has the rights to update it?
- is that documentation up to date?
- is there a changes log per website? (when you see sudden differences in historic data, can someone still tell you what changes where exactly deployed at that time in the past?)
- does the changes log include screenshots, before and after (a usability evolution analysis is useless without)
The keywords here are per site and up to date.
Filed under: Uncategorized | Tags: bounce rate, entry rate, exit rate, single access visit, weighed bounce rate
Every visit starts with an entry page and ends with an exit page. I’m sure you knew that!
But do you know how well your entry pages are performing in luring visitors deeper into the site? A good metric for this is “Bounce Rate” (“Page Stickiness” is a related metric):
- Bounce Rate = [Single Access Visits to this Page]/[Entries for this Page]
- Page Stickiness = 1 – [Bounce Rate]
As with all page metrics, it’s wise to introduce a weighed variant of the metric. This allows you to focus on the pages with a bad value for the KPI and a high volume: obviously these pages are costing you the most visitors in absolute numbers. “Weighed Bounce Rate” then becomes:
Weighed Bounce Rate = [Bounce Rate] x [Entries for this Page]/[Total Entries] = [Single Access Visits to this Page]/[Entries for this Page] x [Entries for this Page]/[Total Entries] and thus
Weighed Bounce Rate = [Single Access Visits to this Page] / [Total Entries]
You can apply the same logic for exit pages. But beware that single access pages are by definition also exit pages, so you might want to exclude them from your analysis to get real exit pages.
Despite the advances in web technology, good old Nietzsche has always know what good usability is about:
“To predict the behavior of ordinary people in advance, you only have to assume that they will always try to escape a disagreeable situation with the smallest possible expenditure of intelligence.”
Friedrich Nietzsche (1844 – 1900)”
Filed under: WA Intelligence | Tags: belgium, browsers, distribution, firefox, google chrome, internet explorer, safari, web analytics
It’s not rare for IT developers to only develop for FireFox because it has so many nice developer plugins and tools. But that won’t help you if only 11% of your web site visitors uses Firefox3, will it?
Distribution for Belgium is (number are for first week of May 2009, and indicate % of website visitors):
- 56% IE7
- 21% IE6
- 11% FF3
- 5% IE8 (and growing fast)
- 1.5% MSN Explorer
- 1.4% Google Chrome
- 1.2% Safari 3.2.1
Don’t forget that this is the general distribution and that there is a difference between week and weekend: in the weekend (at home) people surf using more IE7 and FF3 than during the week (more IE6). So if your web visitors usually convert during the weekend (or at home), you’d better make sure that your online purchase dialogue works flawlessly in IE7 and FF3 as well.
Filed under: Product Comparisons
For those of you doubting between Google’s free Website Optimizer and Omniture’s Test and Target solution, here’s a table highlighting some of the differences between the two. Basically:
- if you only want simple A/B testing then use GWO;
- if you want to do MVT and have a high traffic volume website, consider GWO as well
- if you want MVG on a low traffic volume site, T&T is your only option
- if you want to run segmented tests, target content, segment reporting that is easily implemented and managed, go for T&T
| Google Website Optimizer | Omniture Test & Target | |
| Targeting to only % of visitors | O | |
| Targeting specific segments (browsers, returning visitors) | O | |
| Reusing tags | O | |
| On-the-page tests | O | |
| Whole page tests | O | O |
| Multipage tests (different steps in linked campaigns) | O | |
| Linking external test campaigns (ie emails) with internal ones | O | |
| Ajax or Flash support | O | |
| Easy QA environment | O | |
| Report segmentation | O | |
| Taguchi | O | |
| Conversion rate measurement | O | O |
| Revenu-based success metrics | O | |
| Onsite preview | O | O |
| Merchandising offers (..who bought, also bought) | (separate as Omniture Recommendations) | |
| Week vs Weekend tests and comparisons | O | |
| Data confidentiality | O | |
| Consultancy available? | O | O |
| Vendor consultancy available? | O | |
| SLA | O | |
| Integration with Omniture | O |
Integration with SiteCatalyst will additionally allow you to:
- reuse SC events as conversion events for your test
- reuse SC eVars for segmentation and targeting
- breakdown test results by eVars
Filed under: Best Tagging Practices
A very basic issue in all WA implementations is the completeness of the implementation. Sure: you browse your site, using checking tools like WASP, but what about all those pages that you DON’T browse? All the pages that people aren’t suppose to see?
Don’t be so naive as to think that your online audience won’t see them, ever. Oh no, if it’s on the net, people are bound to encounter it sometimes. Error pages might be hard to come by, but you don’t want them messing with your visitors, do you?
For error pages residing within your wCMS, it shouldn’t be too hard to convince your administrator to create (static) tags for each individual page. Try squeezing as much info as possible in those tags: any info about the origin of the error is best captured in an extra variable or property. Try categorizing this info to avoid an abundance of different error messages clouding your stats.
For “technical” error pages that are not managed in your wCMS, but just reside on your server, kindly talk to your IT colleagues to do the tagging for you. It are primarily these pages that never make it to your WA suite, so it might seem that all your online visitors are happily browsing, but you might be missing out on a huge chunk of frustrated surfers getting stuck on a 404 page as an untagged entry page…But you’ll never know without proper tagging.
It’s the basic rule of statistics: the data only tells you about the population you sampled.
