Icon relevance white

Prefix Search

Last updated 01 August 2017

Algolia performs prefix matching because it was designed from the ground up for user-facing, as-you-type search experiences. This means that records containing apricot are returned as soon as a user types a, ap, apr — no need to wait for full words before displaying results.

Prefix Search Options (Index-Level)

Algolia’s prefix search is highly configurable, with three available queryType modes depending on the use case. Every index can be configured independently.

prefixLast (default)

By default, Algolia uses prefixLast to provide an as-you-type search experience — only the last word in a query is treated as a prefix.

// Consider the following sentences.
1: "Let's play Jenga tomorrow."
2: "Check out these fighter jets flying over my town!"
3: "Beef jerky is a great source of protein."
4: "Jack and Jill went up the hill."
5: "Jacqueline bought me a jet black iPhone."

// Matches for "j" are found in all five sentences.
"j" ➡️ Jenga, jets, jerky, Jack, Jill, Jacqueline, jet

// Matches for "je" are found in sentences 1, 2, 3 and 4.
"je" ➡️ Jenga, jets, jerky, jet

// The only match for "jet bl" is in sentence 5.
"jet bl" ➡️ jet black

In this mode, all query words except the last one are considered complete; prefix search is not performed on them.

Use Cases for prefixLast

This is the default prefixing behavior and is encouraged for the majority of use cases.

prefixAll

This setting treats all query words as prefixes. Consider the last sentence from the previous example:

// Consider the following sentences.
1: "Let's play Jenga tomorrow."
2: "Beef jerky is a great source of protein."
3: "Check out these fighter jets flying over my town!"
4: "Jack and Jill went up the hill."
5: "Jacqueline bought me a jet black iPhone."

// Matches sentences 2 and 5
"je b" ➡️ jet black, beef jerky

Sentence 2 is also returned from the above query because it contains “beef jerky” — jerky matches on je and beef matches on b. Note that the order of the matched words in the result does not need to be the same as the order of the prefixes in the search query. However, the order is taken into account by ranking sentence 2 below sentence 5 in the result set.

Use Cases for prefixAll

  • If users are searching in a domain where many words are commonly shortened, prefixAll could be suitable — for example, “spec review” instead of “specification review.”

  • This value is not recommended for the majority of use cases — it yields counterintuitive results and has a negative impact on performance.

prefixNone

This setting treats none of a search query’s words as prefixes; all words are considered complete and only records containing matches for every query word will be returned.

Returning to our earlier examples:

// Consider the following sentences.
1: "Let's play Jenga tomorrow."
2: "Check out these fighter jets flying over my town!"
3: "Beef jerky is a great source of protein."
4: "Jack and Jill went up the hill."
5: "Jacqueline bought me a jet black iPhone."

"j" ➡️ No results.
"je" ➡️ No results.
"je bl" ➡️ No results.
"jet bla" ➡️ No results.

// Matches sentence 5 because both query words are present in the sentence.
"jet black" ➡️ jet black

prefixNone not recommended for most use cases, because no results are displayed until entire word matches are found. We typically recommend an instant search, as-you-type experience.

Use Cases for prefixNone

For a use case like searching SKUs or phone numbers in bulk (perhaps a merchandising or bulk SMS delivery tool), prefixNone could be suitable. For example, imagine the following query in which an administrator searches for messages that have been delivered to all three numbers:

"+1-867-5309 +1-123-4567 +1-555-5555"

Prefix Search Options (Attribute-Level)

disablePrefixOnAttributes

The engine allow for the configuration of prefix settings per attribute — some attributes can retain the flexibility of prefix search, and others can be more strict, allowing for only exact matches.

Use Cases for disablePrefixOnAttributes

  • An e-commerce shop with SKU search would only want to return exact matches. Very similar SKUs might be wildly different products, so exactness is important. It would be important to disable prefixing on the SKU attribute while keeping prefix search for user-facing attributes like title or description.
  • In the case of a phone number search, a user searching for “867-5309” doesn’t find “867-5308” relevant just because it’s one digit away. A user typing phone numbers likely already knows the full number, and suggestions would not yield more relevant results.

Changing Prefix Behavior

Prefix behavior can be set at either indexing time or query time with the queryType parameter.

At Indexing Time

index.setSettings({
  queryType: 'prefixLast' 
  //queryType: 'prefixAll'
  //queryType: 'prefixNone'
});

At Search Time

index.search({
  query: 'query',
  queryType: 'prefixLast'
  // queryType: 'prefixAll'
  // queryType: 'prefixNone'
}).then(res => {
  // console.log(res);
});

What’s next

Continue building your Algolia knowledge with these concepts:

© Algolia - Privacy Policy