As I’ve written in previous posts, internal search provides great insights into so many aspects of your site, and is one area that you should definitely focus measurement on.

Aside from the usual keywords that people are searching on, and whether or not those keywords lead to a conversion of some sort, there’s other measures that can be used to show whether your internal search is working.

For example, if you segment your audience type (as we do into Staff, Students and Anonymous traffic), you can see the different searches those audiences conduct.

Some measures to understand the effectiveness of search results would be:

• Time on the search page – a large amount of time would indicate they are not finding the result
• Search bounce – a high bounce would indicate poor results
• Number of searches per session – while not a direct indicator, could indicate poor results
• Keyword pathing – shows refinement of searches
• Number of Results – look for the zero’s in this one

Sometimes, no matter what you do, your organic search results just don’t cut the mustard – especially in a distributed content model where the content owners are less inclined or less experienced to think about SEO.  If you find yourself in this situation, there’s a number of different things you can do to help.  Half the battle though is realising that your natural search results are going to be poor (garbage in, garbage out) and any change is likely to be a slow burn.

One option to assist would be Omniture SiteSearch, which will allow you to do all sorts of things, including influencing results based on previous search data from SiteCatalyst, integrated with Test & Target…but we’ll save that for a future post.

Number of Searches

On the flip side, to get more insight, let’s look at the number of searches per session.

You can implement that very easily by using what’s called a counter eVar.  You simply want to know the number of times something happens, before something else happens.

In SiteCatalyst, you can create a counter eVar (simply select the type of eVar as counter).  Each time something happens, such as a search, we pass in the value of the keyword and we pass in a special value “+1″ to the eVar.

SiteCatalyst then allows you to see reports based on those different values.

Our internal search tracking code looks like this:

/* Internal Search Event Setting */
if(s.prop5&&s.prop5=="0"){s.prop5=""}
if(s.prop5) {
s.events=s.apl(s.events,"event1",",",1);
s.eVar39="+1";
}
if(s.prop5&&!s.eVar5) s.eVar5=s.prop5;


We set s.prop5 with the keyword on the search page – everytime a keyword is present.

eVar39 is our counter eVar.  It basically captures the number of times that we have searched for something.  Each time we do another search, the value in SiteCatalyst is incremented by 1 and then we end up with a report that shows the number of searches during a session (as we have set the eVar to expire on a visit).

So in this, albeit very limited result set, it shows that there were 184 searches on the first attempt.

There were 53 searches done on the third attempt, and so forth.

Interestingly (sadly), one search term was searched for on a 17th attempt – someones keen, but likely couldn’t find the result they were looking for, and they continued to search until they found some decent results.

You can also break down (providing you have full correlations on search terms), on each attempt to see what they were searching for.

In the instance where the person conducted 17 searches, the 17th search was for the term “vbs location”

I’ve also illustrated here that keywords can be broken down by the number of searches conducted.  In the example above, Bookshop was searched for 205 times in total, but featured as someone’s 2nd, 3rd, 4th and 5th search attempt (the none is because it’s got previous data prior to my eVar being put in place).

Monetising Search

For most companies, search conversion is key – revenue generation from search.  However, for the most part, our internal search does not “convert” to a sale of something.  It’s mostly used to find content, so we’re keen to understand what that costs us (not how much revenue is being generated).

If you’re looking for a way to calculate a cost for search, here’s a “back of the envelope” calculation…

The average time spent by Staff on our search results page is around 208 seconds.
The average number of annual searches by Staff alone is 124,600…
therefore…
25,916,800 seconds expended using search annually
= 431,947 minutes expended using search annually
= 7,199 total hours expended using search annually
(that’s a phenomenal number when you think about it… that’s 960 working days at 7.5 hours a day)

If the average cost per hour of a resource is $ 40.00
then…
$ 287,960 is the total cost of resources who spend their time searching

If you can decrease search time spent by just 10% (21 seconds), you theoretically save around $29,000 – or you increase productivity availability by 96 days…food for thought!

A few fancy calculated metrics in SiteCatalyst and you could probably put cost of search against each keyword for a specific audience as well…but we’ll leave that for now.

On the plus side, if you do the above, you’ll conversely be able to see conversions from search, enlightening you as to which search terms are driving revenue, or leads etc.

Search is a veritable gold mine that is frequently ignored.

I’m not talking about Search Engines and Keywords, I’m talking about your internal search. Providing you track internal keyword searches, you can gain a wealth of understanding.

Internal search is generally used as a quick wayfinding method, highlighting areas of content that are well used, but are not readily available.  And more often than not, it’s seasonal as well.

The following report shows the top 5 keywords used by students on our University website, smoothed using a 21 day moving average.

Two things immediately jump out.  Firstly, notice how searches for Bookshop increased dramatically in late February, then declined, then Library picked up substantially in March, followed by Exam Timetable in late April (spiking suddenly in late May).

Very seasonal activity, centered around the Student’s life cycle at the University.  In February, having started a new semester, they all needed books.  Then as semester progressed, they all needed access to the Library, and lastly, as exams approached, they all wanted to know their Exam Timetables.

Great – but how can we use this?

Well, firstly this points to the fact that there is no clear navigation on our site to these destinations.  There’s actually a reason for that – our public site is not designed for active current students as they should be using the Student Portal.  That aside, we can assist though in making these destinations easier to get to.

One thing we can do with Omniture is to export these top keywords to our database on a daily basis and then represent them on the site, through things like tag clouds and quick search results, making their lives easier in the process.

By using real data and automating the process, the seasonality of searches will also come through to the site as well.

The other interesting thing about the above chart is their search for timetable, as opposed to exam timetable.  When they start a new semester, they are interested in their class timetables and frequently search for them.  As time progresses and the memory kicks in, that activity slows down.  Again, this can be used in a number of ways – not only online, but through mobile apps and offline support media as well.

In order to track search keywords, simply put the keyword into an s.prop.  You might also want to put the number of results into another s.prop so that you can cross-reference the results on a keyword by keyword basis.  This would highlight any search terms  that return no results.

Segment your keywords

As always, understanding your audience is critical online.  If you segment your audience types, you’ll also be able to see the different searches conducted by different audiences.  We do this and the results are (obviously) very different.  But, without the ability to do it and show it, you’ll be taking an educated guess that they are different.

To do this, put the audience type into another s.prop and use the getAndPersist() plugin to set a cookie.  That way, all activity can actually be segmented by audience type.

Now you can provide some really smart assistance

When you start to build your tag clouds or your quick search lists, you can base the results on the value in the cookie, thereby customizing the information to the user and making it more relevant to them.  Just a few little tricks like this and you’ve helped to increase the usability of your site, which will go along way in driving customer loyalty (and hopefully revenue).