Filter products for conversational search

This page serves as a guide to implement conversational product filtering for Vertex AI Search for commerce. This document provides data-backed best practices to ensure a successful implementation of conversational product filtering for mid-to-large retail businesses.

Vertex AI Search for commerce conversational product filtering is an AI-powered tool that transforms search into a guided experience to accompany shoppers when they interact with large product catalogs. When a site user performs a broad search (like coffee table or red dress) that returns thousands of results, conversational product filtering intelligently prompts them with follow-up questions to quickly narrow down their options.

Business use case

The conversational product filtering capability in guided search is specifically designed to address broad, ambiguous or very nuanced search queries. Applying filters to narrow the results significantly increases both revenue and user engagement.

The primary goal is to help shoppers find the right items quickly and intuitively.

Businesses use conversational filtering to:

• Accelerate product discovery: Help shoppers quickly narrow down vast product selections (such as going from 5,000 area rugs to a few hundred targeted results) by asking relevant questions.
• Refine personalization: The questions and multiple-choice options are custom for every query, based on historical filter usage data for that specific query (coffee table is historically filtered by color more often than size, so color can be asked first).
• Simplify implementation: Questions are predesignated for product attributes such as color and width, with one question per attribute.

One-way conversation user journey

Conversational product filtering operates as a one-way conversation that accompanies the shopper throughout their search journey on an ecommerce site. The AI model asks the shopper a question, and the shopper answers.

1. The shopper initiates a search query. Example: area rugs

2. The retail site returns 80+ pages of product results.

3. Vertex AI Search for commerce asks the shopper on the site a question to help narrow their search. Example: Which color are you looking for?

4. The shopper selects an answer from a list of multiple-choice or free-text options. Example: blue

5. The product results on the page are immediately filtered based on the shopper's selection.

6. Search then presents the next most relevant follow-up question. Example: What shape are you looking for?

Figure 1. Conversational filtering user journey.

Follow-up questions in search

If conversational product filtering is enabled, follow-up questions on the site drive a conversation that ensues until one of the three following scenarios occur:

• A preconfigured minimum product count is reached (a conversation is not useful when only two products show up).
• The user clicks on a product and adds it to their cart (the objective).
• Conversational product filtering runs out of AI-generated questions.

Use as an alternative to dynamic facets

Dynamic facets are associated with broad queries and resulting high search return counts, which leads to low revenue per query. End users can become overwhelmed when they see tens of thousands of results and abandon the search. Conversational search is able to refine queries and can be used with dynamic facets. Conversational product filtering offers some advantages over dynamic facets, being more human, more interactive, and using less on-page real estate.

For more information, refer to the Facets page.

Edit generative questions

Conversational product filtering encourages a human-in-the-loop interaction with the generative AI questions by allowing retailers to preliminarily edit, overwrite, or deselect AI-generated questions according to their preferences, based on the uploaded catalog. Questions can be edited or disabled individually or in bulk in the Search for commerce console or the API in order to tailor the questions they want to appear in the search.

User interaction with filters

This section describes how to configure conversational product filtering. Replacing static, hard-coded filter elements with dynamic conversational filtering to free up screen space for more targeted products is recommended. All applied filters, regardless of their origin, should globally update the product grid.

Subsequent conversational questions should intelligently adapt to the complete set of applied filters, offering both multiple-choice and free-text input options.

Unified global filters

Shoppers can interact with both conversational filters and any remaining classic filter elements. Your frontend implementation must be able to handle this scenario.

• Global application: When a user makes a selection from any filter element on the page, whether it is a conversational product filter or classic filter element, the product grid must update to show results with all global filters applied.
• Intelligent follow-up: The next conversational question the user sees should be relevant based on the complete set of applied filters applies, regardless of which element the user selects. For example, if a shopper selects a color filter from the conversational element and a size filter from the classic filter element, the subsequent conversational question should not ask the shopper what size they want.

Filter types

Conversational product filtering enables the option to use both multiple choice selections and free text user input.

Multiple choice

Vertex AI Search for commerce can present up to 20 multiple-choice options, based on the value names in the product catalog. Options appear in a sorted list of the most relevant choices. As previously noted, for long options (such as long brand names), ensure users can side-scroll rather than wrap to new lines, to maintain vertical compactness.

Free text input

The product filtering feature supports free text input, allowing shoppers to enter their own answer if the option they are looking for isn't listed. While this option exists, more customers opt for multiple choice selections.

If you implement free text, consider a button that says Type your own which, when clicked, reveals a visual display for a text input window directly on the page, or opens a separate dialog window for text input.

Replace hard-coded elements

Many commerce search site developers have prebuilt, manual category filter components in their web interface intended for top revenue-generating queries. These are typically time-consuming to produce, expensive, and not very dynamic.

Figure 2. Example of hard-coded element display.

• Recommendation: The core idea behind conversational filtering is to enable you to quickly deploy dynamic experiences like these across all you products, not just for the few top queries that the visual elements were designed for. Therefore, identify and remove elements that conversational filtering is designed to replace. Avoid having two competing sets of filter elements that perform similar functions. This frees up space on the screen to be able to show more targeted products.

Data ingestion and quality

The Vertex AI model's intelligence is built on user interaction data. The onboarding process uses a two-phased approach to data ingestion.

Phase 1: Initial start with historical events

To begin, the model can be trained on historical event data. This data is initially ingested into the Google environment, allowing the model to be effective even on new projects with no live interaction data.

Phase 2: Transition to live query data

After the capability is live and collecting data, Vertex AI uses the live query data stream to refine the serving model. The live query data is generally of higher quality than historically captured event data as historical events can sometimes be missing key information. This makes live query data more effective for ongoing optimization.

User experience design principles for conversational filtering

Successful implementation of conversational product filtering relies on well-thought-out user experience design.

Visual display elements

The placement and appearance of the conversational filter significantly impact its effectiveness.

Handle long attributes

If multiple-choice options are long (such as brand names), do not wrap them to new lines as this adds height to the elements. Instead, allow them to extend horizontally off the page and enable side-scrolling.

Here is an example of a horizontal scroll implementation:

Figure 3. Example of horizontal element display.

Optimize filter placement

Begin by placing the conversational filter in a prominent position, typically where content first appears, which has yielded positive results. A key takeaway for this placement is that the conversation filtering bar should be as vertically compact as possible. When the conversational product filtering feature is positioned prominently, it can shift product displays further down the page, out of immediate view. This can be a drawback, as shoppers see fewer products. Therefore, the products that are visible must be as relevant as possible.

Additionally, consider placing the conversational filter further down the page, perhaps after three to five rows of products. This approach prevents the conversational element from significantly displacing the initial product displays.

If conversational product filtering becomes your main method for narrowing product selections, think about fully minimizing, or even replacing, your current manual filter bar. This could allow you to add another column of product items.

Desktop and mobile

While desktop implementations have proven successful, results on mobile have been less consistent and have shown lower overall performance gains. The limited screen size on mobile requires a more creative and deliberate approach to placement.

• Recommendation: Prioritize desktop implementations over mobile, at first. The larger screen size on desktop allows for greater flexibility in creative designs. The smaller screen on mobile forces developers to prioritize certain elements.

• Avoid: Chat window interfaces. Do not implement the conversational filter as a chat window. This takes users away from the main web interface and can disrupt the intended web checkout flow design that developers typically spend considerable time optimizing.

Additional mobile considerations

Mobile web and apps should also be treated independently when it comes to testing. Mobile app testing is inherently difficult to conduct, but offers greater flexibility in customization. Mobile web is often quicker to test, but comes with different tradeoffs for various mobile web browsers.

Ideas for experimentation

• Placement between product rows: Insert the component partway down the page, after three to five rows of products. This approach prevents the conversational element from significantly displacing the initial product displays.
• Fly-out / pop-up: Use a button that triggers a dialog or fly-out menu containing the filter questions. This could be integrated with existing filter pop-ups or be a separate element.
• Sticky bar: A persistent bar on the screen presents the questions and options. This sits in front of the products rather than pushing them down.
• Testing considerations: When testing mobile and desktop, ensure that these experiments are conducted independently. The shopping behaviors for each device vary greatly, and the visual components that work on one device might not translate to the other.

Developer's guide

The following is a developer's guide on how to integrate conversational product filtering in your API.

Admin experience

Manage the generative questions and conversational product filtering directly in the API, or in the Search for commerce console, and set it up in the Data quality and Evaluate sections of the Search for commerce console.

// Configuration for overall generative question feature state.
message GenerativeQuestionsFeatureConfig {
...

// Resource name of the affected catalog.
// Format: projects/{project}/locations/{location}/catalogs/{catalog}
string catalog = 1 [(google.api.field_behavior) = REQUIRED];

// Determines whether questions are used at serving time.
// Note: You cannot enable this until initial data requirements are
// satisfied.
bool feature_enabled = 2 [(google.api.field_behavior) = OPTIONAL];

// Minimum number of products in the response to trigger follow-up questions.
// Value must be 0 or positive.
int32 minimum_products = 3 [(google.api.field_behavior) = OPTIONAL];
}

Serving experience

Conversational product filtering is based on engaging the user with an ongoing conversation of multiple turns. Therefore, there is at least a second response required for conversational product filtering to work. The user is presented with a follow-up question and suggested answers in the response. The user can respond to this follow-up question either by entering their answer or by clicking on a suggested answer (multiple choice option).

• Multiple choice The multiple choice option functions behind the scenes like a facet (an event type filter), which narrows the query using filtering. In the background, when the user clicks on a multiple choice response, a filter is applied to the query. Applying a filter using conversational multiple choice is identical to applying the same filter using dynamic facets or tiles.

• Free text If the user responds in free text, a new and narrower query is generated. Learn more about how conversational product filtering enriches filter and user event capturing at the API level.

Service enabled by the feature

The generative questions service (service GenerativeQuestionService{...}) is used for managing LLM-generated questions. Its parent object is the catalog, where it retrieves information to return questions for a given catalog. The service is used to manage the overall generative question feature state, make individual or batch changes, and toggle questions on or off. Data requirements must be met to interface with the Service API and the questions need to first be initialized before they can be managed.

The service interacts with the feature level and question level configs with two sets of handlers:

• GenerativeQuestionsFeatureConfig handlers (feature-level):

  1. Update lets you change minimum products and enable fields.
  2. Get returns an object.

• GenerativeQuestion Config handlers (question-level):

  1. List returns all questions for a given catalog.
  2. Update performs individual question management.
  3. Batch Update performs grouped question management.

The service returns a semantically appropriate question based on the initial query.

A follow-up question is generated by the LLM model and can be overridden. The questions are displayed based on how likely it is used by customers by calling the search event history. If there is no search event history, the fallback is on the commerce search logs.

Different questions are generated based on the previous query. There are no fixed weights. The AI that drives the LLM-generated questions learns from the queries and changes the weighting for every query, so that "shirt", for example, weighs the category very heavily, but "XL red shirt" weighs category, size and color.

Configure the serving experience

Configure the serving experience by integrating the conversational filtering configuration API with the Search API.

User journey in the API

The conversational flow works as follows: The user initiates a search with an initial query and sets the mode flag to CONVERSATIONAL_FILTER_ONLY. The user then selects an answer or provides free-text input, which is sent back to the API using the user_answer field.

The Conversational API provides the additional_filter field in the response. The user must apply these filters to the Search API follow-up request. The search results are based on the user's input and provide a new follow-up question, prompting a follow-up query and continuing the conversation in multiple turns until the user finds what they're looking for on the retailer website.

User scenarios

Assuming conversational product filtering is enabled on the website, the user journey and subsequent interaction with Vertex AI Search for commerce follows this path:

• Step 1. First query comes from user to both Search and Conversational API. The Search API only returns search results. The Conversational API returns the suggested answers and follow-up questions. Call the Search API for the same query or page_category and fetch the search results.
• Step 2. Follow-up conversation requested is sent to conversational search. Call the Conversational API with the right conversation filtering mode.
• Step 3. Initial search response with search results only. The Conversational API refines the query by returning the suggested answers and follow-up questions.
• Scenario A: User selects multiple choice.
  • Step 1A. Selected answer filter sent to the Conversational API.
  • Step 2A. Both Conversation and Search APIs run with applied filter.
• Scenario B: User selects free text.
  • Step 1B. Text answer sent to the Conversational API. Use the Conversational API to send the user answer.
  • Step 2B. The user gets a conversational follow-up question with some suggested answers in the Conversational response. Search run again with a modified query. Conversational API sends another question and additional_filter. This filter must be applied to the search results fetched from the Search API in the first step.

Step 1. First query comes from user

The conversationalFilteringMode mode in the Conversational API is option and the default DISABLED can be set to ENABLED to control conversational filtering.

First, developers need to create the following search request by setting the product or item as the query, in this example, "dress":

{
  query: "dress",
}

Additional actions on the client side to enable conversationally filtered searches:

• Developers must also create a conversational search request by setting "dress" as the query.

• Developers must set mode to CONVERSATIONAL_FILTER_ONLY in order to get a conversational response. Otherwise, if it's set to DISABLED, no follow-up question is supplied.

Step 2. Retailer → search: Initial query with conversation enabled

{
  "query": "dress",
  "conversational_search_spec":  {
    "mode": "CONVERSATIONAL_FILTER_ONLY"
  }
}

Step 3. Search → retailer: conversation ID, refined query, follow-up question, suggested answers

{
  conversation_id: "c154d073-87f5-4edb-accd-587eabe014ff"
  refined_query: "dress"
  conversational_filtering_result: {
    followup_question{
      followup_question: "What is the color?"
      suggested_answers {
        product_attribute_value {
          name: "colors",
          value: "yellow"
        }
      }
    suggested_answers {
      product_attribute_value {
        name: "colors",
        value: "blue"
      }
    }
    suggested_answers {
      product_attribute_value {
        name: "colors",
        value: "red"
      }
    }
   }
  }
}

Conversational product filtering serves these options for continued conversational engagement, leading to faster search refinement:

Scenario A: User selects a multiple choice option

If a user selected a multiple choice answer yellow:

• Developers must restore the conversation_id from session storage.
• Set mode to be CONVERSATIONAL_FILTER_ONLY.
• Set user_answer for what user selects.

Step 1A. Retailer → search: selected answer filter

{
  query: "dress"
  conversation_id: "c154d073-87f5-4edb-accd-587eabe014ff"
  conversational_search_spec {
    "mode": "CONVERSATIONAL_FILTER_ONLY"
    user_answer {
      selected_answer {
        product_attribute_value {
          name: "colors"
          value: "yellow"  
        }
      }
    }
  }
}

Step 2A. Search → retailer: filters applied

{
  conversation_id: "c154d073-87f5-4edb-accd-587eabe014ff"
  refined_query: "dress"
  conversational_filtering_result {
    additional_filter {
      product_attribute_value {
        name: "colors",
        value: "yellow"
      }
    }
    followup_question{
    followup_question: "What is the occasion?"
    suggested_answers {
      product_attribute_value {
        name: "attribute.occasion",
        value: "wedding"
      }
    }
    suggested_answers {
      product_attribute_value {
        name: "attribute.occasion",
        value: "party"
      }
    }
  }
 }
}

Scenario B: User selects a free text input

If a user types in lavender:

• Developers should restore the conversation_id from session storage.
• Set followup_conversation_requested to be true.
• Set user_answer for what user inputs (with the "text_answer:" prefix).

Step 1B. Retailer → search: text answer

{
  query: "dress"
  conversation_id: "c154d073-87f5-4edb-accd-587eabe014ff"
  conversational_search_spec {
    "mode": "CONVERSATIONAL_FILTER_ONLY"
    user_answer: {
        text_answer: "lavender"
    }
  }
}

Step 2B. Search → retailer: run with modified query

{
  conversation_id: "c154d073-87f5-4edb-accd-587eabe014ff"
  refined_query: "lavender dress"
  conversational_filtering_result {
    Followup_question {
    followup_question: "What is the occasion?"
    suggested_answers {
      product_attribute_value {
        name: "attribute.occasion"
        value: "wedding"
      }
    }
    suggested_answers {
      product_attribute_value {
        name: "attribute.occasion"
        value: "party"
      }
    }
  }
 }
}

Iterative improvement with testing

Conversational product filtering is an ongoing process of optimization, requiring continuous refinement and data-driven decisions. The goal is to maximize feature effectiveness by understanding shopper behavior and adapting the design accordingly.

Shopper behaviors are dynamic and evolve over time, influenced by various factors such as market trends, competitor offerings, and changes in personal preferences. It is crucial to experiment continuously. Continue to iterate on your designs and test new approaches as you gather more data and observe how shoppers interact with the AI features. This ongoing cycle of experimentation, data analysis, and refinement ensures that the AI features remain relevant, effective, and optimized for an evolving user base.

Regularly review performance metrics, conduct user surveys, and analyze feedback to identify areas for improvement and new opportunities for innovation. This commitment to continuous iteration is key to long-term success in AI feature deployment.

Lessons learned

• Experiment continuously: The optimal result is often not the first design you try.
• Iterate and adapt: User behaviors evolve. Continue to iterate on your designs and test new approaches as you gather more data and observe how shoppers interact with the feature.
• Beyond A/B: Don't limit yourself to just A/B testing (comparing two versions). Instead, conduct many A/B/C/D/E/F tests to explore a wider range of UI designs and placement options.

Key metrics for optimization

To effectively optimize Vertex AI Search for commerce, it's crucial to define and track relevant metrics that provide insights into user engagement, satisfaction, and the overall impact of the features. Key metrics to consider include:

• Conversion rate: The percentage of users who complete the targeted action, such as making a purchase.
• User satisfaction scores (such as NPS, CSAT): Direct feedback from users on their experience with the AI feature, providing qualitative insights into usability and perceived value.
• Adoption rate: The percentage of shoppers that actively use conversational product filtering, indicating its visibility and perceived utility.