Additional Search Configuration Settings | Yext Hitchhikers Platform
What You’ll Learn
In this section, you will learn:
- Location Support by Country
- Additional Stop Words
- Timeout
- NLP Filter Order
Overview
There are additional Search Configuration settings that can be configured through the UI or the JSON editor. Certain features may only be available via the JSON editor. (Oftentimes, new config features will be rolled out to the JSON editor in advance of the UI.) We will always denote which features are JSON-only both in this module and in the Community. As a reminder, you can access the JSON editor by clicking “Edit in JSON” within your experience:
Let’s walk through the additional configuration options below.
Location Search Support by Country
For any of your entities that have a lat/long (think: an address profile field), you will need to make sure you explicity set country support for each unique country in the Search Configuration.
Location support by country can be set within the UI under “Additional Settings”:
Here’s a sample JSON snippet where you can see the countryRestrictions object listing out multiple countries, which enables international location search support:
"countryRestrictions": [
"US",
"GB",
"FR",
"JP",
"DE",
"CH",
"CN",
"IT",
"ES"
],
This is for Search Quality so that we include those countries when we’re searching locations. We want to search across as limited a set of places as needed so we don’t have any false positives (think about a search of “locations in Paris” – it could be Paris, France or it could be Paris, TX in the US – if we know to only search locations in France or the US, we eliminate needing to choose which one to use). By default, we will search US locations but if you have any entities outside of the US, you’ll need to include the ISO Country Code for each country in the configuration so we can expand the search and incorporate any language or country-specific nuances.
The above Search Configuration set up enables the below international country support:
Additional Stop Words
Stop words are common words that the Search algorithm will intentionally treat differently to deliver more accurate results to the user. By default, the Search algorithm already has a list of stop words built-in, such as of
, the
, in
, etc., in order to streamline a query at the time of the search. However, in your Search Configuration, you can take this one step further with the top level property of additionalStopWords, which allows for customization with additional stop words.
It can be set in the UI under “Additional Settings”:
Here’s an example of the JSON Snippet you would use to add the custom stop word “synergic” to your account:
"countryRestrictions": [...],
"additionalStopWords": [
"synergic"
]
Similarly to Location Search Support by Country, this addition is also for Search Quality. Consider a hypothetical healthcare brand called “Synergic Health”. Synergic’s brand name spans across the account in multiple different entities in the knowledge graph, such as a service entity of Synergic Cancer Research or an FAQ entity about Synergic’s COVID policy. If you search for “dermatologists at Synergic”, you may not want the Research center or the FAQ to return. You can add the brand name as a stop word to get to the heart of the query more efficiently, reducing the matching across verticals to only non-brand name tokens.
Custom Phrases
Custom Phrases are multi-word phrases that the algorithm will treat as a single “unit” when matching results in Search. This can be useful for listing brand-specific phrases that you do not want partially matching with results. For example, consider a fast food brand Turtlehead Tacos. Turtlehead Tacos might add a custom phrase “corn tortilla”, to prevent a query for “corn tortilla taco” from returning results like “corn on the cob”, “ tortilla soup”, or “corn salsa”.
Custom Phrases can be set in the UI under “Additional Settings”, for example:
Or you can add a JSON snippet under “Edit as JSON”, for example:
"customPhrases": ["corn tortilla", "al pastor", "carne asada", ...]
Custom Phrases only affect how fields using Text Search, Phrase Match, or NLP Filter are searched. That is because these three algorithms rely on identifying matching keywords between the query and field values in order to return results. If a field is searched using Semantic Text Search, however, then the semantic similarity of the query and the field value is a factor in how the results are returned. Therfore a result may return that only partially matches with a Custom Phrase. For example, a query for “corn tortilla” could still return “flour tortilla” – even if “corn tortilla” is added as a Custom Phrase – because they are semantically similar.
Timeout
The timeout is a specified time interval (in milliseconds) given for each vertical in a query. All verticals completed before the timeout will still be returned even if others haven’t.
It can be set in the UI under “Additional Settings”:
It can also be edited through the JSON Search Configration editor:
"timeout": 5000,
NLP Filter Order
Search offers natural language processing (NLP) features by allowing Administrators to turn on nlpFilter, which helps filter down search results based on the users query alone. In some cases, however, the same filter value exists in two different fields that have nlpFilter turned on. To better handle this tie between field filters, you can configure the object nlpFilterOrder. This array will allow you to specify the order in which you’d like nlpFilters to be selected when conflicts happen.
As an example, a healthcare client has Cardiology as a value in their specialties field and their builtinFile.medicalConditions field. Without nlpFilterOrder, a search for “cardiology near me” would trigger one of these filters arbitrarily. Using nlpFilterOrder, an Administrator can choose which field is prioritized in a tie.
With specialties first in the below array, specialties will be given priority in the case of a tie.
"verticals": {
"facilities": {
"entityTypes": [
"healthcareFacility"
],
"facetOrder": [],
"name": "Facilities",
"nlpFilterOrder": [
"specialties",
"builtinFile.medicalConditions"
],
"searchableFields": {
"builtinFile.medicalConditions": {
"nlpFilter": true
},
"specialties": {
"nlpFilter": true
},
"source": "KNOWLEDGE_MANAGER"
}