SSA is based on data that comes from actual usage of your site, just like other forms of web analytics. But it’s far more semantic, as it is made of search queries—users’ expressions of what information they want from your site in their own words. That’s why SSA does a better job of depicting and helping you understand users’ intentions than any other form of web analytics. Chapter 3 provides some tools for analyzing and understanding users intentions.
Why do I need SSA?
Because SSA can help drive—and back up—your design decisions. Because you already have query data and want to put it to good use. Because you want to make your search engine find content better (Chapter 8), make your site easier to navigate (Chapter 9), and make your content more effective (Chapter 10). And because your competitors aren’t using it, and you’d like to destroy your competitors.
Where does query data come from, and what tools do I need to analyze it?
When someone uses your site’s search engine, they type a query that the engine will try to match with your site’s content. That query can be (and likely is being) saved. It’s either logged in a text file by your search engine or intercepted and kept in a database by your analytics application. Search engines occasionally and analytics tools increasingly provide reports that help you analyze the data, but ideally you’ll explore and learn more from the data in a spreadsheet. Unfortunately, there’s no one way to get your hands on the data, because how you can get at the data often depends on what search engine you’re using. Talk to your organization’s IT people for help and show them this book if they ask why you need access to the data.
I’m not a “data person,” so why should I read this book?
Organizations are putting more and more pressure on designers to justify their decisions with evidence. Fortunately, SSA is real data that’s also semantically rich, so you won’t be just looking at numbers. And you won’t need to perform statistical tests to learn from it; in fact, it will be immediately obvious to you how it can help improve your design work.
This isn’t part of my job description (or anyone else’s) so who should do this work?
User researchers and the designers who rely upon user research—such as information architects, content strategists, interaction designers, and knowledge managers—should at least consider SSA as a part of their standard kits of research tools, even if it’s not something they use on a regular basis. The same goes for web analytics practitioners: SSA is an important tool, just like clickstream analysis. The best part is that no one needs to do SSA as a job—it scales nicely, depending on the time you have available (see our discussion of the Zipf Distribution on George Kingsley Zipf, Harvard Linguist and Hockey Star-Ways to Use SSA (and This Book)).
How do I actually analyze query data?
First, “play” with the data by looking for patterns and surprises that suggest what’s important to your searchers and what kinds of content will best meet their needs (Chapter 3). Then identify and learn from searchers’ failures (Chapter 4). See what happens in the course of single search sessions (Chapter 5), and tease out what’s important to specific audiences of searchers (Chapter 6). Finally, measure your site’s performance better by injecting search metrics into how your site is performing at meeting its goals (Chapter 7).
How does SSA fit with other user research methods?
SSA is based mostly on quantitative behavioral data; therefore, it’s useful to combine it with your qualitative user research methods and tools. For example, use query data to help determine candidates’ tasks for your task analysis studies or to beef up your personas with real data. Chapter 11 talks about how SSA fits into the broader worlds of both user experience research and web analytics, and how it may be a great means for bringing them together.
If it’s so great, how come more people aren’t taking advantage of SSA?
Good question. Most people don’t know that query data even exists, much less that their organizations likely already own some. Those who do often run into political problems when they try to get their hands on the data, because it is usually owned by IT or some other group. (This is getting easier thanks to ever-improving analytics tools.) Finally, there hasn’t been much practical information on how to analyze the data. Maybe this book will help.
Foreword
A funny thing happened the first time Lou and I teamed up to teach our day-long public workshops (mine on usability, his on information architecture), probably eight years ago now.
I went to his workshop—the day before mine—partly out of due diligence, but mostly because I’ve always enjoyed listening to Lou, and I knew I’d learn a lot.
Halfway through the day, Lou spent 10 minutes talking about something I think he called “search log analysis” at the time. Basically, you get your hands on the log data for your site’s search engine so you can see what terms people are searching for most often. Then you take the most-searched-for items (say, the top 25) for the current month, execute the searches yourself, and see what you can learn from them.
For instance:
Were there any results? If not, maybe you need to add content, or at least figure out why people on your site are looking for something you don’t have.
If there were results, were they the best content your site has on the topic? If not, you may want to tweak your search engine or fiddle with some keywords.
And why were people using Search to find these things? Was it because it’s not obvious how to get to them through your navigation?
Basically, Lou was suggesting that you spend a very small amount of time each month to see if people are finding the things they’re looking for on your site. Then you tweak your navigation, your content, or your search engine as needed to make sure they can. The next month, you do it again, with the new top 25.
The funny thing was that I’d been making almost exactly the same speech in my workshops for a long time, pretty much word for word.
When I mentioned it to Lou later, it turned out that even though the technique was really off-topic for both of our workshops, we both thought that we just had to tell people about it, because we thought it was the most cost-effective thing people could do to improve their site. Very little effort, very big payoff, and almost no skills required. And virtually no one knew about it.
Fast-forward, several years.
Besides starting up a publishing company, having two great kids, and relocating from Ann Arbor to Brooklyn, Lou decided to write a book. About this topic. Which he now called Site Search Analytics.
Fast-forward several more years to today, when you’re holding the book in your hands. (Or reading it on a digital device that didn’t exist