Settings Demo Store (for partial numeric matching)

[Seppmann]

I cannot figure out how to set ES settings so it will find more relevant products first

• All Attributes have search_weight = 1, except "name" (search_weight = 5)
• Standard Settings of Relevance configuration, Spellchecking, etc (except Fulltext Base Settings - Minimum Should Match -> 80%)

Search term
toaster red 77

Search results (name attribute, which has search_weight 5)

1. electric red toaster 7642 (48C/96T) 2 GHz (3.3 GHz Turbo) Box Sockel SP3 TDP 225W
2. electric red toaster 7552 (48C/96T) 2 GHz (3.3 GHz Turbo) Box Sockel SP3 TDP 200W
3. electric red toaster 7552 (48C/96T) 2 GHz (3.3 GHz Turbo) Tray Sockel SP3 TDP 200W
4. electric red toaster 7713 (64C/128T) 2.0 GHz (3.675 GHz Turbo) Tray Sockel SP3 TDP 225W

So why is search result number 4 not more relevant than result 1 to 3? All names of those product match the exact same search terms -> toaster red. Only that search result number 4 also includes search term "77" in electric red toaster 7713
I dont get why its not showing then as first result?! Any ideas?

Thank you!

[Seppmann]

Hi,

to figure out my problem I test on M2.4.3-p2, latest Elasticsuite. No 3rd Party Extensions (except ElasticSuite). Sample Data is installed. What settings I have to set to receive same behaviour as demo shop please?

Local System (standard settings, except Fulltext Base Settings - Minimum Should Match : 80%)

Demo Shop
http://demo.magento-elastic-suite.io/index.php/catalogsearch/result/?q=sprite+yoga

I need same behaviour on LOCAL demo shop - how can I receive that please?

Thanks and best regards

Sebastian

[Seppmann]

Hi there,
does anyone know what the ES settings for the demo shop are?
--> http://demo.magento-elastic-suite.io

I'm getting different results on local demo store M2.3.4-p2, demo data, latest ES. I try to figure out how to solve problem in first comment like that hopefully

Thanks and best regards

Sebastian

[rbayet]

Hello @Seppmann,

The issue you are encountering is that by default we don't have an analyzer that separate series of digits in number in "chunk" like you seem to expect that 7713 would be indexed as "7", "77", "771" and "7713".

The closest we have is the "reference" analyzer which is applied on SKUs to break alphanumeric skus into digit and letters parts, for instance "WB01" will indeed by index as "WB01" and "WB" and "01".

I'm assuming the "7713" in "electric red toaster 7713" is your product name ?

Regards,

[Seppmann]

Hi @rbayet ,

thank you so much for your answer! You are right, we have different models/model types of products that slightly differ.

Like
electric red toaster 7713
electric red toaster 7743
electric red toaster 7845
etc

So customers that look especially for a specific model "type" might just search for "electric red toaster 77" to get all the "77" types. I know its kind of our own logic..and so for us the expected behaviour would make sense.
So fuzziness for example wont be applied on "digit only" terms in search? Is there any way we could achieve a behaviour like that?

Thanks and best regards

Sebastian

[rbayet]

Hello @Seppmann,

Fuzziness will not be a perfect solution, since its job is to handle typographic mistakes by allowing character changes (character swaps, deletion, addition), and it will at most allow two character changes/addition in a term.

But while searching for the ideal solution, you could try to :

• change the fuzziness prefix from 1 to 2 (so when searching for "77" or "775", it will not try to find alternative for the first two "7")
• change the fuziness value from AUTO (which will be either 0, 1 or 2 depending on the length of the term) to 2, this could allow to match "7713" or "7743" when just searching for "77"

Bear in mind that the fuzziness settings will now apply to every search term, so you might have some wonky side effects on other search queries.

In the Magento 1 version of Elasticsuite, we used to have an autocomplete search allowing more partial matches, it relied on the edge n-gram tokenizer, but we moved away from that because having different results between the autocomplete and fulltext search results for the same search query is a bit perturbing (that, and performance issues).

But you could try playing with the Elasticsearch analyzers, having a dedicated attribute/mapping field containing those product references and allowing for partial matching with some custom analyzers.
If you also have alphanumeric reference (like 77BC, 77B1), I would invite you also to have a look at these explanations (Warning: it's dense.)

Regards

[Seppmann]

Hi @rbayet,

thank you very much for your suggestions! I tried the fuzziness prefix/value settings but no luck. The search results wont change..
And unfortunately we cant add a product attribute for the "type" to apply ES analyzers to that attribute/field :(

So for now I dont see how we could solve this...

Thank you and best regards!
Sebastian

[romainruaud]

@Seppmann did you have a look on this comment ? : #970 (comment)

This seems to be the proper way to handle "partial matching" on fields. You could replicate this logic to your product field that is containing numbers.

Regards

[Seppmann]

@romainruaud Thanks a lot! I will check it out!

[romainruaud]

I close, this question is old and has been answered.

Regards