Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
If you’ve read the Selfridges Site Review, you’ll know that during testing, I came across a quite a severe bug. This bug displayed a confusing error message at the checkout when I was trying to place my order, but also charged my card at the same time. What fun.
Inspired by this, I've written about four simple & easy to implement ways to reduce onsite errors, whilst making your Helpdesk staff's job a bit easier.
I’m in rather a unique position, my audience are quite special, in that often they have never shopped online before, and as such, need to be hand-held through the experience. They are also quite prone to mistakes, which means I’ve had to build an extensive support infrastructure, not just for my users, but also for myself and my helpdesk team to be able to resolve issues quickly.
So, since Selfridges took a few days to figure out the problem I had and resolve it, it dawns on me that not everyone is doing the same. So i thought I’d detail a few of the ways I’ve created a support infrastructure that not only aids my helpdesk, but also helps me increase my conversion rate.
Firstly, lets face the truth
OK, firstly, your users are always going find issues before you do, even with the most stringent of testing methodologies. They will always be the ones with funky browsers and special “speed up internet” software and exotic plugins. There will be those who have the “never fetch a new version of a page” cache setting turned on, have fancy payment card details and live at addresses that break the laws of physics. This is a fact of life, it will happen.
You’re job is to find out why it happened and fix it, preferably before the user reports it to you.
And before you think “oh, well I’m on Platform X so I don’t need to worry about this”, Selfridges are on IBM Websphere Commerce: if it can happen to them it can happen to you.
1: The good old Feedback Form.
Even without all the infrastructure to capture and analyse support issues, it's fundamental to offer a clear and simple process for your users to give you a little nudge when they have a problem, and to make sure that when they do, you get the maximum amount of information about their experience.
So, the humble feedback form. I would argue keep this in a single easy-to-reach place, rather than replicating it on any error page. This way should you have any (Gasp!) unhandled errors, they can be reported too. This feedback form should be super simple, pull through the customers contact details if they’re signed in, and prompt if not, but not require them.
The basic additional information in this form should be:
- The user agent of their browser.
- Their Customer ID - if they have one, so you can look into their account.
- Their Basket ID, so you can look up its contents.
- What ever their Session ID is, assuming that you have a handy tSession table that holds session information during a visit.
If you’re feeling funky and have Live Support, then the inbound call request to your helpdesk team can have this information appended to it too.
2: Run Away! The Terrorlog!
OK, this should really be tErrorLog*, which means it’s a table in our database that holds a log of all the server errors ever experienced, so anything 404 or 500 or similar writes an entry giving us a whole bunch of additional information to work with.
Not only does this allow us to capture any points where our firewall’s flood controls and suspicious activity filters are failing, but also with regular review, allows us to pinpoint any situation that would throw an error.
*As an aside, we once had an analyst of a data agency describe our database schema as “it’s just beautiful, a work of art”. That made me so proud.
3: The Card Decline Monitor
I’ve banged on about this before, but if Selfridges had had this, my issue would have been fixed licketyspit.
At Wiltshire Farm Foods, we have a thing called a Card Decline Monitor. What we suspected (via our helpdesk and a healthy does of “feeling in our bones” intuition) was that a number of people were having their payment declined, not because of lack of funds, but due to exotic card types, strange issue number/start date combinations, or an overzealous address verification system.
Whenever a nonstandard response from the Payment Gateway is received, this is stored along with the customer ID, so that our Helpdesk staff, should they receive a call or email, can help the customer resolve the problem.
Most importantly, if we see the same error continually, then we know there is something that we need to look into.
4: Event tracking on Site Errors
If you’re using Google Analytics (which it seems, is an awful lot of us) then you have a nifty feature called Event Tracking. This allows you to register anything that happens on your website as an “Event”. Along with this, you can pass a number of parameters, such as a video being played and how far they go into it, whether someone clicked “add to basket" and how many they added, and so on, without having to use a virtual pageview, which is rather clumsy.
A great use of Event Tracking is to register when an error has occurred to the user, this could be something as simple as an incorrect password, to something more severe like the error I encountered at Selfridges.
With Event Tracking, you can pass an Event, an Action, and a Label to Google Analytics for tracking, so you could pass:
- Event - The error (This seems a bit noddy but you should be event tracking lots in GA, so you’ll want to keep these separate).
- Action - The page it occurred on.
- Label - The error message itself.
Using Google Analytics, you can then examine the pages most prone to errors & the conversion rate following a particular error. Where conversion rate is low, you can then look to either improve the messaging or rework the site so users don’t find themselves in the same situation.
Improve your error messages!
Right, drill this into the heads of your developers: Error messages aren’t error messages, but mini-guides to making sure the customer’s next action is a successful one.
Tattoo it into the eyelids if you have to. From experience, most error messages are written by developers, which is why for a long time we suffered from error messages such as “Something has gone wrong!”. Fortunately we now have a copywriter who rewrites such things for us.
On Selfridges, I received the error:
"Unfortunately we are unable to process your order as it has failed our validation checks"
Which isn’t super helpful. So going back to the rule - the error message is a mini guide, this error should say:
- That everything’s OK (as long as it is) - no one likes an error.
- What the validation checks are.
- Which part of my order failed the check.
- What I should do to correct this.
- A helpdesk phone number and link to a feedback form.
- A different way of placing my order, such as over the phone, a sales a sale.
So, hopefully you’ve found this useful - and as a little “name and shame” game, the next time you come across an error message clearly written by a developer, post it here!