frequent queries of the AIGA.org site, as reported by Google Analytics...
Figure 2-2. ...to learn about what your users want from your sites and your organizations.
Figure 2-3. Rich Wiggins of Michigan State University assembled, categorized, and even color-coded the most frequent queries from the open Web versus those generated locally to illustrate their differences.
Unlike people searching the Web, your site’s searchers typically have more specific needs. They also may be familiar with your organization, its products, and its content—after all, they had to find their way to your site in order to use its search system. So the knowledge you’ll glean from SSA will be a bit different than (and complementary to) what you’ll learn from SEO (Search Engine Optimization) and SEM (Search Engine Marketing). Consider this analogy: if people searching the Web are essentially the leads you want to attract, people searching your site are the customers you hope to retain.
Why You’ll Want to Use SSA
SSA is unique: there truly is nothing like studying what people want from your site. It should be in your research toolkit—not by itself, mind you—but there’s no reason for it not to be there, unless your site somehow doesn’t have a search system.
There are plenty of ways you can track and learn from users’ behaviors aside from SSA. For example, if you’re a web analytics person, you might rely on clickstream analysis; if you’re a user researcher, perhaps you perform eye-tracking studies. They’ll all tell you something about user intent.
But none of these methods will tell you what users want in their own words. SSA provides an unmatched trove of semantic richness—not just what users want, but the tone and flavor of the language they use to express those needs. And it’s without the biases introduced by testing and a lab environment. Plus, you have the data already. You certainly won’t find it anywhere else or acquire it any other way.
It Always Starts with Data
SSA starts with raw data that describes what happens when a user interacts with a search system. It’s ugly, and we’ll break it down shortly, but here’s what it typically looks like (this sample is from the Google Search Appliance):
XXX.XXX.X.104 - - [10/Jul/2006:10:25:46 -0800] "GET /search?access=p&entqr=0&output=xml_no_dtd&sort= date%3AD%3AL%3Ad1&ud=1&site=All Sites&ie=UTF-8&client=www&oe=UTF- 8&proxystylesheet=www&q=lincense+plate&ip= XXX.XXX.X.104 HTTP/1.1" 200 971 0 0.02
This data gets captured in a search log file—something your site’s search engine likely does automatically. Or the search activity gets intercepted, like other analytics data, by a snippet of JavaScript code embedded in each page and template. The intercepted data then gets stored in a database. That’s how Google Analytics, Omniture, Unica, and other analytics applications do it. You really don’t need to know much about how this code works, but now you can at least claim to have seen it.
<script type="text/javascript" src="http://www.google-analytics.com/urchin.js "> </script><script type="text/javascript">_uacct = "UA-xxxxxx-x"urchinTracker(); </script>
Although search engines and your analytics application may gather search data, they’re traditionally and disappointingly remiss at providing reports on site search performance. Even when they do, you still may want to get at the raw data to analyze and learn things that the reports—which tend to be quite generic—won’t tell you.[3] So it’s useful to know the basic anatomy of search data because it will help you understand what can and can’t be analyzed. We’ll cover just the basics here. (See Avi Rappoport’s more extensive coverage of the topic at the end of this chapter.)
Minimally, your data consists of records of queries that were submitted to your site’s search engine. On a good day, your data will also include the numbers of results each query retrieved. On a really good day, each query will be date/time stamped so you can get an idea of when different searches were happening. On a really, really good day, your data will also include information on who—such as an individual, by way of tracking her cookie, or a segment of users that you determine by their login credentials—is actually doing the searching.
Here’s a tiny sample of query data that must have arrived on one of those really, really good days. It comes from a U.S. state government Web site that uses Google Search Appliance. It’s really ugly stuff; so to make it more readable, we’ve bolded the critical elements: IP address, time/date stamp, query, and # of results:
XXX.XXX.X.104 - - [10/Jul/2006:10:25:46 -0800] "GET /search?access=p&entqr=0&output=xml_no_dtd&sort= date%3AD%3AL%3Ad1&ud=1&site= AllSites&ie=UTF-8&client=www&oe=UTF- 8&proxystylesheet=www&q=lincense+plate&ip= XXX.XXX.X.104 HTTP/1.1" 200 971 0 0.02 XXX.XXX.X.104 - - [10/Jul/2006:10:25:48 -0800] "GET /search?access=p&entqr=0&output=xml_no_dtd&sort= date%3AD%3AL%3Ad1&ie=UTF- 8&client=www&q=license+plate &ud=1&site=AllSites&spell=1&oe= UTF-8&proxystylesheet=www&ip=XXX.XXX.X.104 HTTP/1.1" 200 8283 146 0.16
Even with a little bit of data—in this case, two queries—we can learn something about how people search a site. In this case, the searcher from IP address ...104 entered lincense plate at 10:25 a.m. on July 10, 2006, and retrieved zero results (that’s the next-to-last number in each record). No surprise there. Just a couple seconds later, the searcher entered license plate and retrieved 146 results.
These are just two queries, but they certainly can get you thinking. For example, we might reasonably guess that the first effort was a typo. If, during our analysis, we saw lots more typos, we probably ought to make sure the search engine could handle spellchecking. And we might want to make extra sure that, if license plate was a frequent query, the site contained good content on license plates, and that it always came up at the top of the search results page. There are many more questions and ideas that would come up from reviewing the search data. But most of all, we’d like to know if the users were happy with the experience. In this example, were they?
Heaven knows. The data is good at telling us what happened, but it doesn’t tell why the session ended there. You’ll need to use a qualitative research method if you wanted to learn more. (We’ll get into this what/why dichotomy quite a bit in Chapter 11.)
[3] Once you have the raw data,
