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 . 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:
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:
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:
- http://www.example.com/cart/availability
- http://www.example.com/cart/details
- http://www.example.com/cart/extras/
- http://www.example.com/book/check/
- https://www.example.com/book/payment/
- 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.
KeePass 1.18 (Installer EXE for Windows)
