Personalized Site Search Queries

when a customer executes a search, or query, it triggers a personalized site search request to identify complete records from your entire storefront that meet the query criteria the response includes multiple records, representing the search results each record contains data related to a single product refer to omnichannel personalized search action request docid\ xzjy8ycndlmwjle 2oxmw for the information you must provide in an engine api request for an omnichannel experience configured with a personalized search action specifying a search method the value that you can pass in the optional typeofsearch key determines the method(s) that personalized search uses to find record matches for a customer's search term the value options for typeofsearch are as follows value description default this value prompts monetate to use a successive order of search methods to find matches the first method attempted is and, which means that monetate must find all the words of a search term exactly as typed in a record to include it in the results if it finds no results, monetate then tries the wildcard and search method the order of search method s used is as follows and wildcard and fuzzy and wildcard or fuzzy or if a search term only contains 1 word or more than 6 words, then monetate skips the wildcard or and fuzzy or search method s wildcard and this value dictates that all words of the search term must be found somewhere in a record for monetate to include it in the results to bolster the possibility of matches, monetate appends a wildcard suffix to the last word of the search term (for example, the search term hooded jacket becomes hooded jacket , and monetate then looks for records containing hooded and any words beginning with jacket) fuzzy and this value indicates a search method that is the same as the wildcard and query but with a certain amount of fuzziness, or approximate string matching, to account for spelling mistakes (for example, using this query type, monetate can still match the search term hooder jakcet to records containing hooded and jacket ) wildcard or this value indicates an or search method , so monetate must find at least 1 of the search term words in a record to bolster the possibility of matches, monetate appends a wildcard suffix to the last word of the search term (for example, the search term hooded jacket becomes hooded jacket , and monetate then looks for records containing hooded or any words beginning with jacket ) fuzzy or this value indicates a search method that is the same as the wildcard or search method but with a certain amount of fuzziness, or approximate string matching, to account for spelling mistakes (for example, using this search method , monetate can still match the search term hooder jakcet to records containing hooded or jacket ) and this value indicates that monetate must find all the words of a search term exactly as typed in a record to include it in the results (for example, with this search method , a search for hooded jacket only yields records that contain hooded and jacket ) or this value indicates that monetate must find at least 1 of the words of a search term exactly as typed in a record to include it in the results (for example, with this search method , a search for hooded jacket yields records that contain hooded or jacket or hooded jacket ) here's an example query request with the fuzzy or search method specified in the typeofsearch key value pair, along with the response example query request with search method specified { "searchtoken" "monetate 156925593843210765", "recordqueries" \[ { "id" "productsearch", "typeofrequest" "search", "settings" { "typeofsearch" "fuzzy and", "query" { "term" "hooder jakcet" }, "limit" 5, "typeofrecords" \[ "monetate product" ], "fields" \[ "id", "name", "price" ] } } ] } response { "queryresults" \[ { "id" "productsearch", "meta" { "qtime" 6, "noofresults" 5, "totalresultsfound" 104, "typeofsearch" "fuzzy and", "offset" 0, "debugginginformation" {}, "notificationcode" 1, "searchedterm" "hooder jakcet", "searchtoken" "monetate 156925593843210765", "ispersonalised" false }, "records" \[ { "price" "95 00", "id" "31366431146046", "name" "mybrand hooded jacket" "searchclicktoken" "monetate nirsc2lje2njixt3aumynze3mjextyjd" }, { additional records } ] } ] } including fallback queries while you can present a customer with a "no results found" message when their search term yields no products or other results, you can configure a personalized site search queries docid\ gwgtooic olmkssgmarow that includes a backup that presents the customer with the results from another query that might interest them not only does a fallback query present the customer with results in lieu of a "no results found" message, it doesn't require additional http requests furthermore, the fallback query doesn't jeopardize the initial query's performance to include a fallback query in a request, add the fallbackqueryid key to the initial search query, and use its value to identify the fallback in a second query in the same request, pass the id key with the same value as the value of the fallbackqueryid key, the boolean key isfallbackquery with the value true , along with the other required key value pairs and any optional key value pairs you can add the fallbackqueryid key value pair only to the initial search query you cannot add a fallback query to a fallback query personalized search triggers the fallback query only when the initial query fails to return the minimum number of results, which you define using the fallbackwhencountlessthan key value pair for example, if you want the fallback query to supply results only if the initial query yields fewer than two results, then pass "fallbackwhencountlessthan" 3 in the initial query if the value of isfallbackquery is false , then personalized search triggers the fallback query even when the initial query returns enough results to meet or exceed the value of fallbackwhencountlessthan the results of the fallback query are added to those from the initial query, which could potentially double the number of results the default value of isfallbackquery is false here's an example of a personalized site search request that includes a fallback query along with its response example query request with fallback { "searchtoken" "monetate 156925593843210757", "recordqueries" \[ { "id" "productlist", "typeofrequest" "search", "settings" { "query" { "term" "pickleball shorts" }, "typeofsearch" "fuzzy or", "limit" 5, "typeofrecords" \[ "monetate product" ] "sort" "relevance", "fallbackqueryid" "productlistfallback", "fallbackwhencountlessthan" 3 "fields" \[ "id", "name", "price" ] } }, { "id" "productlistfallback", "typeofrequest" "search", "isfallbackquery" "true", "settings" { "query" { "term" "short" }, "typeofsearch" "and", "limit" 5, "typeofrecords" \[ "monetate product" ] "sort" "relevance", "fields" \[ "id", "name", "price" ] } } ] } response { "queryresults" \[ { "id" "productlist", "meta" { "qtime" 1386, "noofresults" 5, "totalresultsfound" 0, "typeofsearch" "fuzzy or", "debugginginformation" {}, "notificationcode" 1, "searchedterm" "pickleball shorts", "searchtoken" "monetate 156925593843210757", "ispersonalised" false }, "records" \[] }, { "id" "productlistfallback", "meta" { "qtime" 169, "noofresults" 5, "totalresultsfound" 104, "typeofsearch" "and", "debugginginformation" {}, "notificationcode" 1, "searchedterm" "short", "searchtoken" "monetate 156925593843210757", "ispersonalised" false }, "records" \[ { "id" "31366431146046", "name" "erika running short" "price" "45 00", "searchclicktoken" "monetate niisc2lje2njixe3aumcnze3mjexiycd" }, { additional records } ] } ] } sorting results by default, records are sorted by relevance to the search term you can specify another order by including the sort key value pair in the settings object example query request with sorting { "searchtoken" "monetate 156925593843210765", "recordqueries" \[ { "id" "productsearch", "typeofrequest" "search", "settings" { "query" { "term" "short" }, "limit" 5, "sort" "price asc" "typeofrecords" \[ "monetate product" ] } } ] } the value options for sort are as follows value description relevance the default sort order, with sorting based on a combination of personalized search's machine learning and your merchandising configurations price asc sort by the value of saleprice in each record (the value of the sale price attribute in the mapped product catalog) in ascending order, or by the value of price if the mapped product catalog doesn't include a sale price price desc sort by the value of saleprice in each record (the value of the sale price attribute in the mapped product catalog) in descending order , or by the value of price if the mapped product catalog doesn't include a sale price name asc sort by the value of name in alphabetical order name desc sort by the value of name in reverse alphabetical order rating asc sort by the average rating for each result in ascending order, if the mapped product catalog includes rating information rating desc sort by the average rating for each result in descending order, if the mapped product catalog includes rating information new arrival asc sort by the date each record was published in ascending order new arrival desc sort by the date each record was published in descending order setting up pagination a page of search results contains a number of records up to the limit key value pair specified in the settings object additional pages containing records beyond that limit can be created by repeating the query request with the offset key value pair example query request with offset { "searchtoken" "monetate 156925593843210765", "recordqueries" \[ { "id" "productsearch", "typeofrequest" "search", "settings" { "query" { "term" "short" }, "limit" 5, "offset" 5, "typeofrecords" \[ "monetate product" ] } } ] } the value of the offset key indicates how many records should be skipped in this example, the returned records are the sixth through tenth matches to properly paginate the search results, repeat the request while incrementing the offset in multiple values of the limit for example, if the limit is 5 , then the offsets in the sequence of requests should be 0 , 5 , 10 , 15 , 20 , and so on