Dec 08 2008
Poorly Performing Pages – How Do We Know?
How do we really know when a specific page isn’t performing well? The obvious answer is to do some user testing. That is essential. Before we even get to that point, though, we can do some investigative work to pro-actively improve (or know where to test!) pages.
Rarely can we look at one report and know the answer. The trick is to look at all angles and search for a pattern.
Let’s start with some examples.
Landing/Entrance Pages. What are the top pages users land on when they enter our site? What is the bounce rate of these pages? Remember to put bounce rate into context, though.
Exit Pages/Exit Rate. By looking at our top exit pages, we can see where people leave our site. Just like bounce rate, make sure you put this in context. Does your page contain a lot of exit links?
Exit rate is defined as Exits/Page Views and tells us what percentage of time a particular page was the exit page of the user. To track your actual exit links (as opposed to someone closing out of your site via the browser), check out the great post by Nick DeNardis on .eduGuru about tracking exit links in Google Analytics.
Internal Site Search. How do users search on our sites? What terms do they use? For example, let’s take a top search term and measure the health of that topic page. Because we deliver online courses, one of our top search terms is “proctor” since students need proctors to take exams. Are users searching for this term because it’s a popular topic or because they can’t find it via the navigation or both? Not sure. Let’s dig deeper.
Knowledge Base. Like internal site search, if the site has a knowledge base and there are recurring themes to questions, users may not be able to find those pages on the web site. Are users consistently asking about transferring credits? It could mean that a) they can’t find the transfer credits page or b) they don’t understand the transfer credits page.
Contact Us Previous Page. If your contact us page link appears on every page (which it should), what are the top previous pages? Where do users come from to get to the contact us page? Again, is there a recurring theme? Are users consistently clicking on the contact us page from a particular page? Maybe the information on that page is confusing.
Call Volume. We are a seasonal business. During mid-term or finals time, for instance, call volume will increase for specific things. We can measure our call volume around specific topics. Let’s take our proctor example again. Are we finding an overwhelming amount of questions about proctors? Do the questions involve simple information that can be found on the web site? Are users getting frustrated, picking up the phone instead of searching?
Caution: When measuring call volume and topics, don’t fall into the “everyone says/nobody can find” syndrome.
“Everyone says our website stinks.”
“Nobody can find X page.”
It’s very important to document when users/students are having issues with the web site. Train staff to document specific issues with specific quantities.
Feedback/Surveys. Feedback forms and site surveys are another good place to get some insight into poor performing pages. If the particular page in question is actually referred to in the feedback or survey as being poor, that’s a no-brainer, but again, always put it into context. If it is one person, use caution. If there is a trend, then take action.
How about looking at what page the user was on when they gave their feedback. This may not be possible with site surveys, but it is with a feedback form if there is a link at the bottom of each page.
Forms/completion rate. This one has to do with forms specifically. By tagging the form *and* the thank you page of the form, we can measure the form completion rate. In Google Analtyics, we can set up a conversion goal to measure this.
Are we finding that there are many visits to the form, but not many to the thank you page of the form? This may tell us there is something wrong with the form. Is it too long? Too complicated? Not user-friendly? Dig deeper.
Adding it all up. None of these, taken individually, will usually tell a whole lot. Except for specific cases (where a page might be broken or have *wrong* information), one of the above *shouldn’t* be taken individually. Never assume anything by looking at it from one angle or with one report. Taken together, however, we can identify patterns. This should then lead us to investigate further (in our case, it led us to do user testing of a specific area of the web site).
As always, the analysis doesn’t end with testing. Test, tweak, then measure again. Did anything change? Hopefully.
