These steps are common to all major search engines. Notably, Google, eBay, Bing, and Amazon apply unique algorithms and search different data for different purposes, and end up with different results.

Quixey is particularly unique among search engines. We invented a new type of search – functional search – specifically for apps. In this post, I’ll explain what standard search engines do and what we do differently.

Step 1 – Receive the user’s query.

Receiving the user’s query isn’t as simple as receiving what the user has typed. Sometimes external factors influence the query’s meaning – factors like the user’s country, browser, language, or device.

This is particularly crucial for an app search engine and functional search. For example, whether users search from an iPhone or an Android phone should influence how the search engine understands their queries. Moreover, someone in Russia may want different apps than someone in the United States.

Step 2 – Parse the query to construct a ‘database query’.

The old-school, simple method of parsing a query is to split it into individual words. Sometimes this involves removing ‘stop words’ (the, is, at, which) and the ‘stem’ of the query – for example, “help me to do my taxes” could be simplified into ['do','help','me','my',taxes','to'], or even something as simple as ['tax'].

As you might imagine, this is a dangerous strategy. It ignores the fact that user intent is not always a direct function of the individual words entered by the searcher. When searching for apps, “convert mp3 to flac” is a very different query than “mp3 AND flac.” Likewise, “tax” and “do my taxes” mean very different things. Misspellings, extra words, missing words, and unrelated words will severely throw off a search engine that doesn’t make this distinction.

It is a huge task to properly parse queries for your database. Most other search engines ignore the problem or solve it poorly. A query like ‘restaurants’, when interpreted incorrectly, will return so many results that the search engine won’t be able to score them all. Linguistics, intent-analysis and data considerations make this step extremely difficult.

Step 3 – Using the database query, assemble the ‘consideration set’ of results to consider for scoring.

Once the query has been transformed for optimal searching, you can use your new ‘database query’ to query the database. It is worth noting that the database query might have virtually no text in common with the keywords the user entered.

You can then select a consideration set based on the database query. The consideration set defines which results are worth considering. For example, queries like “paleontology” might generate a reasonably small consideration set, but queries like ‘racing games’ can generate consideration sets so large that scoring is impractical. That means it’s really important to parse queries properly in Step 2, as well as use algorithms that form manageable consideration sets.

Not only must the consideration set be small enough, but the algorithms used to generate it must be computationally efficient.

Step 4 – Score the consideration set.

A CS grad student writing a paper about ranking can win a Best Paper award even if his algorithm takes an hour to run a single query. Unfortunately, a commercial search engine can’t tell the user to wait hours for results. This creates a trade-off, often not discussed in academic circles, between the result response time and quality of results. The quality of results also correlates with the number of results considered.

Scoring is often the most computationally costly part of a search. Scoring results works as follows:

1. Map each result to a set of (usually numerical) features, like the keywords’ frequency in the description.
2. Apply a function to these features to calculate a meaningful score.

Competitors in the search space are differentiated by the data they access and the algorithms they use to score results. Quixey stands apart because of the wealth of data we use to score apps, and the precision of our scoring algorithm.

This combination is so successful because we invented functional search specifically for apps. Apps have a different set of important features than static web pages, so the standard text features sought by traditional search engines aren’t effective for finding apps. What makes one web page a better result than another is meaningless for apps, which often lack official home pages.

For example, the number of times an app is downloaded is more important than how many people link to its homepage. Likewise, the number of reviews might not be useful, because this metric strongly favors older apps.

Step 5 – Present results to the user based on the scores from Step 4.

It might seem easy to present results to the users by sorting by score. Unfortunately, this problem is more complex. What information should you display, and how do you organize the results? Should a result with a score of 49.9999 really display below a result with a score of 50.0000?

A simple ‘title text-match’ app search works fine when users knows the names of the apps they are looking for. However, our data shows that 86% of queries describe functions, not app names. People need to be able to find apps even if they don’t know what those apps are called.

Any type of ranking system is quite difficult and requires a lot of expertise. Our search requires collecting the right data, analyzing queries, effectively using and building a database, scoring based on the right features, and presenting the results in an intelligent way that helps users determine what they want.

In my next post, I will go into more detail about how Quixey does search differently.