Understanding match mode settings in Oracle Commerce Cloud Guided Search

The first step for retrieving results in Oracle Commerce Cloud Guided Search is matching your keywords in a given Search Interface. For example, if a shopper enters multiple search terms, different levels of matching can occur.

By default, a match mode called “matchallpartial” is what controls the matching. With matchallpartial, it first tries to match all of the entered terms against the fields in the search interface. If zero results are found, it then falls back on partial matching. This will return results that contain a subset of the total number of search terms.

Let’s go through some examples using the default settings:

• If the user enters in 1 term, it will have to match that term
• If the user enters in 2 terms, by default it has to match both of those terms
• If the user enters in 3 terms, it first tries to match all 3. If zero results are found, it then returns results that match the different combinations of 2 terms.
• For 4 terms, it’s similar. First, it tries all 4. If nothing matches, it returns results for combinations of 3 terms.

NOTE: In general, based on analytics gathered by our sites, most shoppers are only entering 1 or 2 terms, sometimes 3. Very rarely are shoppers entering 4 or more terms. So it makes sense to optimize for those 1, 2 and 3 term scenarios.

Changing your Match Mode

Guided Search has options to change your match mode, although we recommend using the default matchallpartial documented above. Some other match modes to consider:

• matchall : This requires matching all terms. If there are zero, then that’s it.
• matchpartial: This requires matching subsets of the terms all of the time. This will give you more results.
• matchpartialmax: This is an interesting alternative to matchallpartial. It first tries to match all terms, and if zero records are found, it then tries combinations in descending order. For example, if 5 terms are entered with zero results, it then tries combinations of 4. If there are still no results, then combinations of 3, and so forth. As mentioned above, however, most shoppers are not entering 4+ terms.

There is no configuration for updating the match mode. Instead, it must be placed on the URL as the Ntx= parameter. An example: &Ntx=mode matchall

Changing your partial match settings

Considering the default behavior mentioned above, when a shopper enters 2 terms it must match both of them. This prevents questionable results from coming back by default. Imagine you were searching for “blue shirts,” but there were no matches for “shirts” on its own. The default settings prevent results for just “blue” from coming back.

However, you may wish to change this default behavior. You can tweak a couple of settings:

• maxWordsOmmitted: Specifies the maximum number of terms that can be ignored in the user query. If Omit at most value is set to zero, any number of words can be ignored. By default, this value is set to 1.
• minWordsIncluded: Specifies the minimum number of terms that each result must match. If there are not enough terms in the original query to satisfy this rule, then the entire query must match. By default, this value is set to 2.

In our example of 2 search terms, the default value of minWordsIncluded=2 is what prevents results matching only 1 term from being returned.

In our example of 4 search terms, the default value of maxWordsOmmitted=1 is why combinations of 3 results are returned, but not 2.

By default, your site uses /gsadmin/v1/cloud/searchInterfaces/All as the search interface.

You can perform the following procedure to change the above settings:

1. GET /gsadmin/v1/cloud/searchInterfaces/All
2. Create the “partialMatch” JSON configuration
3. PUT /gsadmin/v1/cloud/searchInterfaces/All
4. POST /gsadmin/v1/cloud/tasks { “type” : “publish” } to promote the changes. Alternatively, if you publish a catalog change, the next indexing job will take care of promoting those changes.

Here’s an example where the shopper enters 2 terms, and the configuration would allow partial matches of 1 term to be returned:

{
    "ecr:type": "search-interface",
    "crossFieldMatch": "always",
    "partialMatch" : {
        "maxWordsOmmitted" : 1,
        "minWordsIncluded" : 1
    },
    "fields": [
       {
          "attribute": "product.displayName"
       },
       {
          "attribute": "product.category"
       }
}

Final thoughts

It’s always a good idea to view your search metrics and reports to see what shopper behavior on your site is like. Be careful with pushing out search configuration changes just to fix one or two scenarios. Remember that there are other options for adjusting your search results.

• keyword redirects
• dynamic curation rules
• boosting and burying products specifically

Note also that the match mode only controls which products are returned. It does not control the ordering of search results. That is called Relevancy Ranking, and is a topic covered in a previous article, “Understanding and Controlling the order of search results in Oracle Commerce Cloud.”

OCI Free Tier

By the way, if you’re into OCI or haven’t started experimenting with it yet, sign up for an OCI Free Tier account to use services like block storage, database, and compute for an unlimited time.

Join the conversation!

If you’re curious about the goings-on of Oracle Developers in their natural habitat, come join us on our public Slack channel! We don’t mind being your fish bowl 🐠

Photo by Saffu on Unsplash