Setting Up a Vertical Configuration | Yext Hitchhikers Platform

What You’ll Learn

In this section, you will learn:

• Initial Vertical Setup
• Searchable Fields and Additional Vertical Settings
• Example Vertical Configuration in JSON
• Knowledge Graph vs. Custom Backends

Initial Vertical Setup

After you step through the initial setup wizard in the UI, you’ll have a starting point for your Search Configuration verticals:

Throughout the various configuration modules in the Search track, we will walk through the remaining configuration steps, which will allow you to optimize your Search Experience and add more features to it. In total, we will walk through:

1. Verticals
2. Query Suggestions
3. Synonyms
4. Query Rules
5. Additional Settings

The focus for this unit will be on Verticals.

Verticals - Searchable Fields

We will detail and break down all of the searchable field types in the next units. It is important to always make sure that for each of your verticals, you’ve established which fields will be indexed by the Search algorithm and have designated a Searchable Field type for each one. In the example FAQs vertical below, we’ve set up the following searchable fields: name, keywords, and entity type:

Verticals - Additional Vertical Settings

Each vertical will have its own respective settings. The following settings are currently available for each vertical via the UI:

• Name
• Entity Types
• Saved Filters
• Vertical Key

Let’s break down each one:

Name This is a display, “pretty-printed” name for the vertical. For example, ‘Offices’.

Entity Types Supported entity types within a given vertical.

Saved Filters This value references a Knowledge Graph Saved Filter which will specify the entities that will return in a given vertical. You’ll want to include this if you need to limit the entities returned for a vertical in some way, for example only those locations that are open, FAQs that have the Answer field filled out, or events that are in the future.

Vertical Key This is an internal name for the vertical and will be used to uniquely identify the vertical. You will also use this value to reference the vertical in the frontend. We recommend using something customer-friendly and plural, for example “offices”.

Example Config Layout in JSON

Once you create the Experience through the UI, you will automatically have the option to update and maintain your Search Configuration using JSON. If you are inclined to use JSON, you can switch over to the JSON mode from the UI. Here’s how a standard vertical might look, written in JSON Syntax:

"offices": {
  "entityTypes": [
    "location"
  ],
  "keywords": [],
  "name": "Offices",
  "savedSearchId": "123456789",
  "searchableFields": {
    "address": {
      "directAnswer": true
    },
    "builtin.entityType": {
      "nlpFilter": true
    },
    "builtin.location": {
      "nlpFilter": true
    },
    "hours": {
      "directAnswer": true
    },
    "mainPhone": {
      "directAnswer": true
    },
    "name": {
      "textSearch": true
    }
  },
  "directAnswers": {
     "featuredSnippets": {
      "predictionMode": "APPROVE_ONLY"
    },
      "fieldValues": {
        "eligibleFields": [
          "phone", "address"
      ]
    }
  },
  "sortBys": [],
  "source": "KNOWLEDGE_MANAGER"
},

You can see that there are JSON objects for the UI Vertical configuration. Name, Entity Types, Saved Filter, and Searchable Fields correspond to name, entityTypes, savedSearchId, searchableFields, and directAnswers objects within the JSON file. You can always update the JSON, click save, and flip back and forth between the UI and JSON editor.

Knowledge Graph vs Third Party Vertical

As you can see in the above JSON editor, the “source” object will be “KNOWLEDGE_MANAGER” when you are setting up any vertical based on the Knowledge Graph. There are instances, however, where you will want to set up a custom back end that connects to a different “source”. For example, you’ll often see a default “links” search Vertical within a Search experience. That Vertical is NOT powered by the Knowledge Graph and instead is set up via a Third Party Vertical. Remember that for these verticals, the data is not stored in the Knowledge Graph. Third party verticals can only be configured in the JSON editor at this time.

We recommend including at least one third party vertical as a type of “fallback”; if the Knowledge Graph does not have the answer a user was searching for, they’ll see the standard blue link experience.

We offer a few pre-built integrations for Third Party Verticals, namely:

• Google Custom Search Engine (GCSE)
• Bing
• Zendesk
• SOLR
• And many more

Let’s take a look at an example! A custom links backend using Google Custom Search could look like the below:

"links": {
  "apiKey": "apiKey293754324346352",
  "cx": "cx92349564356-32475456553376",
  "name": "Support Links",
  "source": "GOOGLE_CSE"
},

You will learn more about custom backends and how to set them up in the Third Party Backend module .