Web Analytics Blog
Friday, January 23, 2009
  User Tenure - How Long Do Your Users Remain Active on Your Site?
We define user tenure as the number of days a user remains engaged with our site. It's the length of time between initial registration and when the user becomes inactive. The difficulty is when do you define a user as inactive - after 30 days, 60 days 90 days of not logging in? Have the web analytics experts agreed a standard on this one? We tend to use 30 days but I have seen other companies go for 90. May be we are being too hard on oursleves and 30 days is too draconian a cut off.

I guess it will depend on the type of site - an ecommerce site is probably going to care less about tenure than a community/social networking site. On the other hand it depends on what they sell - I engage with Dell to replace my printer cartidge every 3 months - does this mean I have become inactive and will reappear as a new user. I doubt it - I am recognised as soon as I log back in. However, if I haven't been to my Facebook page for 3 months is it likely that I will return? When is the last time you went to a virtual world like Second Life? I can't even remember my user name so I guess I am inactive there. Could this be the definition I am looking for? If only I could tell when my users have forgotten their login details. How about when an email is permanently bounced?

That leads on to what you do with this information. If you know that as soon as somebody fails to log in for 3 months there is a very high chance they will never return. Then is there some marketing intervention (targetted email - not much use if the email is junk) that can be employed to re-activate these users and bring them back to the site. This could make an enourmous difference to site retention.

Labels: , , , ,

 
Thursday, January 22, 2009
  The Most Common Errors in Web Analytics

This extract is taken from Sem Angel and sums up the issues facing all web analyst experts so I had to quote it pretty much in full:

Going From a Theory of Error to a Web Analytics Process

Here are a few basic causes of error that I think drive the vast majority of problems in web analytics:

1. Self-Interested Measurement. This problem is hardly unique to web analytics. Many of the institutional practices of scientists and academics are designed to protect against the force of self-influence. Though this is sometimes portrayed as venal, it is even more commonly encountered as simple self-delusion – we all have the strong desire to find that whatever we currently believe is true.


2. Lack of Statistical Significance. Statisticians are generally, widely and rightly considered to be a royal pain in the rear. They are like gatekeepers who are constantly slamming the door in your face – usually with a snide remark to go along. They are only necessary because the rest of us are constantly and helplessly fooling ourselves into believing that a pattern is real because it “looks” real. Flip a coin ten times and there’s a pretty good chance you won’t get five heads and five tails. Just as detailed analysis of all these obscure variables turns up lots of opportunities for bad analysis, web analytics reporting will do the same. You are suddenly putting lots of information into everyone’s hands. If they aren’t protected from misusing it, I guarantee you that your company will soon be betting money on numbers that don’t mean a darn thing.


3. Unreliable data and what to do about it. Nothing can create a statistically significant finding faster than bad data. As every analyst knows, the first analysis pass is usually good for little more than identifying all of the interesting “facts” that turn out to be measurement artifacts. While my first two principles are completely common to every truth-seeking endeavor, number 3 is more pronounced in web analytics than in most disciplines. God knows that this isn’t because most disciplines have clean data to work with – ours is just unusually bad. The problem has been compounded by the prevalent and thoroughly misguided idea that “trending the data” somehow protects against data quality issues.


4. Siloed Optimization. Large organizations tend to create a special class of measurement issues by creating silos of measurement that focus on single issues like organic search optimization or multivariate testing. This inevitably leads to siloed optimization where the incentive to local optimization cannibalizes success in other parts of the organization. This is a shockingly common problem and it’s an unusual one because it tends to be worst in the most sophisticated companies.


5. Metric Monomania. We see a metric move and we know it’s supposed to be actionable. So we want to do something about it. But, as I’ve argued for years now, the movement in a single metric is pretty much NEVER actionable. It doesn’t matter whether it’s a KPI or even a really good KPI. In the real world, KPIs are nearly always interrelated into systems – meaning that changes in one variable are nearly always driven by changes in other variables. Unless you understand the system you don’t understand the true significance of any given change in a metric.


6. Tactical Focus. For most analysts, tactics come much easier than strategy. Analysis of data nearly always drives plenty of micro-changes that might make a web site better. But the best uses of data are often in completely unrelated problems and contexts that have nothing to do with immediate tactical problems. You can try forty different variations of a drive to registration, tweaking everything from button color to offer text.

And this is the important bit:

But registration rates will always be crappy if you don’t give your customers a really good reason to register.

You can micro-analyze your data with powerful statistical tools, but the biggest learnings may require nothing more than looking at your overall traffic numbers.

If you build your measurement processes to deal with these six problems, you’ll have protected yourself from a heavy majority of web analytics errors.

Labels: , , ,

 
Wednesday, January 07, 2009
  Whats Your PayPal Completion Rate?
I am currently working with a client who use PayPal as their payment service provider. God I hate 3rd party PSPs. - don't they make life difficult? We've been tracking shopping cart abandonment over time but have been unable to set up a full conversion funnel analysis because only a very small proportion of purchasers click the return button on the payment successful page with in the PayPal domain and return to the site.

We had suspicions that the shopping cart abandonment rate was much higher than the industry average - Fireclick estimate this to be between 66 and 82%. But couldn't get a handle on what was happening on the PayPal payment page itself. Searching for "PayPal abandonment rates" on Google failed to come up with any useful figures. Does anybody else have estimates? PayPal aren't saying.

To begin payment on the site shoppers must click on a "buy now" button (Flash) which takes them to the payment page. We obviously know the number of completed purchses. So we could have used Google's Analytics New Flash Tracking to count the number of times users clicked on Buy Now. Luckily before I got the developers to do this somebody discovered that the back office system tracked all transactions started as well as completed - presumably as the system needs to pass on order details to PayPal. So in the end it was easy - PayPal abandonment is simply the percentage difference between the number of started transactions and the number of completed transactions.

In fact our PayPal Completion Rate was very close to the Fireclick Average for Fashion & Apparel average of between 18 and 32%.

Labels: , , , ,

 
Increase the sales and profits of your business by improving the performance of your website in support of your business objectives. Web analytics allows you to measure and therefore improve the performance of your website. Find out how by reading the JU2 analytics blog.

Archives
April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / October 2006 / March 2007 / April 2007 / August 2007 / September 2007 / December 2007 / February 2008 / October 2008 / November 2008 / January 2009 /


Powered by Blogger

Subscribe to
Posts [Atom]