you. You get the benefit of years of pondering, researching, inventing, and fine-tuning by somebody as smart as Lou. (In this case, Lou.)
One caution: Don’t be intimidated by the soup-to-nuts scope of the book. Even though Lou spells out a lot that you can do, you don’t have to absorb (or even read; sorry, Lou) all of it. I encourage you to just try a little bit; dip a toe in the water, if you will.
With nothing more than this book, a few hours of your time, and perhaps a copy of Excel, you’ll be amazed at how much better your site can be.
And once you see how much you can learn in a few hours, don’t be surprised if you get hooked and want to do a lot more. That’s when you’ll be glad Lou wrote the whole book.
Have fun.
—Steve Krug
Author, Don’t Make Me Think! and Rocket Surgery Made Easy
I love internal site search data. Completely.
My love emanates from a singular fact: Of all the data we have access to, site search is the only place where we have direct access to visitor intent.
When people click on links to visit your Web site, you know the sites or search engines they come from. How much intent does that communicate to you? 10%. It is really hard to know from that data why people might be showing up. How much intent is there in the keywords that people type into search engines like Google, Bing, or Baidu? Maybe a bit more than 10%, but honestly not that much. Our beloved visitors are notorious for being deliberately vague when they use search engines.
Yet when people search Web sites, they become astonishingly precise about why they are there. The queries they type into site search engines contain oodles of intent, just waiting for us to convert into insights that drive greater customer satisfaction.
Over the last couple of years, it’s been amazing to see how much valuable intent data is now available from almost all analytics tools, including Google Analytics. What words did people type? How many of them left your site because search results were so horrible? How many people had to refine their queries to get your search engine to cough up the right answer? Is there a material difference between conversion rates for people who use site search users and those who don’t? With site search analytics, all these questions and more can now be more easily answered.
So now that the data is available, how does your site go from merely okay to magnificently glorious? That’s where this lovely book by Lou comes into play.
Gently holding your hands, whispering soothing words, Lou will guide you through this rich and untapped world. You’ll start simple: just reading Chapter 2 will bring you 10x the return on what you paid for the book. Subsequent chapters will take you deeper and empower you to answer invaluable questions. How do you understand the patterns in your data (Chapter 4)? How do you analyze the audience (Chapter 7)? How do you achieve the nirvana of bridging the world of quantitative and the qualitative (Chapter 11)? All will be revealed using real-world examples, practical actionable tips, and a precision that will yield immediate benefit to your website visitors (and long-term benefits to your own salary!).
Carpe Diem!
—Avinash Kaushik
Author, Web Analytics 2.0 and Web Analytics: An Hour A Day.
Chapter 1. How Site Search Analytics Can Save Your Butt
The Brake Works—Thanks to Site Search Analytics
Moral of the Story: Be Like John
I could jump right into telling you all about site search analytics—after all, that’s the goal of the book. But a story might be a bit more instructive and interesting way to introduce the topic. So let’s start with a true story of how one large organization faced a grave problem with its search system—and how site search analytics saved the day, as well as some jobs.
The Brake Gets Pulled
John Ferrara should have been satisfied.
After all, his employer, financial services giant The Vanguard Group, had just purchased a powerful new search engine to make its intranet’s content searchable. Given its long history of investing in user experience, the company had asked John, an information architect on the staff, to help select the new engine and ensure that it served the end users. And, unlike many organizations, The Vanguard Group actually listened to its information architect’s advice. The installation was going swimmingly, and the technology seemed to be working. The search engine was running on a development server, the launch was scheduled, and it wouldn’t be long before Vanguard’s 12,000 employees were enjoying a far better search experience.
And yet, something didn’t seem quite right.
The project manager wanted to ensure the quality of the search results and asked John to do a review of the build on the development server. So he poked around and kicked the new engine’s tires, trying out a few common search queries to see what happened.
What happened wasn’t pretty. The search engine seemed to be retrieving results that made no sense; the results were far worse, in fact, than those of its predecessor. How on earth could all that time, money, and effort lead to an even worse search experience?
The launch deadline loomed just a few weeks out.
The Brake Gets Stuck
So John pulled the chain to halt the process from going forward. With his project manager’s support, John described the problem to the IT staff who owned the project. They nodded their heads and listened patiently. And then they told John that they couldn’t see the problem. After all, the search engine was up and running, and had been set up as the vendor suggested. The vendor was experienced and clearly knew what it was doing, likely far more than anyone at Vanguard (John included) could possibly know about how a search engine should work. Anecdotal findings from one person’s poor search experience weren’t going to trump that knowledge. With the launch date just around the corner, the staff weren’t about to halt the project.
Now, this may seem to be an unreasonable response. But most IT people would react in the same way, and with good reasons: technically, the search engine really was working quite well. And while Vanguard’s IT staff were uncommonly sensitive to user experience issues, it wasn’t clear that the problem John was intuiting actually existed. After all, he had no compelling proof to present that the search was broken. Combine these reasons with the pressures IT faced to get the project completed on schedule, and you could argue that the IT people were actually being very reasonable.
But