Best Practices for Making Search Requests

The final part of your Relewise setup involves preparing your search requests.

Relewise search falls into four request types: ProductSearch, ProductCategorySearch, ContentSearch, and SearchTermPrediction.

A request type contains the following:

• A Search Term
• A Language
• A Currency
• A User
• A skip value and a take value (or .pagination if using Javascript/Typescript)

Search requests can also take a Location, and we recommend using locations for your site when possible, to improve your analytics overview.

For good examples and a showcase on how to format and implement search requests, refer to our Examples Page.

Datakeys are Case Sensitive

Most datakeys in Relewise are case sensitive. Ensure that your data adheres to this case sensitivity to avoid unnecessary issues during implementation.

To learn more, click here.

Sorting Searches

As a rule of thumb, you do not want to sort the search results until after they have been presented to the user. The default search sorting is built around the personalization that Relewise has gathered for the user, and will produce the best results in the vast majority of cases.

For post-hoc search sorting, make sure to enable a secondary sorting type of relevant, to ensure that sorted results with the same value are given a fallback criterion. For instance, if the user sorts by price, there may be several products with the same price being presented. Having a fallback ThenBy sort type of Relevance, ensures that Relewise always returns the best results first, increasing the likelhood of a conversion, and giving the customer the best possible experience.

Search Refinement

Relewise Search comes pre-equipped with processes for stemming, decompounding, synonyms. That means that most of the common cases are already covered by the Relewise engine, but there may be industry-specific terms that the default settings do not cover.

The MyRelewise UI makes it easy to set up customizations for stemming, decompounding and synonyms, and we recommend that you consider whether there are any particular cases unique to your business where any of these functions might benefit you. You can read more about stemming, decompounding and synonyms in our documentation.

A note about Language

As noted above regarding Multilingual Properties, we urge you to employ Multilingual / MultilingualCollection properties for all data fields containing language-specific texts which you want your users to be searching for. The above features of stemming, decompounding, synonyms etc. will also perform the best when the language of the text in a given field is known. Even if you only have a single language on your site, employ Multilingual poperties whenever a field should be externally searchable and the field contains language-specific text.