Technical buyer’s guide to site search

Consumer-grade search is one of the hardest features to get right as it includes multiple disciplines (UX, speed, relevance, personalization) while always being compared to massive players like Google and Amazon. It needs to be a top-notch tool for your users, your developers and your business managers.

How to do that? This is where the guide comes in. Use our considerations to help you make the right decision when it comes to picking your next search API.

If you were drawn to this guide, you probably know that search is a mission-critical part of your application: in domains like ecommerce, introducing a search bug can cost millions of dollars. Search is also one of the hardest features to get right, both because users benchmark search experiences against Google and Amazon, and because search is a balance of multiple disciplines, not limited to UX, relevance tuning, and performance optimization.

Query results must update with each new character entered. Search must intuit what users are looking for, if not outright predict their intentions, which brings all manner of user analytics and data — and, of course, AI — into the mix.

At the center of a good search experience lies a powerful search engine that regularly performs incredible feats of computation. Given that search is a competitive differentiator, your next step is to learn as much as possible before starting to evaluate tools to implement. 


This short guide will tell you:

• What constitutes consumer-grade search
• User expectations for search, both in terms of performance and the feature set
• Where latency and computation add time to a query
• How to personalize a user’s experience
• How to please both end users and developers
• And other considerations

 

What makes a search engine powerful?

When we talk about search in this guide, we mean consumer-grade search, which adapts to the user, not the other way around. It matches a music lover with a pair of headphones she’ll love, tolerates misspellings, and knows that “football” in the United States isn’t the same as in Brazil. Consumer-grade search is ultra fast, works on any device, and almost universally provides the most relevant results. This distinction from enterprise-grade search, which scans intranets, applications, and workplace tools, is important because the emphasis is placed on the consumer’s high expectations for speed and relevance.

And, by the way, consumer-grade search no longer applies to just consumer-facing applications. Today’s business application users have become just as demanding, in part because many business apps are distributed in app stores and some even compete directly with consumer versions.

Speed

When you search for “Robinhood” on Google, it’s only a fraction of a second before you’re served 89 million results. In that short time, those nine letters traveled hundreds of miles to a data center where servers queried index after index to find and rank matching records, then sent those 89 million results hundreds of miles back.

Speed is a function of computation and latency. How fast can search figure out what a user wants, and how quickly can it bring it back to the user? Anything more than a couple of hundred milliseconds and the user’s interest will begin to sour.

f(computation,latency) = speed

Latency

Distance is the most apparent input for latency. Even if you’re using the best fiber-optic cables, a hundred-mile journey is still faster than a thousand-mile one. If you do business in multiple regions, having only a centralized location increases latency for distant clients. Even getting a request to your data center can be a complicated journey: load balancers and DNS services often send requests hopping from network to network before properly resolving them. And although latency is mostly a networking problem, it can also refer to which sorting algorithm is used or how a database is architected.

Computing power

The other half of the equation is computing power. There is a direct relationship between clock speed and how quickly something can be indexed and searched. Hardware, storage techniques, data structures, merging, resource provisioning, and many other variables all act in concert to erase milliseconds of time.

The details matter: how distributed the architecture is, whether it runs on bare metal (removing the performance costs of virtualizing servers), whether the indexing process presorts results or requires them to be sorted at query time.

Of equal importance is prioritizing indexing versus search. One strategy is to separate these into two processes with different CPU priorities so that, for example, search always preempts indexing. Additionally, indexing and search normally perform numerous disk I/Os. In an ideal world, search doesn’t perform any disk operations, which means all the data needs to remain in memory. This ensures that search engine speed is not impacted by indexing operations.

The last factor to mention is organizing a collection of words in an index. Lists or maps may be the intuitive data structure, but tries are actually the best.

To suggest an autocomplete word, a trie’s branching layout of root-child nodes can quickly be crawled with a partially completed query. For example, Figure 1 shows a radix tree structure for “fast”, “faster”, “test”, “toast”, “toaster”, and “toasting”. Each branch represents the minimal amount of information necessary to identify the search query, as opposed to hash tables, which require a hash function to be computed.

When you’re evaluating a search engine, ask:

• What type of hardware is it running? Will it be virtualized or bare metal?
• Where will I be storing my data? Is it distributed well enough?
• Am I using resources such as RAM, CPU, and disk most efficiently?
• What data structure will my database indices use?
• What is the fastest method to query it?
• If processing power is limited, will it be prioritizing indexing or search?
• How quickly can I feed in fresh data?

Relevance

Our expectations for search results have changed a lot in the last decade. For example, we’ve done away with the archaic use of the Enter key to initiate the search process.

Now, the user expects to not only see a list of matching results instantaneously, but to have those results be ranked in perfect order of relevance. Consumers used to having it all on page one of their Google search results want similar performance from on-site and in-app search.

Relevance makes sure that all records matching a query are found. However, what does it mean to “match a query”? Simplistic text matching isn’t enough if you’re designing a search engine for the modern consumer. Intelligent matching takes into account typo tolerance, partial word matching, spatial distance between matching words, the number of attributes that match, synonyms, natural-language characteristics such as stop words and plurals, geolocation, and many other aspects that match “intuitively” not just what the consumer enters but what they expect from search in the Google era.

Figure 2: Counting the operations needed to transform a word

Finding records is only part of the story. Once you have the “right” records, another aspect comes into play: how the records are ordered, or ranked.

Ranking

The more innovative addition to search is to order results by relevance, which is a careful combination of ranking, text matching, and user attributes. A simple “Robinhood” Google search would use a “naive” ranking algorithm, pushing results with more instances of the word to the top.

An intelligent search adds dimensionality to the calculation to account for the text-entering (or speaking) human; it can decipher whether the user is referring to the investing app or the heroic outlaw. These contextual data points add complexity to the algorithm, requiring more-sophisticated ranking methods that leverage analytics and user behavior.

The underlying algorithms that calculate the ranking exist for different use cases. Algorithms like TF-IDF and bag-of-words were designed to search unstructured documents. Consumer-grade search benefits from structured data. Amazon recommending the right book requires ranking algorithms to factor in data attributes such as author and rating.

If you’re looking to give users relevant results, ask:

• Which attributes are descriptive and which are irrelevant?
• Can I understand the intent behind a query (e.g., is the user looking for new information or do they know an item exists)?
• What scoring method will I use to rank?
• What contextual data will I collect?
• How will I weigh it and why?
• Can I inject data points relevant to business objectives?

 

What makes a search engine good for your team?

Search is critical to the user experience. It is the preferred, and more often than not, essential, channels of interaction with applications and websites. Search is clearly valuable to the user, but before making your search-tool decision based strictly on the user experience, you’ll want to consider what will make search valuable for your team.

Implementation and maintenance

A fundamental question when buying software is whether you implement it yourself, have it hosted, or do something in between. Yes, you want the power of fully buildable and extensible software, but at what cost?

Do you want to provision for servers and engineers to operate those servers, as well as take into account the cost of hosting and maintenance on your own? Can your team keep the software up to date and handle backward compatibility?

Hosting, managing, and maintaining search clusters is complex, encompassing everything from tackling security issues to limited configuration options to visibility into the stack. Properly securing the entire stack requires a knowledgeable and experienced team. From physical access to servers to OS and network security, every bit of your infrastructure needs constant attention.

Next, there is fetching and indexing of data. If you go the API route, you can expect to have to extract data from your source, format it in JSON, and push it to the provider for indexing. That means you’ll want to make sure your provider plays nicely with your tech stack. An API client for your preferred language would be good, a regularly maintained API client would be better. Supporting your development framework is great, and so is a native extension for your ecommerce back end.

When you’ve figured out indexing, the next step is configuring the relevance of the engine. Unlike enterprise-grade search, which has a confounding number of knobs, switches, and displays for processing large unstructured documents, consumer-grade search is about connecting people with products and content. It seems simple: all that needs to be configured is what is constituted as relevant. But consider whether you have the resources to build your ranking formula from scratch and define a text relevance strategy that functions and is performant for your use case. To do these things, you’ll need a highly skilled team and a significant amount of time.

When you’re deciding where to implement your search, ask:

• Can I spare engineering resources to operate this?
• Can I stay up during peak traffic? Do I have enough servers?
• Where will my data come from?
• Can I standardize data formatting?
• How do the true costs of hosted and self-hosted options compare?

Lifetime

By necessity, all software needs to be future-proof: the pace of innovation threatens any product with obsolescence every few years. But what does future-proof mean in the context of search?

A baseline standard for any evaluation is software that can facilitate data-driven decisions. At the very least, a search engine needs to have an insights layer. Combining reports with metrics such as click-through rates, query counts, most popular queries, and queries that yield no results can highlight user behavior.

With the advent of AI, the possibilities for predicting user intent and recommending and personalizing products and content are both endless and necessary. At the same time, in a privacy-first world, AI must be leveraged with the utmost care and transparency to your team. Optimizing an AI algorithm is difficult but crucial. 

Perhaps the most inarguable inevitability of all is voice search. Physical typing interfaces are more often than not supplemented by voice search to provide a less frustrating user experience. Of course, voice search has only become possible through progress in the realm of natural-language processing (NLP), circling back to artificial intelligence.

When you’re planning to implement or improve your search functionality, ask:

• Can this search engine support new markets I want to expand into?
• Does it offer the scalability and language support I need?
• Will it keep pace with advances in AI and NLP?
• Can I analyze user behavior in a way that won’t violate user privacy but will give users the most relevant results?

Developer experience

Search engines have three basic user groups: end users, business users, and developers. While end users demand speed, relevance, and a delightful UX, developers prioritize clarity, productivity, customizability, and flexibility of the engine, as well as elements of developer experience (DX) such as good documentation, support, and the ability to work on things that matter.

A good DX means easily manageable security, minimal setup, and easy-to-understand, flexible tools. It means, for example, that you’re looking for comprehensive libraries that will help implement search features; bonus points if these libraries are in your preferred frameworks.

It also means not having to jump on IT tickets multiple times a day. In most businesses, people who own search data and want insight into it are not developers but product managers, digital strategists, ecommerce marketers, and omnichannel strategists. Will your search tool enable these business users to understand and update the relevance formulas and, more importantly, look at search analytics to get insights on those clicks and queries? Compare this type of agility with having to run to your developer team for every change in search formulas and every offering.

Good developer experience equates with developer productivity, which, with engineering salaries and talent shortages at historic highs, translates directly into higher-quality products and lower total cost of ownership for internal applications.

When you’re thinking about DX, ask:

• Which front- and back-end languages are supported? Which have libraries?
• Can the API client easily connect to my apps and tools?
• Is the documentation thorough? How frequently is it updated?
• If the product is open source, how active is the community?
• Are there native integrations into my web app framework?
• Will the search tool support business teams so my team doesn’t have to?

Parting words

Development teams often delay building search because of a lack of confidence in getting it right and the fear that it will take longer than expected. Yet, the quality of an application’s search has a big influence on the perception of its overall quality. Digital search continues to evolve, setting ever-higher expectations for users. To afford them the best service, your search functionality must be fast, personalized, and ultra relevant.

To accomplish this, think total cost of ownership, developer happiness, flexibility, and availability to all your search stakeholders, including those on the non-engineering side. While the combination of these factors can make search a risky area of development for business and consumer applications, looking at the full, end-to-end, picture of what search means for your application and your team will help mitigate the risk — and choose the right tool for your use case.

 

About Algolia

Algolia is the world's only end-to-end AI search and discovery platform. Our engineers invented a breakthrough use of AI to create exponentially better search & discovery. Algolia's proprietary NeuralSearch tech combines vector-based natural language processing & keyword matching in a single API. Algolia powers 1.75 trillion search requests a year or more than 30 billion a week enabling more than 17,000 customers in 150+ countries to build blazing-fast and relevant search and discovery experiences for their in-app users and/or online visitors using any web, mobile or voice device – by surfacing the desired content instantly and at scale.