Adjusting the Exact Criterion
The exact ranking criterion counts the number of exact matches between a query and a record. By default, an exact match occurs when a full word in a query matches a full word in an attribute completely and without typos. An inexact match has typos, or only matches a prefix. For example:
- “star wars” is an exact match for “Star Wars”
- “Stare wa” is an inexact match to “Star Wars”
- “Star wa” is an exact match to “Star”, and an inexact match to “Wars”
Additionally, synonym matching and singular/plural matching are considered exact. Thus, if a synonym of a word matches exactly, it’s considered an exact match for purposes of the exact criterion.
Single-word matches on multi-word attributes aren’t considered exact matches by default. For example, on the single-word query “road”, only a record with an attribute equal to “road” would be considered an exact match. A record with an attribute containing the term “road trip” wouldn’t be an exact match in this case.
How is the Exact criterion computed?
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 counter, the higher the record is ranked.
The counter works with single or multi-word queries. Every word is treated separately. Thus, if the query contains two words, and they both match exactly in the same attribute, that’s 2 points, 1 for each match. If the first word matches in one attribute, and the second matches in another, that’s also 2 points.
The exact score of a record is different than the words score, because the words criterion takes into account inexact matches. The exact score of a record may be less than the number of query words because of inexact matches, or if you’re using the optionalWords setting.
For example, on the query “Apple iPhon X”, a record containing “iPhone X” (and not “Apple”) would have a words score of 2 and an exact score of 1, even though there are three query words. This is only possible if optionalWords includes “Apple”, since by default, a record must contain all query words in order to be considered a match.
One caveat to keep in mind is that exact words are only counted once per record. If the same word has 10 exact matches in a record, whether it’s in the same attribute or not, that word of the query still gets only 1 point. This means exact is always a number between 0 and the number of words in the query.
With all that in mind …
What kind of adjustments can you make to the Exact settings?
Considering exact on single-word queries
By default, the engine treats single-word queries differently than multi-word queries. When there’s a single-word query, the only way to increment the exact counter is with an exact match of the entire attribute. Concretely, single-word queries only increment the counter when they exactly match single-word attributes.
You can change this default and make single-word queries behave similarly to multi-word queries by setting exactOnSingleWordQuery to word. You might want to do this if you have few important single-word attributes, and you want matches on single-word attributes and multi-word attributes to rank evenly.
Disabling exact on some attributes
You can disable the exact criterion on one or more attributes using the disableExactOnAttributes setting. As a result, the disabled attributes no longer take part in the exact computation.
If you have a large description attribute where you’re likely to have an exact match occur, you might want to disable exact matching on this attribute. By doing so, you favor exact matching on other, more meaningful attributes such as title or name. This provides attributes with shorter content more control over ranking than attributes with larger content.
Changing the default meaning of exact
By default, the engine counts singular/plural and single-word synonym matches as exact matches. For example, if you have a synonym between “swimwear” and “swimsuit”, a search for “swimwear” will count as an exact match on a record with the word “swimsuit”. Multiword synonyms are not counted as exact matches. You can change this default using alternativesAsExact. Keep in mind that, in practice, there is rarely a good reason to do this.
