Relevance tuning in the search domain. What is it exactly?

First thing first! Let’s get rid of the bullshit bingo lingo: “Relevancy tuning” in search is a fancy description for something that’s not very magical, even if it sounds like just that. It’s about getting the right results on top of your search result. End of story. If somebody asks you a question, you should start by giving that person the most likely answer first. Most search engines seems to be digressing. It’s because we haven’t told in a clear manner what to be expected from them. And because we often use generic tools to solve specific problems.

One generic tool for getting the right results on top is the “term frequency–inverse document frequency“, or tf-idf for short. It’s a combination of how often a term is mentioned in a document compared to how often it’s mentioned in all of your documents in the index. So, rare terms within the whole index used often in one document makes it a good search result when searching for that term. But most likely, not good enough. You need to figure out what’s the characteristics of your content, and what are the most characteristic use cases and user stories for your users. Only then can you achieve great relevancy, …  I mean get the right result on top of your search result.

Model for relevance tuning

We’ll use our Recipe app as an example…

Model for relevance tuning

So, for our food recipe app, we have some obvious content characteristics:

  • The more ingredients in-season for one recipe is good. We’re doing an OR-search on all ingredients in-season so this comes out-of-the-box … almost.
  • Quite a lot of recipes doesn’t stand the test of time. We know that most of the recipes at oppskrift.klikk.no from 2008 or newer are quite good and have nice photos.
  • We’re not sure if we need this, but we know whom of the writers to trust. This may be an overkill when we already have a boosting on newer recipes.

And we know a lot about our users as well:

  • Most grown up people in Norway have a job, thus limited time to prepare a meal. This means that recipes that takes shorter preparations should be boosted from Monday through Thursday. The verdict on Friday is still not decided.
  • During the weekend people have more time to make dinner. The recipes that takes a short time to prepare most probably cut some corners, and are not that good compared to recipes that takes a little longer time. So for the weekends, we should do a demotion of really quick recipes, at least for dinners.

This is the info we’re going to use to sort our search result. But we have more knowledge about our users that we can use to auto-set filters for certain times of the day:

  • Most work days, people don’t plan a breakfast meal or lunch. The whole day we can auto-set the main “course” filter.
  • During the weekend, people may also plan a lunch. We’ve decided to auto-set the “light meal”-filter during weekends up until lunch time. After that the “main course” filter is auto-set. We’ll log if the first thing our users do is to set another filter.
  • On Friday and Saturday a lot of Norwegians drink beer, wine or liquor. After some hours of drinking, they get hungry. Maybe we should have an “afterparty, quick and greasy and tasty-meal”-filter auto-set for late Fridays and Saturdays?

So, what’s the filters we’ve decided on:

  • Light meals
  • Starters
  • Main courses
  • Deserts
  • … and maybe the Afterparty-thingy

What do you think?

Model for relevance tuning

Sounds nice? This is work in progress, so check back every now and then for new blog posts.

Article written by

Espen Klem
Interaction designer with a love for log reading, statistics and mind-bending, user friendly concepts.


Leave a response





XHTML: These tags are allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

301 Moved Permanently

Moved Permanently

The document has moved here.


OSLO

Comperio AS
Øvre Slottsgate 27
NO-0157 Oslo,
Norway
+47 22 33 71 00
View map

STOCKHOLM

Search Provider Sverige AB
Gamla Brogatan 34
SE-11 120 Stockholm
Sweden
+46 8-21 49 00
View map