No help strategy can be complete without including regular analysis of search analytics. Search analytics are the metrics about how users access to your help content. For example, some key search analytics include the number of page views for each page in your help, the length of time each page was viewed, the bounce rate, and so on.
By regularly reviewing your search analytics, you can gather key information about your help content. Using this information, you receive a better understanding about the kind of content users are trying to find, the questions and issues that matter most to them. Analytics should shape how you organize your information.
The following are some notes from Lou Rosenfeld's session at Brain Traffic on search analytics.
If you find that a lot of users are reading about feature X, Q, and P, then you can review those pages in your help material to make sure they are accurate and helpful. These high traffic pages usually mean the topics are of higher interest to users, so it gives you a key place to focus your efforts. Remember the 80/20 rule — not every topic in your help deserves equal attention. Put more effort into the topics that are viewed most.
A bounce means a user looked at just one page on your site and then exited. On the web, users sometimes bounce to other sites when they don't find the information they're looking for. This may or may not be true in help, however.
For example, suppose you have a context-sensitive link to a specific help topic. The topic answers the user's question, and then the user closes the help.
However, if some pages have high bounce rates, it may indicate that the user isn't actually finding the information. Take a look at these pages and analyze why the user didn't find the information on the page. Are there questions you're not addressing?
It's easy to focus on the pages that users spend a lot of time on, and to consider those important. But pages with high numbers of hits and a short viewing time also reveal a lot. These metrics show you the negative space of your content that you should focus on. Maybe you used the right keywords but failed to address questions the user had.
One immediate fact you'll notice from search metrics is that the home page almost always has the highest number of views. This is because the homepage serves as the gateway to all other pages. Nearly every user who lands on your content starts at the home page.
Given that the home page has such a high number of views, shouldn't we focus a tremendous amount of energy on this page? Rather than providing a general description of the application, followed by other overview information, perhaps we should focus the homepage on the most popular issues and frequently asked questions.
If you can capture keywords users input in their searches, this information can help you know whether the terms you're using in your application match the terms users prefer to call the same concepts. This is a point Lou Rosenfeld stressed in his talk. This list of search terms provides you with a perfect database of the user's language.
You may not be able change the terms in your application to match user search queries, but some help authoring tools allow you to create a synonym file that will connect two terms together. This way, if a user searches for term A, and you have equated term A with term S in a synonym file, users will be more likely to find what they're looking for. Establishing synonyms can provide a key boost in the helpfulness of search results.
I was looking through some analytics today and noticed that "Page Not Found" ranked rather highly in a certain set of analytics. Knowing that users can't find a certain page can be illuminating. Rather than give users a dead-end in the form of a "Page Not Found" sign, seize this opportunity to help them find what they're looking for. I wrote a post some months about the need to focus on the "Page Not Found" or "No Results" page. See Customize the No Results Found Page with Helpful Tips.
On your "Page Not Found" page, you might add links to the most popular pages, include an advanced search, add a link to the help desk or popular queries, and so forth. This Page Not Found is often an overlooked opportunity that help authors don't even notice.
To see the "Page Not Found" page in your help, type in a bogus web path to your site, or search for something you know isn't in the help.
Some search tools show you the path users take to get to your page. Seeing this path can be tremendously helpful. I wrote a post last year called Treejack as a Means of Evaluating Your Navigation. Treejack shows you the paths users took to move to their information goal.
Even without Treejack, advanced reporting tools such as Omniture Site Catalyst can show you path information. As you analyze paths, consider why a user decides to move from one page to another. Does the user connect the two pages in his or her mind? Perhaps the page titles communicate a similar grouping? Does one set of instructions require the other? How can you adjust the site navigation to be more intuitive based on the user's path. Ultimately, try to answer this question: Why did the user take this path?
So often we skip over search analytics because we're trying to meet tight deadlines and often lack the time for this more reflective assessment of our content. But trying to increase findability without carefully looking at how people are using our sites is foolish. Metrics give you objective feedback about how people are using your site. Using this information, you can help users better find the content they're looking for.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the San Francisco Bay area of California. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here.