Search as you type

The modern ecommerce search bar is far more than just an input field. It's an interactive, dynamic assistant that guides your users to the right products before they even finish entering text. This search-as-you-type (SAYT) experience, which displays query suggestions, popular brands, relevant categories, and even top product results in real-time, drives user engagement and increases the likelihood of conversion.

While Vertex AI Search for commerce provides distinct APIs for query autocompletion and product search, it intentionally leaves the final implementation of a SAYT user experience open-ended.

This guide to building with Vertex AI Search for commerce explores two primary design patterns for implementing a robust SAYT widget using the Vertex AI Search for commerce APIs, detailing the trade-offs of each approach.

Understand the core components

To build a comprehensive SAYT feature, you need to understand the two fundamental APIs provided by Vertex AI Search for commerce:

  1. CompleteQuery API: This is the brains behind your autocomplete suggestions.

    • Function: For a given input string, such as lipst, it returns a list of suggested query completions, including lipstick and lip gloss, associated popular brands, and relevant categories.
    • Cost: This API is included in the Vertex AI Search for commerce package pricing.
    • Performance: It's a high-throughput API designed for the rapid, low-latency responses required for a keystroke-by-keystroke experience. It leverages auto-learning features, including spell correction and suggestions that are designed to yield results, all trained on your store's daily search events.

  2. Search API:This is your core product discovery engine.

    • Function:For a given query, it returns a ranked list of relevant product results.
    • Cost:This is a paid API, and its usage directly impacts your operational costs.
    • Events: For model training and analytics, each Search API call should ideally be paired with a search event to track user behavior and improve the relevance models over time.

To create the SAYT experience, you must write a wrapper API or frontend logic that calls both these APIs and combines their results into a single, cohesive user interface.

Implementation pattern 1: Direct but costlier approach

This is the most straightforward method to implement. The logic is for every keystroke, you make parallel calls to both the CompleteQuery and Search APIs.

Flow

The flow follows this sequential path:

  1. A user enters a character, such as l.
  2. Your application sends l to the CompleteQuery API.
  3. Simultaneously, your application sends l to the Search API.
  4. The results are combined and displayed.
  5. The user enters another character (l, making the query li).
  6. The process repeats for the new query li.

alt_text

Advantages

The advantages include fast implementation, allowing you to quickly write and deploy the log.

Disadvantages

  • High Search API volume: This approach dramatically inflates the number of Search API calls. A query like lipstick would trigger eight separate search requests, leading to a significant increase in volume.
  • Increased cost: Since the Search API is a paid service, this high volume directly translates to higher operational costs, making it difficult to achieve a positive return on investment (ROI).
  • Event management complexity: Every Search API call should be logged with a corresponding search event for accurate model training and measurement. The high volume of calls makes it challenging to ensure every event is captured, potentially leading to data loss and skewed analytics.
  • Potentially lower quality results: Searches for one or two characters, such as l, li can return noisy or overly broad results, leading to a less relevant initial experience.

This pattern optimizes for cost, performance, and relevance by using the CompleteQuery API to intelligently decide when to call the Search API.

Flow

The flow follows this sequential path:

  1. A user enters a partial text query, such as lip.
  2. Your application sends lip to the CompleteQuery API.
  3. The API returns a list of suggestions, with lipstick likely being the first result.
  4. Your application takes the first suggestion (lipstick) and makes a single call to the Search API with that term.
  5. The autocomplete suggestions and the product results for lipstick are displayed.
  6. As the user continues to type lips, lipst, ... you can add logic to only make a new search call if the first autocomplete suggestion changes.

Advantages

  • Significant cost reduction: By drastically reducing the number of Search API calls, this method keeps costs under control.
  • Controlled API and event volume: API and event volumes are manageable and predictable, ensuring more reliable data for model training and analytics.
  • Higher relevance: You are searching for more complete and probable terms, which provides higher-quality product results in the SAYT widget.
  • Better ROI: Lower costs and a better user experience contribute to a stronger return on investment.

alt_text

Handling edge cases

This approach is superior but requires handling a few corner cases:

  • No suggestions: If the CompleteQuery API returns no suggestions, your logic should fall back to calling the Search API with the user's raw input.
  • Partial vs. suggested query: In rare cases, a user might want to see results for their partial term, such as eye rather than the top suggestion, eye shadow. While this is a minor trade-off, the optimized approach prioritizes the most likely user intent.

Measure success with experiment IDs

Regardless of the implementation you choose, it's important to measure the performance of your SAYT widget independently from your main search results page. If you use the same tracking for both, you'll be unable to determine if the SAYT feature is truly improving click-through rates and conversions.

The solution to measuring click-through and conversation rates of the SAYT widget specifically is to use distinct experimentIds in your search events that differentiate these metrics from those of the main search events.

  • SAYT events: Assign a specific ID, such as "experimentId": "sayt-widget", to all search events originating from the search-as-you-type capability.
  • Main search events: Use a different ID (or no ID) for searches initiated when a user presses Enter or clicks Search to go to the main search results page.

By segmenting your events this way, you can use the analytics dashboards in the Vertex AI console to filter and compare the performance of your SAYT widget against the standard search experience, giving you clear, actionable insights.

Conclusion

Vertex AI Search for commerce provides the components for creating a search-as-you-type experience. By acting as the architect who designs the interaction between the CompleteQuery and Search APIs, you can build a search capability that builds the bridge between user experience and performance. For most use cases, the optimized approach delivers a user-relevant experience while avoiding compute-heavy operations.