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,

• Parameters define the partition weights for the experience, one business rule per parameter.
• 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 Tags

An experience can be tagged with one or more tags. Tags can be used to filter and group experiences in the Admin UI.

Time-based experiences

An experience can have time-based variants that apply only during a scheduled time period, so campaign and seasonal settings activate and expire automatically. See Time-Based Experiences.

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.

graph TD;
    _f[fallback<br/><br/><b>Fallback</b>]
    _f --> _browse[experience_browse<br/><br/><b>Scope = Browse</b>]
    _f --> _search[experience_search<br/><br/><b>Scope = FullSearch</b>]
    _browse --> _cat[experience_clothing<br/><br/><b>Category = Clothing</b>]
    _cat --> _red[<b>Color = Red</b>] --> _size[experience_red_xl<br/><br/><b>Size = xl</b>]
    _cat --> _yel[experience_yellow<br/><br/><b>Color = Yellow</b>]

 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": ""
}

The experiences conditions that can be used are:

• Attributes
• Targets
• Scopes
• Categories
• If the search request contains a phrase
• If the search request is a specific phrase

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 favorite conditions

It is possible to mark conditions as favorites in the Settings page of the Admin UI. Once the conditions are added to the favorites they will show up above the other conditions on the Playground conditions dropdown list.

Experience inheritance

Experiences inherit business rules from less specific experiences, the ones whose conditions are a subset of their own. A value defined on a less specific experience applies to every more specific experience below it, until one of them defines its own value. For example, an experience with conditions on FullSearch and on a subcategory takes each business rule it does not define itself from the first of these experiences that has one:

• An experience that has conditions on FullSearch and on the parent category
• An experience that has conditions on FullSearch
• The fallback experience, which has no conditions

Setting states

In the Playground every inheritable setting shows one of four states as a badge in its header:

Each state offers a fixed set of actions:

Where a value comes from

Under the badge, a short line names the experience the value comes from: "from Fallback" for an inherited value, "Overrides Fallback" for a customized one, and "Not used in Browse or below" for an excluded one. A setting that is defined here has no such line.

Hovering over or focusing the badge shows the inheritance chain of that setting: the experience that holds the value, the current experience marked You're here, and how many experiences below inherit the value and how many have their own.

Copy to parent

A customized value can be put on the parent experience, the one it overrides, without leaving the Playground. Copy to parent replaces the parent's value with the current one, and the current experience goes back to inheriting in the same step, so it keeps the same values. The parent changes at once, which affects every experience that inherits from it. Copy to parent is not offered for pinned products, and it is not available for bury rules, because a customized bury rule always has the same field and value as its parent.

Settings with several rules

Most effects hold one setting per experience. Parameters and bury hold several: each parameter, and each bury field-and-value pair, is a setting of its own, with its own state, origin, and actions.

See Business rules and inheritance for a walkthrough.

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.