Concepts / Managing results / Override engine defaults
May. 10, 2019

Override Engine Defaults

Don’t override engine defaults unless absolutely necessary

There are times when you’ll want to dig deeper into how the engine functions. Not out of curiosity, but because something’s not right about your results, and you think tweaking the engine will fix the problem.

Before taking that step, let’s look at what you can do first.

  • The first suggestion is to review the content of your data.
  • Next verify that both searchable attributes and custom ranking are well configured.
  • Next, verify that you’ve chosen the best search and index settings for your data and needs.
  • Next, take a look at your analytics data for insights into what can be improved in your data or settings.
  • Finally, take a look at our troubleshooting guide.

If you’ve gone through these steps, here is a list of engine-level settings that you can look at to address persistent, “unsolvable” problems.

Note: These settings are global, so you’ll need to be very careful - every change impacts every search. With a small tweak, customers often solve one problem - only to create other problems. Or worse, they undermine their entire search solution.

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 a full-word match before displaying results.

By default, Algolia uses a “prefix last” logic, where only the last word in a query is treated as a prefix; all other text in the query must be a full match.

You can change this and get back more results by making all text in a query match on prefix.

Advanced Syntax Overview

When Algolia’s advanced syntax is enabled (advancedSyntax), search queries are treated differently in two significant ways.

  • Phrasal Queries
  • Excluding Words

Note that These behaviors are enabled together by Advanced Syntax; they cannot be enabled individually.

Phrase Queries - Matching within quotes

Terms enclosed in quotes must match exactly. For example,

1
sparkly blue "iPhone case"

would return only records containing the exact string, “iPhone case.” However, “sparkly” and “blue” could occur anywhere in the record; their location and order are not constrained.

Note that typo tolerance is disabled inside the quotes.

Excluding Words

The negative operator is a minus sign, pre-pended to a term in the search query that should be excluded from results. For example,

1
search -engine

will only match records that contain “search” and do not contain “engine.”

API Reference AdvancedSyntax

Enable search on non-alphanumeric characters

By default, separators are not indexed, meaning they cannot be searched. The query “yahoo!” becomes “yahoo”.

Here is a non-exhaustive list of separators frequently used by our customers:

1
!#()[]{}*+-_一,:;<>?@/\^|%&~£¥$§€`"'‘’“”†‡

These usually are not indexed. To be able to search for “Google+” or “C#”, you’ll need to override the default and ensure that + and # are indexed like all letters.

API Reference SeparatorsToIndex

Change the Ranking Formula

Reorder the criteria

This is rarely done, and we strongly discourage you from doing this, unless you understand the global impact of the change. While changing the ranking formula might solve one query or a few queries, it might cause unexpected consequences on all other queries.

The most common change, and least risky, is to put Words at the top. This is done when dealing with long docs and long queries, where you care about how many words match - the more words that match, the more likely the document is relevant. This works in connection with optionalWords. We do this in our product DocSearch.

Adjust the Exact criterion

The exact criterion behaves like a counter: If an exact match occurs in an attribute, the exact counter is incremented by 1. The higher the exact count, the higher the record is ranked.

There are several behaviors to Exact:

By default, an exact match is where a full word in a query is matched fully and without typos to a word in an attribute. In contrast, an inexact match is one with typos or matched by prefix.

“star” is an exact match to “Star Wars”. “Sta” is an inexact match to “Star Wars”

Additionally, synonym matching and plural/singular matching are considered exact.

Finally, single-word matches on single-word attributes are given higher ranking over multi-word exact matching.

You can adjust one or more of these behaviors.

Adjust the Proximity criterion

By default, adjacent words are ranked higher than words with one word in between, and words with one word between them are ranked higher than words with two words in between, and so on. You can override this default behavior by increasing the minimum proximity, up to 7.

For example, consider the query “javascript framework”. If you set minProximity to 2, two records containing respectively “JavaScript framework” and “JavaScript charting framework” will get the same proximity score, even if the latter contains an additional word between the two matching words.

API Reference MinProximity

Did you find this page helpful?