Internal search is one of the best goldfields available to you. Not only does it help you understand what your users can’t find in general, but it can also helps you understand what they expect to see on certain pages – and aren’t seeing.
Beyond just the basic keyword measurement, there’s also other things you can do to further enhance your internal search metrics.
For example, we generally all have search pages, which users end up at following a search. The typical SiteCatalyst implementation involves setting an s.prop and an eVar with the value of the search term, and a success event, on the search results page.
Many also implement another s.prop with the number of search results found to get an understanding of searches that are returning zero results.
But you can take it one step further too.
Multiple ways to search
Most sites are designed with a consistent search field somewhere on the page, which means that entry to the search results page can be from any page on your site. So finding pages that are causing people to search becomes a problem. You could use pathing, but it doesn’t really help because it’s a combination of the search term and the page they were on that’s of most interest.
So there’s another way to do it, using a plugin you may already have.
If you use the getPreviousValue plugin, you can correlate the previous page the user was on when they typed in the term to your search engine.
So in the example above, we see that “exam timetable” was the most searched for term over the last X period (in fact exam related information is quite heavily searched for in general).
To get greater insight, use the s.getPreviousValue plugin. This plugin is most commonly used for understanding how far a user scrolls down the page, but it can also be valuable for search.
The first thing to do is implement the plugin into your s_code – if you’ve not done it already.
Typically, you’ll have something like the following in your s_code as well, which captures the previous page viewed into an s.prop and the percent the page was viewed into another s.prop:
/* capture previous page name; capture percent of page viewed */
Once you’ve got that done, all you need to do is correlate your keywords s.prop with your previous page viewed prop (use the Admin to correlate the two).
When correlated, you can now breakdown the keywords report by previous page viewed report. This only works because both the keywords prop and the previous page viewed prop are set on the same page…hence you get the value of the keyword as well as the value of the previous page they were on when they searched for the term.
For example, if we correlate the keyword “exam timetable” with Previous Page Viewed, we see:
Now we see that of the 1737 searches for exam timetable, 558 of them originated from our home page, 362 from our student portal, etc.
It may be wise therefore, especially at a time like this (exam season) to provide those links within those pages.
You can also reverse it, to see what else they’re searching for from specific pages.
Open the Previous Page Viewed report, pick a page and correlate with internal search terms:
Here we see that from the same portal page above, the top things they cannot find information on, is all about exams.
A good indicator that something should be added to the page to support the users desire for information about exams.
By the way – “unspecified” exists in this report because it says that of the 16,631 page views to portal:students:myunits, 15,350 views didn’t result in a search.
We’ve got more coming on our Search soon as we’ve just gone through a Search & Promote implementation, teid to SiteCatalyst, with some incredible results…we’ll be sharing them with you once we’ve found the time to blog about them. Let’s just say that we can demonstrate a savings of around $165,000 to the organisation through this implementation.
But more coming on that soon.
And there’s a humdinger of a Test & Target campaign coming up this week too…stay tuned for that one.
Oh, and sometime in the near future I’ll post something around the holy grail – measuring user engagement using Discover.