Skip to content

Best Practices for Configuring the Search Index

Setting up the Search Index is most easily done via the MyRelewise interface. For more information on the basic functions of the Search Index, click here

When you are setting up your Relewise, you will be given a Default search index to work with. It is very important that you engage with it and set it up to your requirements; by default, the index will only search for Product Titles and nothing else, so you must curate it to your specifications.

By default, Relewise provides you with one search index for you to configure. In the vast majority of cases, this is sufficient to give you the control you need, even with multiple languages to configure. If, however, you find that you require more than one search index, we urge you to reach out to us and discuss the possibilities of having another index added to your administration.

Site Coverage Checklist

Since the default Index will only search in Products, and only for Product Title, it is important that you ask yourself the following questions:

  1. Does my search need to find products? If yes, make sure you configure the Product section of the Index.
  2. Does my search need to find product variants? If yes, make sure you configure the Product Variants section of the Index.
    • Relewise treats Products and Product Variants as different entities, which means that you must set up both in the Search Index for your variants to be properly searchable.
  3. Does my search need to find product categories? If yes, make sure you configure the Product Categories section of the Index. Note that there is a distinction between "finding product categories", and "finding products based on their categories". To find products based on their categories, configure the Products section of your Search Index to include Product Category as a weighted field.
  4. Does my search need to find Content Pages? If yes, make sure you configure the Content section of the Index.

Best Practice Search Index

Being ISO 639_1 Compliant

Relewise requires langauge codes to conform to the ISO639-1 standard (eg. en or da). The Search Index allows you to configure the language code to fit the ISO standard, provided your data import is not set up for ISO compliancy already. While the field marked ISO639_1 accepts both neutral language strings (en) as well as specific culture codes (en-gb), Relewise only requires the neutral language code.

Best Practices Language Code

Weighting the Search Index

Search weighting is entirely dependent on what you need from the search engine. As such, this is meant as a jumping-off point for further customization.

Weighting the Search Index - Products

Depending on whether or not you use variants for your products, the best practice for configuring search term weight differs. The important thing to keep in mind is that for search weighting, a higher score means more prominence in the search results.

Generally, the more distinct and less likely a field is to contain anyting not directly relevant to the entity, the higher a weight it should be given. For instance, DisplayName and Brand are candidates for higher weights, where longer texts such as Descriptions are often best configured with a very low weight, since they are more likely to also contain words not specific to the individual entity.

You can read more about the particulars of search weighting here.

If your products do not have variants, focus your weighting on DisplayName first, followed by either CategoryDisplayName or BrandDisplayName. These are almost universally what users are likely to search for, and provides excellent coverage until you are ready to specialize your search weighting further. Set the weight of any field that contains a lot of text (such as a description field) to 1, to ensure that it is searchable without cluttering up the results.

If your products do have variants, your focus will naturally shift towards the particular features of your products. Variant data will vary depending on product type, and so your goal is to promote the most prominent of the data that users will likely search for.

It is important that you differentiate between cases where you need your search function to look for products, and where you need to look for variants. Businesses that operate heavily with variants on the products will see a reduced efficiency of Relewise if this is not implemented correctly.

Weighting the Search Index - Content Pages and Categories

Following the principles above, weighting content pages and content/product categories is straightforward. DisplayName and CategoryDisplayName are highest priority for content, and you may add an additional data key to allow for searching in the main body of text of the content page as well.

Product Category searches should focus on DisplayName, with ID second.

Prediction Source Types

The final stage of configuring your search index is ensuring that each searchable field is parsed correctly by the search engine. Not every field should be engaged with in the same way, which is where prediction source types come in. You can read about the different prediction types here.

Keep in mind that Prediction Source Types affects regular search requests as well as predictive searches/typeahead.

Best practice for prediction source types is to consider the type of field, and the type of data in it. For fields where you only want to predict completions of the the current word, this could be for SKU, ID, or Description fields, use "Individual Words".

For custom fields where you would like Relewise to predict continuations of additional words, like DisplayName use "Partial Word Sequence".

If you dont have a lot of products in your catalog, and would like to predict full sentences based on only a few key strokes, you could consider to configure fields like DisplayName as "Complete Word Sequence", this will instruct Relewise to predict full product names.

Most often, you will only be using "Individual words" and "Partial Word Sequence" in your index, but when suitable, the other options can bring great value given the right use case.

Don't know us? Don't worry - you can find more information about us, by visiting our main page