Prefix Searching

Prefix matching is central to Algolia’s as-you-type search experience. It enables the engine to start matching records based on partial words.

For example, records containing apricot are returned as soon as a user types a, ap, apr. There’s no need for the engine to wait for full-word match before displaying results.

This is already useful in avoiding insufficient results. But you can also use prefix matching to bring back even more results.

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

You have 3 options:

• prefixLast (default) - where only the last word is a prefix, and the rest are treated as full words
• prefixAll - where all separate text in a query is treated as a prefix
• prefixNone - disables all prefixing

Additionally, you can turn off prefixing on some attributes using:

• disablePrefixOnAttributes

queryType=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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 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 5.
"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 isn’t performed on them.

Use cases for prefixLast

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

queryType=prefixAll

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

1
2
3
4
5
6
7
8
9
// 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 query because it has “beef jerky” - jerky matches on je and beef matches on b. Note that the order of the matched words in the result doesn’t 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 isn’t recommended for the majority of use cases - it yields counterintuitive results and has a negative impact on performance.

queryType=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 the earlier examples:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 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

Using prefixNone isn’t recommended for most 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
"+1-867-5309 +1-123-4567 +1-555-5555"

disablePrefixOnAttributes

You can adjust the 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 ecommerce 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 turn off 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.