Skip to content

Experiences

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

An experience consists of:

  • Experience id is used to uniquely identify the experience. This is only editable and viewable from the api.
  • Name assigns an easy-to-read name to the experience.
  • Conditions are used to resolve the correct experience when searching.

It can also consist of these optional business rules,

  • Parameter set / parameter define the partition weights for the experience.
  • Search relevance weights are used to calculate the relevance of products given a search phrase.
  • Facets are used to specify the facets which are returned when searching.
  • Pins are used to specify results that should be promoted to the top of the result when searching.
  • Affinity weights are used to boost affinities that a user might have.

Experiences are related to commercial sorting. Experiences 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 experiences, all products would have the same boost, all the time. But with experiences, 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.

Playground

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

Experience conditions

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

Example

Experience conditions form a hierarchy of conditions to match. Given the following experience condition hierarchy:

graph TD;
    _f[fallback

Fallback]
    _f --> _browse[experience_browse

Scope = Browse]
    _f --> _search[experience_search

Scope = FullSearch]
    _browse --> _cat[experience_clothing

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

Size = xl]
    _cat --> _yel[experience_yellow

Color = Yellow]

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

Experience Conditions
Fallback No conditions
experience_browse Scope = Browse
experience_search Scope = Fullsearch
experience_clothing Scope = Browse
Category = Clothing
experience_red_xl Scope = Browse
Category = Clothing
Color = Red
Size = xl
experience_yellow Scope = Browse
Category = Clothing
Color = Yellow

In order to resolve the experience experience_red_xl, a request like below must be issued. 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
{
    "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 experience_clothing will be matched instead.
  • If the color filter is changed to yellow, then the experience_yellow will be matched instead.
  • If the category filter is changed, then the experience_browse will be matched instead.
  • If the scopeId is changed to fullsearch, then the experience_search will be matched instead.
  • If the scopeId is neither browse nor fullsearch, then the fallback experience will be used instead.

The experiences conditions that can be used are:

Experience condition priority

Experience conditions are prioritized in this order:

  • Targets
  • Scope
  • If the search request contains a phrase
  • If the search request is a specific phrase
  • Categories
  • Other filters

If there are two experiences, one with a scope condition and one with a category condition, and a search request matches both, the experience with the scope condition is used because it has the higher priority.

Experience inheritance

Experiences inherits business rules from other experiences with fewer conditions. So if there the current experience has conditions on FullSearch and on a SubCategory. Then it will inherit business rules from the following experiences(if there are no business rules of the same type on the current experience):

  • An experience that has conditions on FullSearch and on a MaterCategory
  • An experience that has conditions on FullSearch
  • An experience that has no conditions

Fallback experience

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

Publication

Changes to an experience will only take effect after publication.