Imagine my surprise when I fired up Stephane Hamel’s WASP Firefox Add-in and browsed over to http://sas.com.  It turns out that they are using Google Analytics on their site.  How ironic.

As good as Google Analytics is, I couldn’t imagine any other analytics provider endorsing the competition this way.  Omniture has four tags on its site, all from Omniture.  Webtrends has five Web Trends tags plus Quantcast (strange, but understandable) — at least they don’t have Google Analytics.  Coremetrics uses (you guessed it) Coremetrics.

Oddly enough, WASP did not detect SAS using their own tool.  Now in fairness, I doubt WASP detects SAS, but, nonetheless, this looks pretty bad for SAS.  Maybe SAS is simply engaging in competitive research.  Can anyone shed some light on this?

I asked our Marketing Director, Juan Ribero, to give me his input on the subject and here is what he wrote:

Everybody likes a fast car. I’ve never heard a single person utter the words, “I wish my car was slower.” The problem is that just because a car is fast does not mean we’re willing to deal with anything less than the utmost comfort and luxury. Only the most dedicated automotive enthusiasts would deal with a daily-driver that had no air conditioning or power windows simply because it was able to move down the road quicker than others.

Analogously, everybody wants their website to be really fast but few people are willing to give up on having items such as analytics tracking codes, personalization, rich media, numerous images, etc… At CableOrganizer.com we’ve spent a lot of time and money making sure that we provide the most useful information and content to our potential customers in the way that is preferable to them. The problem is that because our customers are a particularly savvy group and our products particularly complex, this has resulted in our pages having A LOT of content and this affected our website speed. People facing problems like this essentially have two options:

1. Look for a middle path balance by eliminating just enough content to ensure that their website is fast enough.
2. Invest in website optimization and content delivery to ensure that they could maintain the same amount of content while improving the speed of our website.

Since we were/are facing the dilemma of always wanting our site to be faster and had already dived headlong into the second option, we had to know exactly how much more money we would make (if there was a difference at all) from a faster website and how much we could be losing if our site slowed down for whatever reason. That way, we would know exactly how much resources we could devote towards speeding up the site and find out once and for all if services such as Akamai were worth the expense.

We used Tealeaf to find this information but SAS has this functionality as well and I’m sure something can be rigged up with Google Analytics partially using the Event Tracking functionality like the people at Panalysis. http://www.panalysis.com/tracking-webpage-load-times.php

First thing we did to figure this out was to use Tealeaf in order to make events based upon the load time on the client side (this is out of the box once you install Tealeaf’s Javascript SDK). We made sure to get really granular assuming that a 0.25 second difference was significant. We went from less than ¼ second to over 20 seconds.

We let the data build up for a month (getting over 200 sales a day so that a month was enough for statistical significance).  We then segmented all of our sessions looking at load time averages with the stipulation that no maximum load time was ever more than 3 seconds above the average. We made the assumption that if somebody had an average load time of 0.5 seconds (very fast by most standards) but took 15 seconds loading a single page (usually indicative of a major problem) then their session behavior would be contaminated by that anomaly and it would not be indicative of other customers with sessions of that average speed.

We then analyzed each segment and saw what percentage of each segment actually purchased. These load-time derived conversion rates were quite telling. We found out that users who averaged less than 1 second of loading per page without any significant deviations throughout the session converted at a much higher percentage than those who took an average of 2 seconds. Although intuitively some would be inclined to say that the difference is slight between a second and two, our data proved that there was a statistically significant difference in conversion rate between those two numbers. As one would expect, the difference got more pronounced as the averages got higher and higher with the final extremities proving that our conversion rate for people who average a load time of 7 or 8 seconds was shameful (there may be other factors here like the fact that they’re mobile or dial up users abroad of course).

We were then able to see within these analyzed segments whether or not the average order value changed between those with low page load times and those with high load times and found that there was no consistent difference. This could be because some people interested in big orders would deal with a slow website whereas some business customers willing to make big orders would usually have faster connections and therefore lower load times (these are just my hypotheses.) I imagine that the data would have been a lot more telling regarding average order value if we had segmented it out by product type as naturally some of our impulse buys have a more elastic demand than those items to which we have the best pricing and/or are exclusive distributors. This would have been an interesting study to run but the further segmentation into product types may have diluted our numbers to the point of losing statistical significance so we judged it to be beyond the scope of this test.

As such, we accepted the lack of correlation between average order value and page load time for the time being and used our combined average order value to estimate how much more revenue we could generate on a monthly basis if we increased the speed of the website by an average of 1 second, 2 seconds, etc…  and how much we would lose if the site slowed down by those intervals.

We found that the increased revenue that would come on a monthly basis was significant enough (even for a 1 second difference that only affected 1/10 of the visitors) that revenue allocation to the optimization of the website could be done in a quite liberal way. If we had not already been using Akamai for years, it would have been very interesting to do the same report before and after their implementation to see not only how much they lowered the average load time but exactly what their ROI is. Nonetheless, given the fact that most CDN services are relatively affordable, they would have to be really ineffective in order to not be a cost effective model for increasing revenue.

• Today
• Dashboard
• Visitors
• Traffic
• Content
• E-commerce
• Site Search
• Event Tracking
• Goals

• Visitor Loyalty
• Visitor Recency
• Length of Visit
• Depth of Visit
• Languages
• Browsers
• Operating Systems
• Browsers and OS

• All Traffic Sources
• Referring Sites
• Search Engines
• Keywords
• Non-Paid Keywords
• Paid Keywords
• AdWords Campaigns
• Campaigns
• Ad Versions

• Top Content
• Content by Title
• Top Landing Pages
• Top Exit Pages

• Products
• SKUs
• Categories
• Transactions

• Search Terms
• Start Pages
• Destination Pages
• Categories

• Categories
• Actions
• Labels

Wow, Google Analytics is simply a nuisance?  Coremetrics is simply a nuisance?  I did a little Google search for “Web Analytics Company” and guess what.  Omniture was not at the top.  In fact, Coremetrics is in position #5 and Omniture is in position #7.  So I went over to compete.com to look at the two websites.  Click here for the results.  As you can see, Coremetrics is nipping at Omniture’s heels.

In the conference call, Omniture has admitted that growth has slowed for them.  They reported that they added 200 new customers in the first quarter verses 250 for the first quarter of last year.  They now have 5,200 customers.  I looked back at their Q1 08 press release and noticed that they had 4,500 customers at the end of that quarter.  In their press releases since then, Omniture claims to have added over 950 customers so I estimate that they lost about 250 customers since last year.  It looks as if they were losing about 50 per quarter last year and that has accelerated to 100 per quarter this year.  Omniture said that many of their smaller customers were dropping off, but their larger customers were more stable. 

OK, I am aware that we are experiencing a global recession, but is Google Analytics slowing down?  By my estimation, Google Analytics is becoming the de facto standard these days.  I doubt that they are slowing down at all.  Maybe GA doesn’t do everything Omniture does, but it certainly does a lot and it does most of the important things.  Any analyst worth his weight in salt could use this tool to provide value for their company.

During these slow times, fast and nimble companies (usually smaller companies) make cost effective moves and use cost effective strategies.  Analytics is a much higher percentage of their operating expenses than it is for larger customers.  It’s no wonder smaller companies are abandoning Omniture for GA.  It only makes sense and I predict it will continue to occur.

According to their latest press release, Omniture lost $8.2 million in the first quarter and is saying they will lose $.09 per share in the next quarter.  If I were Omniture, I would not be so quick to dismiss my rivals.

I’ve written about this before, and I’ll say it again, I just don’t understand how that company could snatch defeat from the hands of victory.  They are a profitable company with a lot of great web properties.  A couple of years ago, Brad Garlinghouse wrote an internal memorandum labeled the “Peanut Butter Manifesto” that outlined the problems at Yahoo.  He noted that the company was spread too thin and recommended a management shakeup and layoffs.  It looks as if the brass at Yahoo paid attention.  Let’s hope it works.

All this data is readily available from most analytics applications, but I’m torn on where I should focus.  There’s the question of what is popular and then there is the question of what should be more popular.  As web analysts, our jobs are to improve things.  Yes, that’s right, we aren’t simply here to measure things.  We want to make them better for the enterprise that engages us.

I think the best way to do that is to focus on the low hanging fruit.  Where can I have the biggest impact for the least amount of effort.  So instead of focusing on what is your most popular product, you may be better served by looking at what should be more popular.  Fortunately for us in the analytics world, it’s relatively easy to compare products and their conversions.

You could start by looking at your conversion rate from the confirmation page to the completion of the order.  Then you could look at your rate from the cart addition to the payment screen.  Items that fail to make it down the funnel could have problems with their shipping rates or a poorly designed cart.  We’ve seen products with incorrect weights causing the shipping rate to skyrocket and lower our conversion rate.  Comparing conversion rates at this point is an easy way to spot freight problems.

Moving up the chain, you would expect to see a similar rate of cart additions to page views.  If a product has lots of page views but no cart additions, you could have a problem.  Are your prices too high?  Is it hard to find the “add to cart” button?  Are the images and descriptions clear?  Do the customers trust you?

Then you could look at bounce rates and page exits.  Both are important and I like to look at them mutually exclusively.  In other words, when I look at exit rates, I take out the bounces so that I only look at exits on navigation.

Finally, you could look at your advertising conversion rates and your SEO.  Is this page getting the click-throughs you were expecting.  If you do all this, you should start to see improvements pretty quickly.  I would suggest, however that you start with your highest potential items first.  Like most other places, 80% of your rewards will come from 20% of your efforts.  So try to find the 20% first.

Sure, one or two orders a day won’t be statistically significant, but the million dollar tests drive me nuts.  We only had $13MM in sales in all of 2008.  Test or no-test, Omniture dutifully reports every sale as if it were the real thing and records it for all of eternity.  Hmm, why did my revenue drop by 1,527% over last year?

But that’s not the only thing messing us up.  We also process catalogs through our website.  While we don’t charge anything for a catalog, we send our customers through the order entry system to process the order.  That way, we have all the info we need on the customer and can process it seamlessly through our order management system.  Is a zero dollar order really an order?  If so, it sure reduces my average order size.

Then we have Purchase Orders.  We deal a lot with the federal government and many educational institutions throughout the country and the world.  Their preferred method of purchasing is a PO.  These don’t get entered into the system like web orders.

Finally, there are the mistakes entered by customers and the occasional weird order from Nigeria.  The net result – our online revenue numbers make no sense.  The graph doesn’t make sense either.  In order for Omniture to show the million dollar days, it has to compress our regular sales to the bottom 5% of the graph.  It’s hardly enough space to detect any trends at all.

Is there a way to upload or edit Omniture and GA sales data?  If so, I’d love to hear about it.

The article states that both Nielsen Online and Comscore use panels to estimate traffic.  Then they go on to detail the problems with panels.  Next they talk about Quantcast who also uses panels to estimate the traffic on non “quantified” sites.  But the article praises Quantcast for its ability to tag certain sites that have been “quantified.”

Somehow, the author never seems to discover that some sites actually tag their own sites and use tools such as Omniture and Google Analytics.  Assuming the sites are tagged correctly, I think it is safe to assume that they will have more accurate counts of their traffic than either Nielsen, Comscore, or Quantcast.

So where’s the problem?  I think this is really a problem of third party verification.  Yes, the first party websites may know what their traffic is, but the second party advertisers want proof that their banners are being seen.  Therefore, the need for a third party such as Comscore comes into play.

Unfortunately, this article is so poorly written that one might imagine that there is no such thing as web analytics in this world.  Let’s spread the word.

The Wharton study pointed out several cases where goal setting resulted in disaster.  For instance, did you know that the Ford Pinto was a result of Lee Iacocca’s goal to produce a car weighing less than 2,000 pounds and under $2,000 to compete with the Japanese?  They achieved the goal, but eventually lost millions because of the safety problems associated with it.

Look at CitiCorp and Bank of America’s goals to become the largest banks in the country.  They have certainly become huge, but are both miserable failures.  The singular focus on the one goal of growth caused them to make risky, hasty decisions that the taxpayers of this country will end up paying for.  How’s that for goal setting?

Let’s look at Wall Street’s focus on quarterly earnings.  Do you really think this kind of goal setting helps a company in the long run?  Wharton found four basic problems with goals:

1. Goals that are too specific.  These goals encouraged workers to focus on the narrow goal rather than the broader good of the company.  In the analytics world, you may have the goal of doubling your conversion rate.  What’s the easiest way to do that?  Just add a log-in to your home page and only let your best customers enter.
2. Goals with unreasonable time frames.  For example, increase ad revenue by 50% in one quarter.  The problem with this is that you may be tempted to rob future periods of revenue to meet this quarter’s goal.  I once paid someone a bonus to increase my ad revenue on a content site.  They ended up doubling the advertising all over the site.  It worked for a little while until I had alienated all my loyal visitors.
3. Workers with high goals could end up taking huge risks to meet them.  Just take a look at the inappropriate risks that Citigroup, Bank of America and Wachovia took.  BOA bought Countrywide financial at the height of the sub-prime mess.
4. Unethical behaviour.  The obvious example here would be Enron who engaged in plenty of unlawful behaviour to meet their goals.  If you own or manage a website, you might be tempted to purchase links or try black hat optimization.

In the analytics world, we seem obsessed with numbers and goals.  Increase traffic, decrease bounce rate, increase conversion rates.  Yes, they all seem like good ideas, but each is fraught with dangers.  Rather than relying on goals, it may be a better idea to rely on your people.  Train them to do a good job and you may be surprised at the positive outcome.

First of all, what is a cookie?  It is simply a text file that a website can write to your browser’s cookie directory.  The file always follows this format: Name, Value, Host, Path, Secure, and expires.  Here’s an example of a cookie my site, cableorganizer.com, set on my computer by Google Analytics:

__utma
143129127.1911746407.1217860093.1220364684.1229437920.4
cableorganizer.com/
1600
1765752448
30121262
2012777344
29974411
*

The first line is the Name.  The second line is the Value.  The third line is the Host.  It is important to note that the host is the only website that can read this cookie.  Absent of some malicious exploit, one website can not see what another website has set.

The fourth line to the end represent the Path (directory), tells us whether the cookie is secure (meaning that the browser will only send it over a secure connection) and sets the expiration date.  Obviously these are coded so you can’t easily read them.

Cookies are incredibly useful things.  They allow a website to set information about your session that is unique to you.  For starters, they can allow a website to tell the difference between your session and someone else’s session.  You may be thinking, why of course they can do that, but the truth of the matter is that without cookies, there would be no practical way of differentiating you from someone else.  Imagine that you add something to your shopping cart and then someone else sees it added to their cart by mistake.  Sure, the cart could create a unique URL for that session, but what happens when you come back — your cart will be lost.

So what’s so harmful about cookies?  The answer is that cookies may contain private information and that private information could be exploited by third parties.  This can happen by one of two ways: 1) The cookies could be read in transit from your browser to the website’s servers.  This could happen through a virus on your computer or even some malicious code on your ISPs servers.  2) The cookie could be revealed through a cross site script. 

Both of these issues are rare, but they do happen.  And when they do happen, it is shocking and alarming.  We as human beings tend to zero in on the catastrophic rather than the common.  We ignore the 60,000 people killed each year in auto accidents to focus on the 150 people killed in one airline accident in 8 years.  That’s simply human nature.

The media loves hype and FUD.  Some of the common myths surrounding cookies are that they are like viruses.  People believe that they cause popups, are used by advertisers to unfairly target you and send you spam.  None of these things are true.  But some companies have a financial interest in scaring you.  They will sell you software to eliminate cookies.  The only way to get you to buy their software is to scare you into fearing them.

So how do we fight this?  We fight it with knowledge.  It’s time to stop fearing the cookie.