Skip to content

Contexts

A context is a set of settings that can be resolved from a search request. It is recommended that the contexts are managed via the Admin UI, but they can be set up via the Admin API. See the full API reference here.

A context consists of:

  • Context id is used to uniquely identify the context.
  • Name assigns an easy-to-read name to the context.
  • Context conditions are used to resolve the correct context when searching.
  • Context partitions define the partition weights for the context.
  • Search relevance weights are used to calculate the relevance of products given a search phrase.
  • Context facets are used to specify the facets which are returned when searching.
  • Context pins are used to specify results that should be promoted to the top of the result when searching.

Contexts are related to commercial sorting. Contexts allow for different sorting configurations for different scenarios. High-end designer products might benefit from boosting exclusivity, while products that targets the general audience might boost on number of clicks last 3 days, or number of sales last 30 days.

Without contexts, all products would have the same boost, all the time. But with contexts, search requests with a specific brand filter, and other conditions, may sort by different parameters, providing tight control over the user's search and browse experience.

Context preview

The UI has a context preview page, where the context can be edited, and it is possible to see the effect, different settings have on which products are returned.

Context conditions

Context conditions are used to specify which context will be used. The more context conditions that match data in the search request, the more relevant the context is. The most relevant context which has all context conditions satisfied is used.

Example

Context conditions form a hierarchy of conditions to match. Given the following context condition hierarchy:

graph TD;
    _f[fallback

Fallback] _f --> _browse[context_browse

Scope = Browse] _f --> _search[context_search

Scope = FullSearch] _browse --> _cat[context_clothing

Category = Clothing] _cat --> _red[Color = Red] --> _size[context_red_xl

Size = xl] _cat --> _yel[context_yellow

Color = Yellow]

In order to get a graph like this, the contexts must be set up with the specific conditions.

Context Conditions
Fallback No conditions
context_browse Scope = Browse
context_search Scope = Fullsearch
context_clothing Scope = Browse
Category = Clothing
context_red_xl Scope = Browse
Category = Clothing
Color = Red
Size = xl
context_yellow Scope = Browse
Category = Clothing
Color = Yellow

In order to resolve the context context_red_xl, a request like below must be issued.

{
    "segmentId": "b2c-en-test",
    "scopeId": "browse",
    "filters": {
        "CategoryNames": {
            "values": [
                "Clothing"
            ],
            "match": "any"
        },
        "color": {
            "values": [
                "red"
            ],
            "match": "any"
        },
        "size": {
            "values": [
                "xl"
            ],
            "match": "any"
        }
    },
    "phrase": ""
}

  • If the size filter is changed, then the context_clothing will be matched instead.
  • If the color filter is changed to yellow, then the context_yellow will be matched instead.
  • If the category filter is changed, then the context_browse will be matched instead.
  • If the scopeId is changed to fullsearch, then the context_search will be matched instead.
  • If the scopeId is neither browse nor fullsearch, then the fallback context will be used instead.

The contexts conditions that can be used are:

Fallback context

Each segment must have a fallback context which is used if no other matching context can be found. The fallback context cannot have any context conditions or be inactive, but otherwise behaves as other contexts. Each segment must have exactly one fallback context, if not, a conflict occurs in the publication.

Context partitions

Context partitions are used to control the sorting of products. A partition is multiplied by a weight and added to a context to create a context partition. See commercial properties for more information.

An example of two context partitions could be: Products that are in the 10% most sold products have a weight of 10, and products that are in stock have a weight of 5. Different contexts can have different partitions. This means that while one context might boost products that are in the 10% most sold products, another context might boost products that are trending.

Warning

A max achievable score can be set in the general settings (by default 1000). When set, the sum of all the weights must equal the max achievable score. This score is global for all contexts, and helps to ensure that contextual boosting does not outweigh the search relevance. When users search for products, it is important that they see relevant products. Among these relevant products, the order in which they are displayed may be influenced by commercial sorting.

Personalization weight is used to specify how much a person’s affinity for the product should count in the score.

The sort order of the products will update live as changes are made to the weights, allowing for an experimental approach.

Search relevance

Search relevance is used to configure how important a phrase match is compared to other contributions. Often, a match in the name or short description of a product is more important than a match in long description. Also, a match on the product number is often the most important. A context is created with a set of recommended settings.

It is possible to choose the following weights:

  • Very High
  • High
  • Medium
  • Low

Only fields that have been configured as searchable can be assigned a search relevance.

While editing a context, a search will show how much it boosts every product, and changes to the Search relevance will affect the live preview immediately.

Context facets

Context facets are used to set up which facets should be returned in a search response, if the search request resolves into the context.

Each context can have one facet for each allowed filter. When selecting a context facet, the match type is specified. The order of the facets when editing a context reflects the order of facets in search responses.

Example

For the product category clothes, facets on size and material are needed for the customer to be able to select these properties by themselves.

A context for the category clothes is created, and context facets for size and material are added. The context facet for the size attribute will have the Any match type, as it does not make sense for a SKU to have multiple sizes. The material facet has the match type All, as a customer might want to look for clothes with multiple materials for the same SKU. Alternatively, material could have the match type None, if it is necessary to provide the customer with the ability to filter out clothes containing specific materials.

Context pinning

Pinning bypasses commercial sorting within a context.

If a search request is sent with pinned ids, these will take priority over saved ids on the context.

Each context can have up to 200 pinned products/SKU's.

Context affinity weights

Context affinity weights describe how user affinities are boosted in search requests.

Each context can have unique boost values per affinity source.

Publication

Changes to a context will only take effect after publication. Only active contexts will be part of the publication.