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 count is incremented by 1. The higher the exact count, 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 in another, that’s also 2 points.
The exact score of a record is different than the Words criterion score because the 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 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 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.
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 count is with an exact match of the entire attribute. Single-word queries only increment the count 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. Consider doing this if you don’t have many important single-word attributes and want matches on single-word and multi-word attributes to rank evenly.
Disabling exact on some attributes
You can remove the exact criterion from attributes with the disableExactOnAttributes setting. As a result, these attributes no longer take part in the exact computation.
If you have an extensive description attribute (making it more likely to have an exact match), consider removing exact matching on this attribute. By doing so, you favor exact matching on other, more meaningful attributes such as title or name. This gives attributes with shorter content more control over ranking than those with more extensive 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”. Multi-word synonyms aren’t counted as exact matches. You can change this default using alternativesAsExact. In practice, there is rarely a good reason to do this.
