Appearance
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
skipvalue and atakevalue (or.paginationif 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 SDKs 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 likelihood of a conversion, and giving the customer the best possible experience.
Set a Debounce Time
A Debounce time refers to a delay between inputs that ensures that a function is not executed until the input has been stopped for the specified amount of time. For instance, a search request with a Debounce time of 300 ms will ensure that typing input must have come to a stop for 300 consecutive milliseconds before the search request is sent to Relewise. Typically, a search overlay will be coded to fire off a search request automatically as the user types, and the Debounce time will help ensure that the search is not fired off at every input, but only when the user is finished typing.
At Relewise, we encourage you to set a Debounce time of somewhere between 200-350 ms. This can help reduce the cost of your search requests per month, without incurring a noticeable loss of performance or function on the site.
Debounce times are variable from one solution to the next, and there is no single right answer to what the time should be; we encourage that you set a limit around 200-350 ms to start with, and test it to see how well it performs for you.
Be aware that Debounce is not something you set up in Relewise, but rather something you code into your website. Relewise cannot help you with the actual Debounce code.
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 My Relewise 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 properties whenever a field should be externally searchable and the field contains language-specific text.