Identify Problems with Your Site

If you’ve run a site for more than 1 week you’ve encountered users. For some reason they seem to be able to take the most finely crafted work you and your developer came up with and reduce it to a pile of smouldering bugs within seconds of launch.

I have one project in particular that has been launched for months and suddenly we had 1 user reporting missing content. They could see it when they weren’t logged in but as soon as they logged in content was missing.
Posts ‘magically’ disappeared.

I spent 2 hours trying to track that down. My client and I were about to just give up and say it was a user problem and she was just wrong. I couldn’t reproduce the error on my local install or on our staging site or when logged in to the user account on the live site.

Then one little tidbit of information came through. There was a ‘login’ link that I wasn’t aware of. During 2 short weeks when I was busy another developer had added it and hardcoded a path to the development server.

Development was at least a week behind live content so of course when the user logged in they didn’t see all the content.

What was a 10 minute fix took over 2 days of back and forth to find.
For most sites this process of back and forth is going to repeat itself over and over because “that’s just how it works.”

The reality is that it only works that way because you let it work that way.

Have a reporting system

Our big step to deal with future problems has been to build a reporting form for clients. We collect:

1. Browser (including version)
2. OS
3. Detailed steps to reproduce (seriously the more detail the better and screenshots FTW)

We also recorded a training video on how to get your browser version and your operating system and showed how much detail is great for bug reporting.

Finally if the bug seems to be extra obscure we get clients to use Screenr to record the bug in action. We even took the time to record a video demonstration of how to record that screencast and submit it to us.

But users rarely report bugs

Even with a solid process that’s easy for your users know that most of them are not going to report a bug. In fact we typically see only about 5% of users will actually report a bug even if it affects most of them.

So it’s likely you’re going to simply be loosing sales due to a bug you don’t know about.

That sucks but your developer can do something about it.

Log some bugs

Instead of just sitting back and waiting for your users to report bugs (which we know doesn’t happen enough) you should be expecting your developer to build in error reporting for your site.

We always use tool called WP_Logging (it’s a bit technical to be sure) with our custom development to catch any situation where an error could happen.

Less technical and usually billed as a marketing plugin is Leadin. With Leadin installed you can see where your users are going so you can check where that member that just cancelled has been during their membership. I did they recycle on an odd page for a few days?

Does that page work properly? Time to figure it out.

Set up Goals

Google Analytics has an awesome feature called ‘goals’ that allows you to define the ‘flow’ of a user through your site. A typical eCommerce flow should look something like a triangle pointed down.

100 people start the funnel 80 people get to checkout and 50 people purchase a product.

Now if you have 100 people start the funnel and 80 people get to checkout and 10 people purchase then you’ve likely got a problem with the checkout page. It may not be a site bug (as in it may not be actually broken) but there is certainly something wrong with the content of the checkout page.

Issues happen on sites and it’s likely that your users aren’t even reporting them they’re just leaving. Setting up some goals in Google Analytics and some additional development logging will go a long way to making sure that you catch as many bugs as possible.

• Posted by:

  Curtis McHale on February 3, 2015

• Category: Fundamentals of Online Selling