Sr. Staff Writer
Sorry, there is no results for this query
We continue our series on search relevance. Our first article defined relevance, describing a relevance cycle that starts with search (i.e., finding and ordering items) and continues with advanced browse and discovery strategies like merchandising, content management, personalization, and recommendations.
In this article, we focus on the first part of the cycle, Search. We walk through some real examples and search configuration strategies that create a production-level relevance. We break down then optimize the two pillars of search relevance:
First, we’ll show that these pillars are largely driven by how you structure and configure your data. To illustrate this, we’ll describe the basics: searchable attributes, faceting, and custom ranking – terms that we’ll define as we go along.
We’ll discuss important configurations like synonyms, language, and typo settings. Finally, we’ll demonstrate the importance of analytics and testing your most important queries to see that they return the desired search results.
When we say “relevance”, we often mean “textual relevance”, which refers to how a search engine compares the words of a query to your underlying data (search index) and returns matching results.
There are two questions to ask of relevance:
To illustrate what we mean by finding weak and strong matches, imagine a search that uses the simplest form of relevance – namely, letter-by-letter comparisons.
Here are four famous quotations (we already discussed this in part 1, but from a slightly different angle):
Textual matching can be exact or partial. A search for “be” matches the text of 3 records: record 1 (“be”), record 2 (“best”), and record 4 (“bed”). In this example, record 1 is the strongest because it is an exact match, whereas records 2 and 4 are weaker because they are only partial matches.
Continuing with this example, if we allow 1-word typos, then a search for “that” would find records 1 and 3, with record 1 (“that”) stronger than record 3 (“what”), which differs from the query by 1 letter.
If it were only that simple… Truth is, people who search are far more demanding than that. Search is not just about matching text. They want their results to feel intuitive. Here are some additional questions to ask:
To help achieve some of this, we need to consider the quality of the content / data and how best to configure it.
The content, or data, needs to contain more detail. Here’s an updated dataset:
With all that great data, there’s one more step: the engine needs to be configured. We’ll add some synonyms. Synonyms are not part of the data, they are part of an engine’s settings. Let’s add “best = greatest”. We’ll also configure the engine to match singular and plural forms (book = books) and tell it to tolerate typos and misspellings. There are other configurations to make, as we’ll discuss later.
The above quotations were used to illustrate what we mean by relevance. Now let’s look at a typical media / ecommerce example: a collection of books (to buy or for streaming).
Here, we can envision the book’s information (i.e., attributes) as follows:
To search, we don’t need to use the “cover image”, “price”, or “popularity”. And we’ll also ignore “description” for now. The other fields (“title”, “author”, “genre”) will be used to find the book. This process of selecting only some attributes helps the engine focus on searchable attributes, which makes your information more precise and guarantees relevant search results.
The other fields are present for other purposes. For example, for displaying in the search results (“price”, “image”) and to sort by (“popularity”, “price”).
The order of your searchable information is equally important. We call it Relevance Ranking. For example, if you type in “king” to find books written by Stephen King, you may see books with the word “king” in the “title” before seeing Stephen King books. To fix this, you’ll need to put your attributes in the below order (e.g., “author” above “title”, making the search engine look at author first):
You can also add “genre”at the top, so “king horror” will guarantee good results.
The point here is that you can select the priority of what gets searched. This is an important business customization, a unique choice for each bookseller.
To improve the matching, let’s add “description” as a fallback. However, we need to be careful. Long attributes like “description” can be noisy and generate false positives in relevance. Such attributes often contain too many easy matches. In such cases, you can create a “short-description” attribute that takes a subset of keywords from the “description”.
Lastly, let’s make sure that “title”, “author”, and “short-description” can be searched in the beginning or middle of the field. This enables a search for “peace” to find “War and Peace”, even though “peace” is not the first word in the title. This is not good for every attribute, for example “genre”. We use a special word “ (unordered)” to accomplish this.
Here we focus on the attribute “popularity”. We just need to tell the engine to use “popularity” to help order the records.
This idea of custom ranking needs some context. When a user searches for “king”, all records that have the word “king” in one of its searchable attributes will show up. Having “author” as a field will of course ensure this (regarding Stephen King).
The question is: Which Stephen King book should be at the top of list? Which second? That’s where popularity comes in. There’s no way to know which to show first, since they all match equally well, so we can order by popularity. We can also order by newest release.
Now, what if there is an unknown author that you want your users to know about. You can add another custom attribute such as promote-book, which is true or false, or a rating system with 1 to 5, 1 being very important to display to the users. Other custom ranking attributes: highest margin or most trendy. Or a combination of two or more attributes.
We describe this process as tie breaking, where we compare matches and put the strongest matches at the top and the weaker ones lower in the order. For example, if someone types in “ki”, the author’s who match “ki” exactly (for example, Ki Lynn), will show up higher than authors who only match partially. But if the user adds “ng”, making it “king”, Ki Lynn drops (as an inexact match) and Stephen King rises to the top. Additionally, with popularity as a custom ranking, Stephen King will most likely fill up the first 10 pages of results. (There are ways to avoid this last fact – where a popular author can hog the top places in the results. You can limit Stephen King to only 3 results, for example.)
Now your data is searchable and will rank properly. The search engine doesn’t need to know much more about your data. You’ve structured it and given it meaning by specifying how to search it. More can be done to manage certain particular situations, but what we’ve done is largely sufficient to go live with. But we can go one step further by creating synonyms and facets (i.e., filters).
Every customer has a set of unique words that can be satisfied by creating synonyms. In the case of books, there’s the word “novel” as a synonym of “book”. There are theaters and plays, authors and writers, and such mundane synonyms as “chairs” and “seats”, or “pants”, “slacks”, and “trousers”. Many relevant synonyms can come from a dictionary, but others are very specific to an industry or a company. They can also AI-power your synonyms.
Already alluded to, for books, adding attributes like “genre” and “author” help users drill down and single out collections of books based on these and other filters. Filters can work in the background or can be placed onscreen as facets.
Typos & misspellings
Your search engine should be able to find words that only differ 1 or 2 letters. Mistyping “shakspear” should find, nonetheless, “Shakespeare”. This is called typo tolerance.
Set the language of your search solution to the native language(s) of your users. If you sell only English books, you need to tell the search engine that your users will be typing in English. The search engine can then apply certain language-specific logic (such as determining plurals or separation of words). However, if your audience is also French, you might want to start adding French text to your data, or creating a different set of data – one English, the other French..
And you’ll want the search engine to distinguish between single and plural, and to not get bothered by “stop” words such as “the”, “what”, and “and”.
Finally, Analytics. You want to track the top 10 most typed-in queries. Then, test these top 10 queries and other analytics metrics to see if you are satisfied with the results. Also, avoid providing no results. Check to see if your top searches are returning no results, or only a small amount of results. And tracking user clicks and conversions.
Matching text is a critical starting point. To do this, you want to anticipate your users’ queries and ways of expressing themselves, and then you’ll structure your data to match the words of the most common queries. As we’ve seen, simple textual matching does not solve every problem. You also need features like filtering, ranking, attribute priorities, handling typos, synonyms, and other language-based characteristics to allow the search engine to read between the lines. Next step is to go beyond search and see how you can deepen your relevance with personalization, merchandising, browsing, discovery, and recommendations.