Best Practices for Configuring the Search Index

Setting up the Search Index is most easily done via the My Relewise 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 DisplayName and nothing else, so you must curate it to your specifications.

Depending on your use case, the best practice for configuring search term weight differs. Weight is a score assigned to a data field to determine its influence on search relevance. It is a numeric value (byte) ranging from 1 to 255, where higher numbers indicate greater importance. These weights are relative, both to each other and to the maximum assigned value.

For instance:

• Two fields with weights 1 and 2:
  → The second field is 100% more influential than the first.
• Three fields with weights 1, 2, and 3:
  → Field 2 is 33% stronger than field 1, and
  → Field 3 is 66% stronger than field 1.

This means that the impact on Search Ranking goes as follows:

• Large differences in weights lead to a strong impact on result ordering.
• Smaller differences allow other ranking factors to take over, such as:
  • Personalization
  • Popularity
  • Relevance modifiers
  • Merchandising rules

Search Term Stacking

It is important to keep in mind, when integrating and indexing data, that Relewise does not consider multiple matches of a search term within the same field to be a "stronger" match than a single match within the same field. This means that if a product description contains the search word 10 times, and another product contains the search word 1 time in the same field, those two products will be considered equally relevant to the search results.

In other words, more emphasis should be put on matching search terms accurately, and less on trying to stack certain fields with multiple instances of the same term to make it "better".

Considering the Search Index

The philosophy of configuring the search index should be based on a consideration of how your users are going to engage with the search. This varies from use case to use case, and can be difficult to generalize on, but typically you should have some idea of what the most typically searched-for features of your data are.

Keep in mind that not all data on your dataset necessarily needs to be related to the search; a lot of data is likely to be more relevant for faceting, which has nothing to do with the search index itself, but does operate in conjunction with the search. Consider how your users are going to search and how they are going to facet that search - some use cases will tend to go from "generic search to specific facets", while others will rely more directly on specific searched.

For instance, a clothing retailer is likely to see users searching for broad terms such as garment type, brand, or color, and then facet down from there. A hardware store, by comparison, is likely to have users search for specific dimensions (e.g., an 8mm screw) than simply the term "screw". This means that the setup of the search index for these two will differ; the hardware store will prioritize the technical specs, whereas the clothing store will focus on the more broadly descriptive fields.

Site Coverage Checklist

Since the default Index will only search for Product DisplayName, 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.

Be ISO 639-1 Compliant

Relewise requires language codes to conform to the ISO639-1 standard (e.g. 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 compliance 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.

Learn more about languages here

Weighing Product Entities

The main thing to consider when weighing data keys is the kind of information it contains, and the way in which users are likely to engage with the search. Generally, the more succinct the data is, the higher a weight it should be given. For instance, DisplayName and Id are candidates for higher weights, since these are highly specific to the entity being searched for. Conversely, long-form texts such as Description are often best configured with a very low weight, since they are more likely to contain words not specific to the individual entity, which is prone to cause many false positives if weighed too highly.

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.

Weighing Content Entities

Weighing content entities is very similar to weighing products, as content entities use the same data types as product entities. This means that the same principles apply: Consider how the user is most likely to search for the content page, and prioritize those fields. Typically, DisplayName will be at the top of the priority, with something like a ShortDescription or a MetaDescription coming in second, if relevant.

There are no strict guidelines for how much data can be integrated to a content entity, and as such, you can technically integrate the entire body of the content entity into Relewise and make it searchable. Best practice for this, however, is to avoid dumping large fields into the search index, since it can easily end up muddying the results. Consider the fact that Relewise does not perform any kind of stop-word filtering on your data, but simply processes it as-is. That means that if you make a field containing 2500 words searchable, any of those 2500 words will be eligible to match on a search term - which will in turn throw up a lot of false positives.

Best practice for long-form texts is to lower their relevance to the lowest score in the index, in order to use them primarily as fallback resources when all other relevant fields fail. It can be beneficial, rather than relying on the body of an article, to implement a list of relevant tags on the content entity, which are made searchable at a higher weight. This will help guide users towards articles that may not contain a subject matter in the title, but does contain it in the body - without "polluting" the search results with a lot of potentially less relevant results.

Weighing Categories

Category entity searches are typically performed solely on either Entity Id or DisplayName. Weigh these according to the advice outlined above; if the use case is more likely to favor searching for the ID, place a higher weighting on Id than DisplayName, and vice versa.