Using The Wrong Tracking Code Can Cost You $500k a Year

This is a guest post from Tom Critchlow who is an excel ninja, data geek, analytics nerd and head of search for Distilled, a London & Seattle based search agency. Tom provides a cautionary tale on the importance of keeping your site up to date.

This blog post title may appear sensational but I assure you that it's not (much...). I recently spotted an issue with a client's e-commerce website which was costing them £100,000 / month in revenue (~$150,000). The fix took 5 minutes. Even more surprisingly, since I've been on the lookout for this issue I've spotted it on quite a significant number of websites. Hence why I got in touch with the Google guys and asked if I could talk about this in front of as many people as possible to try and spread awareness!

1) Graph of Win

Firstly, let's take a quick look at a pretty graph. This is comparing revenue month on month before and after the fix was made:

Note the increased revenue! :-) Everyone loves increased revenue. For those with beady eyes you will have spotted that this isn't total revenue on the site but it's just IE8 users. What's going on here?

2) The Issue

Before I delve into the issue, let me first give you a little background. When you enter private information online, such as your credit card details, you want to be sure that you're transmitting the information over a secure connection. You can usually tell you're on a secure connection to a website if the page URL begins with https:// instead of http://

Making webpages secure, however, is more resource intensive and so most websites only make their most important pages secure (though Gmail now always uses https:// by default). This means that when you browse a website, for example http://www.amazon.com you will browse around product pages which are all located on http:// URLs. When you want to actually purchase something from the site however you transition over to secure URLs such as https://www.amazon.co.uk/gp/cart/view.html

This is standard practice for e-commerce websites and when you move through the buying funnel you should inevitably transition at some point from a non-secure page (http://) to a secure page (https://).

Now, the issue I'm talking about in this post is with the client's site. The site uses Google Analytics however unfortunately they were using the old version of the code and were using the same piece of code across all pages of their site. The code they were using looked a little like this:

Unfortunately, this means that their secure checkout pages such as https://www.example.com/checkout/payment contained non-secure elements - namely the URL call to "http://www.google-analytics.com/urchin.js". Browsers like Chrome and Firefox don't display a warning but Internet Explorer 8 produced the following security warning when users transitioned from the non-secure (http://) pages to the secure (https://) pages. This error looks like this:

Pretty scary huh! Unsurprisingly this was causing almost all users browsing in Internet Explorer 8 to abandon the shopping process. Since Internet Explorer 8 is one of the most popular browsers on the web this was a huge amount of revenue they were missing out on!

3) How To Fix It

This issue arose because of a non-secure HTTP call within a very old version of the Google Analytics tracking code. The fix for this is very simple - just install the new code! The new code is more versatile than the old code and works both on http:// pages and https:// pages so you don't need to worry about using a different code on secure and non-secure pages. The new code looks a little like this:

There's a complete run-through here on using this new code here and specific migration advice.

And that's it! It's a simple fix but one that can have significant impact on your bottom line. I repeat what I said at the top of the post - I've seen plenty of sites that suffer from this issue so it's really not as rare as you might think!

I should point out here that the Google Analytics code has been able to handle HTTPS and HTTP pages properly since well before the asynchronous code was released, but plenty of sites are still using very old legacy code, which is why this is still an issue for some sites. Also, it's not just the Google Analytics code which can cause problems! Any non-secure elements on a page can cause a security warning so double check your code carefully.

4) How to Diagnose This Issue (simple)

If you're wondering if your site suffers from this problem there's a quite easy way of checking by looking at your conversion rate segmented by browser:

Setting up these custom segments is really easy, but to make it even easier I've set them up for you and all you need to do is click these links to add both these segments directly into your Google Analytics account:

Internet Explorer 8 Users

Non-Internet Explorer 8 Users

Then browse to your conversion rate report and select the segments from your custom segments:

5) How to Diagnose This Issue (advanced)

Of course, the issue I'm talking about in this post is only a specific issue and plenty of other issues may well exist like it. The underlying principle is that segmenting your funnel is a useful thing to do so that you can see if a specific visitor type are not converting or there is a specific drop-off point for them. Unfortunately there isn't a way of segmenting your funnel within Google Analytics at the moment but there are a few advanced ways of getting around this. For example:

• ROI Revolution have a method for segmenting on the fly. Unfortunately this method doesn't let you check custom date ranges.
• LunaMetrics have a way of segmenting the funnel using goals. Unfortunately this method won't let you capture historical data.
• Analytics Ninja has a way of segmenting using advanced segments. Unfortunately this method only let's you track up to a maximum of 3 funnel steps at a time.

None of these methods quite does what I want it to so I'm presenting a 4th option here:

Step 1 - Identify your funnel steps

This is fairly straightforward, all you need to do is understand what the URLs look like for your funnel. For example, let's say our funnel looks like this:

1. http://www.example.com/cart/availability
2. http://www.example.com/cart/details
3. http://www.example.com/cart/extras/
4. http://www.example.com/book/check/
5. https://www.example.com/book/payment/
6. https://www.example.com/book/confirm/

Step 2 - Create some regex

This is getting slightly more complex, however, assuming that all your URLs are exact match (rather than head match or something more complicated) the regex to create is this:

^/cart/availability$|^/cart/details$|^/cart/extras/$|^/book/check/$|^/book/payment/$|^/book/confirm/$

Where we generate this string as follows:

• ^/url1/$ - this matches the exact URL contained between ^ and $
• | - separate each URL with a pipe, this OR matches any of the statements in the string

For a more complete (and very pretty) guide to using regex in Google Analytics download this PDF.

Step 3 - Enter this regex in the top content report

In the top content report copy and paste this regex into the filter box:

This will then filter the top content report to only show you visits to one of the above pages in your funnel. Now we can see the drop off between steps like we can in the regular funnel.

Step 4 - Add custom segments & export to Excel

Now, we add whichever custom segments we want (for example IE8 users like above). This gives us each step of the funnel and the visits to each step broken down by segments:

Unfortunately this data is a little bit difficult to analyse as it doesn't give us the drop off percentage. So, to make this data easier to process and analyse export it to Excel. This will allow us to create a nice little table like this (very minimal excel magic required!):

This is an improvement over the simple diagnosis above because it not only shows us that IE8 users are not converting as well as users from other browsers, but it even tells us the exact step where it's a problem (the cell highlighted in red in the image). Looking back at the URLs we've identified we see that this drop off percentage is the same step where a user transitions from HTTP to HTTPS.

Note: The super-observant among you may have noticed that there is a potential discrepancy here. The warning message that IE8 throws up allows the user to select the option to only view secure elements on the HTTPS page. If the user selects this option then theoretically the user could still carry on through the site and complete the purchase. This visit and the revenue from this purchase wouldn't be tracked in Google Analytics since the HTTP Google Analytics call is blocked by the browser. So the extra £100,000 / month could in theory only be a reported increase in revenue. In reality however we found that the true bottom line still increased by over £30,000 per month as a result of this change. This implies that displaying the pop-up still has a drastic effect on conversion rates.

6) Conclusion

So what have we learned? The key lessons here are as follows:

• Keep your GA code up to date
• Use advanced segments to monitor conversion rate between browsers
• Always perform browser testing to ensure your website functions for all browsers

Remember, the HTTP/HTTPS issue applies equally to all URL calls so even if you use the up-to-date Google Analytics tracking code some other non-secure element on the page might be costing you revenue so always make sure that your website is functioning perfectly across all browsers. If you don't, you might end up losing £360,000 ($500,000) a year or more!

Thanks Tom for a thorough look at how to avoid this problem. And to echo Tom's advice, we encourage everyone to move to the newest version of the GA tracking code. You can follow more analytics insights and online marketing tips at the Distilled Blog or follow Tom on Twitter.

Posted by Trevor Claiborne, Google Analytics Team