Vertical Intents, Biases & Thresholds | Yext Hitchhikers Platform

What You’ll Learn

In this section, you will learn:

• How to configure the vertical ranking Search algorithm
• What vertical intents, biases, thresholds, and priority fields are

Overview

In the Vertical Ranking unit , you learned how the Search algorithm ranks verticals. This unit will walk through all the different properties in the Search configuration that are designed to influence the vertical ranking of your Search experience.

Namely, we will cover:

• Vertical Intents, which allow you to provide additional clues for each vertical that the Search algorithm will use to evaluate its relevance
• Thresholds, which are are minimum score requirements that a vertical must meet in order to be returned at all in the search results
• Biases, which allow you to make adjustments to the final score of each vertical, which determine the rank in which they appear
• (Optional) Priority Fields, which allow you to guide the Search algorithm towards clues that are most important for representing the vertical

A vertical using all four vertical ranking properties may look like this in the configuration:

"resources": {
    "entityTypes": [
        "ce_resource"
    ],
    "name": "Resources",
    "searchableFields": {...},
    "semanticVerticalBias": 0.2,
    "semanticVerticalIntents": [
        "sales resources",
        "sales sheet",
        "corporate pitch deck",
        "support deck"
    ],
    "semanticVerticalRankingPriorityFields": [
        "name",
        "c_category"
    ],
    "semanticVerticalThreshold": 0.4,
    "sortBys": [...],
    "source": "KNOWLEDGE_MANAGER"
}

You can also configure these vertical ranking properties in the config UI for each vertical. Note that priority fields are an advanced concept and can only be configured in the JSON editor, not the UI. The above configuration in the JSON editor would look like the below in the UI:

Define Vertical Intents

One of the most direct ways you can control the vertical ranking of your Search experience is by defining Vertical Intents for each of your verticals.

Vertical Intents are phrases or search queries that you want to associate with that vertical as a whole, like a synonym for the vertical. A good way to think about vertical intents is to ask yourself: if this intent was placed as a search query, would I want this vertical to always return first?

Vertical intents are used by the Search algorithm as one of the “clues” to evaluate the relevance of a vertical for a particular search query. If the search query is very similar in meaning to a vertical intent, it is very likely that vertical will appear first as a result.

You can define vertical intents today in the JSON of any Search configuration, using the semanticVerticalIntents property under any vertical. For example, if you were defining a Resources vertical for a workplace search experience, you might add intents such as:

"resources": {
    "name": "Resources",
    "entityTypes": [
        "ce_resource"
    ],
    "semanticVerticalIntents": [
        "sales resources",
        "sales sheet",
        "corporate pitch deck",
        "support deck"
    ]
}

Set Thresholds

Thresholds are minimum score requirements that a vertical must meet in order to be returned at all in the search results.

Thresholds are limited from 0 to 1 (inclusive) and can only include a single decimal point. They are set in the JSON of the Search configuration, using the semanticVerticalThreshold property.

"resources": {
    "name": "Resources",
    "entityTypes": [
        "ce_resource"
    ],
    "semanticVerticalThreshold": 0.4
}

Choosing a Threshold

A useful way to think about vertical thresholds is how strict you want Search to be when deciding whether to return a vertical or not.

Setting a very high threshold (e.g., 0.7 or 0.8) indicates that you only want that vertical to return if there is an extremely high semantic match with the user’s search query.

Without a threshold, a vertical will often be returned in Search if there is any keyword match with the user’s search query whatsoever. This can be frustrating when working with verticals with a lot of content (e.g., long crawled documents, forum posts, etc.), where the probability of a random keyword match is high.

Therefore, setting a high threshold for these types of verticals can be a good way to restrict how often they return, so they only return when the algorithm thinks they are meaningfully related to the query.

On the other hand, setting a low threshold (e.g., 0.1 or 0.2) can be good practice in general across verticals, to ensure matches on keywords that are not actually semantically similar to the query are ignored.

Set Biases

Biases are adjustments you can make to the final score of each vertical, which determine the rank in which they appear. Adding a positive bias will be added to the vertical score, and a negative bias will be subtracted.

Biases are limited from -1 to 1 (inclusive) and can only include a single decimal point. They are set in the JSON of the Search configuration, using the semanticVerticalBias property.

"resources": {
    "name": "Resources",
    "entityTypes": [
        "ce_resource"
    ],
    "semanticVerticalBias": 0.2
}

Choosing a Bias

Vertical biases can be used to nudge the Search algorithm into favoring one vertical over another. This can be useful, for example, if you have some verticals that are more authoritative or that you find are more useful than others.

For instance, if you have a support search experience with one vertical featuring official published help articles, and another featuring forum Q&A posts, you will likely want to bias the algorithm towards returning the official content. This is because if there is a roughly equal match between help articles and forum posts, it is preferable for the user to go to the official published content.

Determining the right bias for your verticals should be done iteratively; by placing searches, evaluating the ranking of verticals, and making adjustments to the biases until the ranking feels generally correct.

Pick Priority Fields

Finally, there is an additional, more subtle way to impact vertical ranking which we have not discussed yet - and that is the concept of Priority Fields. This is an advanced concept, and is not required to configure vertical ranking.

Priority fields are a select list of the searchable fields on a vertical, which you want the algorithm to prioritize when evaluating vertical ranking.

The way it works is: when gathering clues from each vertical to calculate vertical scores, the Search algorithm will also look at the values of the searchable fields for the top entities returned. If two verticals are tied and have the same vertical score, Search will then check whether the match of any vertical is on a priority field; and if it is, it will rank that vertical above the other.

The most common use of priority fields is to prioritize fields that are visible to the user on the SERP (Search Engine Results Page).

Say for example, you have an experience with two verticals: Product Categories and Locations. A user searches for “shoes”, and the algorithm returns a Product Category with the name “Shoes”, and a Location with a keyword “Shoes”.

The Product Category is obviously the better vertical to show first, because the Shoes Product Category more directly addresses the user’s query than a Location that sells shoes. Therefore, we can add name as a Priority Field for the Product Category vertical, to ensure it always appears above similar matches on keywords for Locations.

Priority fields are defined using the semanticVerticalRankingPriorityFields property in the Search configuration. Note that by default, name and builtin.entityType are set as Priority Fields for all verticals, as this is a pretty common use case. You’ll only need to define Priority Fields is you are looking to override this default.

"resources": {
    "name": "Resources",
    "entityTypes": [
        "ce_resource"
    ],
    "semanticVerticalRankingPriorityFields": [
        "name",
        "c_category"
    ]
}