Searchable Fields Best Practices | Yext Hitchhikers Platform

Overview

To make the most of your search configuration, it is crucial to ensure that you are using the appropriate search algorithm for each field you make searchable. The following is a list of tips for setting up your searchable fields.

For an overview of searchable fields, check out the Searchable and Display Fields unit. For the schema of searchable fields, check out the Search Config - Verticals reference doc.

Note: If you are using Search for healthcare, find industry-specific guidance in the Set Up Your Search Configuration for Healthcare guide.

Tips by Search Algorithm

The following are some general tips for how to use each search algorithm based on the content you want to make searchable:

Keyword Search

Keyword Search is the simplest way to search a field. Search will simply look for the tokens in the query in fields set up with keyword search. Thus keyword search works best for short text fields with relatively unstructured data.

Example: Jobs vertical, Name field

• The tokens from the query “application for partner roles” are “application,” “partner,” and “role.” This can return jobs with the names:

  • Partner Engineer
  • Partner Engineer, New Grad
  • Technical Partner Manager
  • Associate Technical Partner Manager
    

  It’s not immediately clear which exact role the user is looking for and since these Job names are varied, unstructured data with infinite values that are similar to each other, keyword search would be the best choice.

Use Keyword Search for:

• keywords when these are just related to the entity and may not be searched exactly. We recommend using phrase match with more specific keywords when possible, but if the data quality is not certain, use keyword search.

Keyword Search tips:

• If the field contains the full name of a person, like “John Doe”, phrase match will provide better exact matches for “John Doe” rather than keyword search results for both “John” and “Doe”.
• Fields with similar and overlapping content should use keyword search rather than an inferred filter which is more restrictive. For example, if a retail bank had both “Student Checking Accounts” and “Checking Accounts” as products, use keyword search to surface both, whereas an inferred Filter would filter down to the one best match. Since search queries may refer to these products by similar but different names, don’t use phrase match which matches the content exactly: the search “Student Checking Accounts” would not return “Checking Accounts” and the search “bank accounts” would not return either.
• Keyword search should almost never be used on long-form text fields like description. This will produce irrelevant results because there is a high likelihood of random keyword matches with such long text.
• If multiple fields with Keyword Search or Document Search enabled may have similar content, use field-level weighting to assign boosts to fields to prioritize matches for. See Field-Level Weighting for Keyword and Document Search for more information.

Semantic Search

Advanced Search Tier Feature

Semantic search is only available on the Advanced Search tier. Check out the Search Tiers reference doc to learn more about the features that are available in each tier.

Semantic Search works by matching a user’s query to anything that is semantically similar (think “beef”, “steak”, and “cheeseburger” – these three terms have a similar meaning).

Example: FAQs vertical, Question field

• A query for “send back my food” would surface the FAQ “Can I return my order?” because they are semantically similar; in both the user wants to return something (in this case, food). Keyword search would not return this result because the words themselves are not a match (i.e. “return” does not match “send back” and “order does not match “food”).

Use Semantic Search for:

• name of entities where a user may not search for the exact terms, but is likely to search for something semantically similar (e.g., “shrimp” may be on a restaurant’s menu, but users could also search for “prawns”).

Semantic Search tips:

• Semantic search is ONLY available for entity names, and is not available for the locations vertical.
• Semantic Search should not be used for names of proper nouns, as semantic similarity does not apply here.

Phrase Match

Phrase Match allows an entity to be surfaced only when there is an exact phrase match contained in the query. It works best for text fields where you want the query to exactly match the content of the field.

Example: FAQs vertical, Keywords field

• Let’s say the FAQ “Do you offer any special menus?” has the keyword “happy hour” on it. We only want to return this FAQ if users search for the entire phrase “happy hour” and not when they query “what are your hours?”. Phrase match works best here because we want to match the entire keyword in the query to return the result.

Use Phrase Match for:

• name of a person (e.g., “John Doe”) to only return exact matches for “John Doe” instead of keyword search (which would surface all results for both “John” and “Doe” separately).
• keywords when these may actually be key phrases that should be searched exactly (e.g., if you want “Mortgage Loan Officers” to only return results for “Mortgage Loan Officers” and not results for “mortgage”, “loan”, and “officers” separately).

Phrase Match tips:

• Make sure keywords added to entities in the platform represent the entity and are not just *related* to the entity. Think of keywords as synonyms for the entity, so setting keywords that are too broad will result in bad matches. For example, if you set “mortgage” as a keyword for a mortgage officer entity, that officer will return when the user searches “mortgage rates”, which is not a query that should return officers.

Inferred Filter

Advanced Search Tier Feature

Inferred filtering, except on builtin.location, is only available on the Advanced Search tier. Check out the Search Tiers reference doc to learn more about the features that are available in each tier.

Inferred Filter is best for structured fields for which there are a finite number of options, such as department or builtin.entityType. It infers a specific filter and applies it to the search, making it a black and white filter, a much stricter setting than any other search algorithm.

Example: Jobs vertical, Job Department field (single option select with options for Revenue, Technology, Delivery, etc.)

• A query for “open technology jobs” will filter to only jobs with “Technology” populated in the Job Department field. Since this field is structured and contains a finite number of value options, inferred filter works best.

Use Inferred Filter for:

• Fields that represent a specific category or label for an entity (e.g., filter products down to “Men’s Shoes”).
• builtin.entitytype for every vertical to surface those entities when a user searches for the name of entity type. For example, searching “FAQs” would apply an inferred filter for the FAQs entity type, boosting that vertical to the top of search results.
• builtin.hours for any entity type that you want to filter down to options that are “open now”.
• builtin.location for any entity type that has an address and can be searched by location, e.g. locations, professionals, and jobs.
• address.region (or other address field) for an entity type with an address where users are expected to search more specifically for city names (or by other parts of the address). This will create a more restrictive filter for location searches.

Inferred Filter tips:

• Inferred Filters will exclude results that do not fall under that category from the search results.
• Inferred Filters use the exact content of the field, so be careful of duplicative categories like “Men’s Shoes” and “Men’s Shoe”. The algorithm will choose the best match and exclude results for as the other.
• Inferred Filters are available in  Experience Training , so you can easily improve your search experience by accepting and rejecting filters.
• If you are using multiple inferred filters, you can add nlpFilterOrder to your config to set prioritization following the Search Config - Verticals reference doc.

Document Search

Advanced Search Tier Feature

Document search is only available on the Advanced Search tier. Check out the Search Tiers reference doc to learn more about the features that are available in each tier.

Document Search works by matching query intent to long form, unstructured text to find the most relevant snippet of text within the document. Document search matches query intent to unstructured text in the backend and produces featured snippets to display on the frontend.

Example: Help articles vertical, Body field

• The query “What does Yext do?” is answered in a help article. Document search will both return the most relevant help article by searching the long form, unstructured content and also providing the most relevant snippet back from the article to display as a featured snippet.

  

Use Document Search for:

• description and body fields with long, unstructured content (e.g., help articles, product descriptions, and file search).

Document Search tips:

• Document Search works well with extractive QA to surface direct answers! For more information, refer to the Direct Answers unit.
• Check out limitations of file search in the File Search reference doc.
• If multiple fields with Keyword Search or Document Search enabled may have similar content, use field-level weighting to assign boosts to fields to prioritize matches for. See Field-Level Weighting for Keyword and Document Search for more information.

Facets

Facets allow a field to be used as a type of dynamic filter that a user can interact with in the frontend search experience to narrow the search. This is best for structured enum/option fields for which there are a finite number of options.

Example: Jobs vertical, Job Department field

• Typically fields that work well with inferred filters are good for facets as well, so let’s return to the example from inferred filters. In the screenshot below, the filters on the left are for the Job Department field (which we’ve labeled as “Job Category”). Facets will also need to be set up on the frontend (check out the Facets and Filters (Frontend Theme) unit for more detail).

  

Use Facets for:

• Structured enum/option fields for which there are a finite number of options.
• Fields whose filter you want a user to be able to toggle on the frontend.
• With similar best practice tips, fields that are good candidates for an inferred filter are typically good candidates for facets as well. These search algorithms work well together because when an inferred filter is detected, the corresponding facet will show up as checked.

Facets tips:

• Facets use the exact content of the field, so be careful of duplicative categories like “Men’s Shoes” and “Men’s Shoe,” as these will both show as options. We recommend consolidating these into one category.
• Setting too many searchable fields as facets may be overwhelming to a user, so defer to the fields that are most likely to help a user narrow down the results.
• Facets with lots of options can be made searchable. For instructions on how to make facets searchable, refer to the Facets and Filters (Frontend Theme) unit.
• Consider placing the most general, high-level filter categories at the top of the list and the more specific ones at the bottom. For instructions on how to set facet order, refer to the Facets and Filters (Backend) unit.

Multiple Search Algorithms on the Same Field

Only use multiple search algorithms for the same field if it’s deliberate, or else it could cloud the process of which search algorithms are being applied.

• Inferred Filters would override other searchable fields because of its strict nature to filter down to only the one best match.
• People names is an example of a deliberate use of multiple search algorithms and we recommend using both Phrase Match and keyword search. Results would return based on the number of matched tokens (check out the Overview of Algorithm and Indexing unit), which will display results for Phrase Match and then keyword search. For example, if the search query is “John Doe,” phrase match would return all exact matches for “John Doe”, and keyword search would return any matches for “John” and any for “Doe”. Since a match to “John Doe” is stronger than a match to “John” or “Doe”, the phrase match results will appear above the keyword search ones.

Tips by Vertical

The following are guidelines for setting searchable fields by vertical type. We have included instructions for the most common verticals: Locations, FAQs, Products, Professionals, and Jobs.

These examples are meant to give you a starting point for how to approach searchable fields as you build your own Search experiences. Of course, your specific experience may have different entity types or different use cases that lead you to diverge from these guidelines.

Advanced Search Tier Features

Semantic search and inferred filtering (except on builtin.location) are only available on the Advanced Search tier. Check out the Search Tiers reference doc to learn more about the features that are available in each tier.

Locations

To surface the best results in your locations verticals, add the following to your config as searchable fields:

• Add keyword search to name.
  • Note: if all location entities have the same or similar names, using name as a searchable field is not recommended because a search for this name will surface all entities.
• Add an inferred filter to builtin.location.
• If you want to filter down results to only show a particular place when a user searches for a specific zip code, city, or state, set the field (e.g., address.city) as an inferred filter.
• If you are using multiple inferred filters, you can add nlpFilterOrder to your config to set prioritization following the Search Config - Verticals reference doc.
• Add an inferred Filter to builtin.entityType.
• Add phrase match to keywords.
• If your locations fall into multiple categories (e.g., hospitals and outpatient centers), consider adding the corresponding category field as a facet and an inferred filter.

FAQs

To surface the best results in your FAQs vertical, add the following to your config as searchable fields:

• Add semantic search to name.
• Add phrase match to keywords.
• Add an inferred Filter to builtin.entityType.
• If your FAQs fall into multiple categories (e.g., account, order status, etc.), consider adding a category field as a facet and an inferred filter.

Products

To surface the best results in your Products vertical, add the following to your config as searchable fields:

• Add semantic search to name.
• Add phrase match to keywords.
• Add an inferred Filter to builtin.entityType.
• If your products have features that fall under multiple but finite categories (e.g., brands, colors, parent products, or stock statuses), consider adding those feature fields as an inferred filter and a facet.

Professionals

To surface the best results in your Professionals vertical, add the following to your config as searchable fields:

• Add keyword search and phrase match to name (name, first name, and last name).
• Add phrase match to keywords.
• Add an inferred Filter to builtin.entityType.
• If professionals speak different languages, add an inferred filter and a facet to language.
• If professionals have associated addresses, add an inferred filter to builtin.location.
• If a healthcare account, also consider adding an inferred filter and facet to insurance accepted.
• If professionals are associated with specific locations in the Knowledge Graph, consider adding phrase match and keyword search to related locations.

Jobs

To surface the best results in your Jobs vertical, add the following to your config as searchable fields:

• Add semantic keyword search to name.
• Add phrase match to keywords.
• Add an inferred Filter to builtin.entityType.
• Add an inferred filter to builtin.location.
• If applicable, add keyword search to department and hiring organization (or, if the options are limited, consider adding these as inferred filter and facet).
• Add an inferred filter to employment type.