SXA Search Boosting rule not having affect on Azure site

Question

I created a search scope for boosting based on a rule.

I set the search box and search result scope to use this boosted search.

Works completely as expected locally - but when I deploy to azure the boosting seems to have no affect at all.

I have rebuilt the index, and have checked that the navigation title field is in the index by setting a nice random value in that field for a page, and after publishing confirms that it is picked up in the search results.

There are no errors in the log on executing the search (querying the logs in application insights).

I read in another post that potentially azure search does not handle contains properly - but even changing to "is case-insensitively equal to" does not work on a single word.

Here's an example - where the pages with the word Sample should appear at the top of the list.

The search query according to logs is:

[sitecore_sxa_web_index]: &search=(sxacontent:(/.holiday./) AND (template_1:(53d07dd880b148cf8e2cbc36cff7dc5b) OR template_1:(dc876a19c0de42788ef491ecb3c82b79) OR template_1:(71f7269a47484737aec3924ddf328142) OR template_1:(3e4af7d2a9e14357bca75108dc7a5416) OR template_1:(ac2a523742c84f5490c6dbe51f9d6a0c)))&$filter=((search.ismatchscoring('navigationtitle_s:(/.holiday./)^49', null, 'full', null) or not (compat_prefix__name_s eq '')) and latestversion_1 and (path_1/any(t:t eq 'c57e57c57b1d47afaeac3b9532763b10')) and searchable and (path_1/any(t:t eq 'c57e57c57b1d47afaeac3b9532763b10')))&queryType=full&$skip=0&$top=20&$count=true

Changing boost score from 50 to 49 made no difference.

Answer 1

With Azure search - if you use contains then it does a partial word match as in "Samp" will boost "Sample Page 1". If you use "Sample" it is not a partial word so does not get boosted.

To use the word matching in a phrase you need to use is equals to rule.

I also discovered that the "is case-insensitively equal to", "is not case-insensitively equal to", and "matches the regular expression" comparison types are not supported for this type of rule. A request to hide them has been submitted as I initially thought the case-insensitively equals sounded fit for purpose.