2.11.4

📦 Feature

[Experimental] Ability to finetune single term queries exact maching

When an exact match query is performed with multiple search terms, the targeted attributes/fields are :

1. the searchable attributes/fields in their 'standard' analyzed version with their own search weight

2. the searchable attributes/fields in their 'shingle'/phrase matching version with their own search weight multiplied by the phrase match boost value

3. the searchable AND sortable attributes/fields in their 'sortable' version with their own search weight multiplied by twice the phrase match boost value

The logic behind that query construction is to

1. collect all indexed documents (products, categories) containing the individual search terms in a strictly exact or "stemmed" version (ie, not differentiating between the singular and plural form of a word - grill vs grills for instance - or between a noun/verb and its participle present form - hammer vs hammering for instance)
2. boost (possibly heavily) the documents that contain the search terms in a strictly exact or "stemmed" version close to one another
3. boost (possibly quite heavily) the documents that have an attribute/field containing strictly exactly the search terms and only the search terms in their indexed value (for instance, when a user searches for a product name without any word missing or any typo/approximation)

Now, when an exact match query is performed with a single term, there is a slight change with regards to rule 2. : the searchable attributes/fields are targeted in their 'whitespace' version, but still with their own search weight multiplied by the phrase match boost value.
Considering that the 'whitespace' version of attributes/fields does not have any stemming component, that means that exact matching for single term searches puts a huge boost on product or categories that contain exactly the word the user typed, compared to product or categories that contain only the "stemmed" version of that word.

This is not an issue in most cases, but you could find yourself in a situation where you would like that this emphasis on strictly exact matching be a bit more relaxed, particularly in the context of matching categories in the autocomplete.
For instance, let's imagine you're selling grills, grill tools, grill accessories. You might want that when a user searches either for "grill" or "grills" in the autocomplete, the same list of categories appear in the same exact order: "Grills", "Grill Tools", "Grill Accessories".

It is now possible to achieve that behavior with new experimental settings located in "Elasticsuite > Search Relevance > Relevance Configuration > Exact Matching Configuration" :

• "[Experimental] Enable single term custom boost values" : Yes/No, enables customizing the boost value for rules 2. and 3. when a single term is searched. Defaults to No.
• "[Experimental] Single term phrase match boost value" : the boost value that will replace the phrase match boost value applied to 'whitespace' version of attributes/fields. Defaults to 10. It's possible to set it to 0 to totally disable the rule 2.
• "[Experimental] Single term sortable matches boost value" : the boost value that will replace "twice the phrase match boost value" applied to 'sortable' version of attributes/fields. Defaults to 20. It's possible to set it to 0 to totally disable the rule 3.

Those three new settings can be changed only for a specific scope, ie a specific search query type on a given store view.
You are thus allowed to change the native behavior for categories results in the autocomplete box without affecting the products search.

What's Changed

• Add observer to load mandatory attributes on category collections by @nige-one in #3044
• Experimental single term exact matching relevance by @rbayet in #3050
• Only Add Frontend Tracker Blocks If Config Enabled by @pykettk in #3051

Full Changelog: 2.11.3.3...2.11.4