动态搜索

现代电子商务搜索栏不仅仅是一个输入字段。它是一个互动式动态助理，可在用户完成输入文字之前引导他们找到合适的产品。这种边输入边搜索 (SAYE) 的体验可实时显示搜索查询建议、热门品牌、相关类别，甚至热门商品搜索结果，从而提高用户互动度并增加转化可能性。

虽然 AI Commerce Search 为查询自动补全和 Product Search 提供了不同的 API，但它有意让 SAYE 用户体验的最终实现保持开放式。

本指南介绍了如何使用 AI Commerce Search API 构建功能强大的 SAYE widget，探讨了实现该 widget 的两种主要设计模式，并详细说明了每种方法的优缺点。

了解核心组件

若要构建全面的 SAYE 功能，您需要了解 AI Commerce Search 提供的两个基本 API：

  1. CompleteQuery API：这是自动补全建议背后的智能技术。

    • 功能：对于给定的输入字符串（例如 lipst），它会返回建议的搜索查询补全列表，包括 lipstick 和 lip gloss、相关热门品牌和相关类别。
    • 费用：此 API 包含在 AI Commerce Search 套餐价格中。
    • 性能：这是一款高吞吐量 API，旨在提供按键输入体验所需的快速、低延迟响应。它利用自动学习功能（包括旨在产生结果的拼写更正和建议），所有这些功能都基于您商店的每日搜索事件进行训练。如需了解详情，请参阅拼写校正 API 规范。

  2. Search API：这是您的核心商品发现引擎。

    • 功能：针对给定的查询，返回相关商品结果的排名列表。
    • 费用：这是一项付费 API，其使用情况会直接影响您的运营成本。
    • 事件：对于模型训练和分析，每次 Search API 调用最好都与搜索事件配对，以便跟踪用户行为并随着时间的推移改进相关性模型。

即输即搜

如需创建 SAYE 体验，您必须编写一个封装容器 API 或前端逻辑，用于同时调用这两个 API 并将它们的结果合并到一个连贯的用户界面中。

实现模式 1：直接但成本较高的方法

这是最直接的实现方法。该逻辑是，每次按键时，您都会并行调用 CompleteQuery 和 Search API。

Flow

该流程遵循以下顺序：

  1. 用户输入一个字符，例如 l。
  2. 您的应用向 CompleteQuery API 发送 l。
  3. 同时，您的应用会向 Search API 发送 l。
  4. 结果会合并并显示。
  5. 用户输入另一个字符（l，使查询变为 li）。
  6. 新查询 li. 的流程会重复执行。

优点

其优势包括实现速度快，可让您快速编写和部署日志。

缺点

  • Search API 调用量高：此方法会大幅增加 Search API 调用次数。像 lipstick 这样的查询会触发八个单独的搜索请求，从而导致搜索量大幅增加。
  • 成本增加：由于 Search API 是一项付费服务，因此这种高用量会直接转化为更高的运营成本，从而难以实现正投资回报率 (ROI)。
  • 事件管理复杂性：每个 Search API 调用都应记录相应的搜索事件，以便进行准确的模型训练和衡量。大量调用使得确保捕获每个事件变得困难，这可能会导致数据丢失和分析结果有偏差。
  • 可能返回质量较低的结果：搜索一个或两个字符（例如 l、li）可能会返回杂乱或过于宽泛的结果，导致初始体验不太相关。

此模式使用 CompleteQuery API 智能地决定何时调用 Search API，从而优化成本、性能和相关性。

Flow

该流程遵循以下顺序：

  1. 用户输入部分文本查询，例如 lip.。
  2. 您的应用会向 CompleteQuery API 发送 lip。
  3. API 会返回一个建议列表，其中 lipstick 可能是第一个结果。
  4. 您的应用接受第一个建议 (lipstick)，并使用该字词对 Search API 进行一次调用。
  5. 系统会显示自动补全建议和口红的商品搜索结果。
  6. 随着用户继续输入 lips、lipst…，您可以添加逻辑，以便仅在第一个自动补全建议发生变化时才进行新的搜索调用。

优点

  • 显著降低费用：通过大幅减少 Search API 调用次数，此方法可有效控制费用。
  • 可控的 API 和事件量：API 和事件量可管理且可预测，从而确保为模型训练和分析提供更可靠的数据。
  • 相关性更高：您搜索的是更完整、更可能的字词，这会在 SAYE widget 中提供更高质量的商品结果。
  • 更高的投资回报率：更低的费用和更好的用户体验有助于提高投资回报率。

处理极端情形

此方法更优，但需要处理一些极端情况：

  • 无建议：如果 CompleteQuery API 未返回任何建议，您的逻辑应回退到使用用户的原始输入调用 Search API。
  • 部分查询与建议的查询：在极少数情况下，用户可能希望查看部分字词（例如 eye）的结果，而不是热门建议（例如 eye shadow）。虽然这是一种小小的权衡，但优化后的方法会优先考虑最有可能的用户意图。

使用实验 ID 衡量成效

无论您选择哪种实现方式，都必须单独衡量 SAYE widget 的效果，而不是将其与主要搜索结果页的效果一起衡量。如果您对两者使用相同的跟踪方式，则无法确定 SAYE 功能是否确实提高了点击率和转化次数。

若要衡量 SAYE widget 的点击后转化率和对话率，具体解决方案是在搜索事件中使用不同的 experimentIds，以便将这些指标与主要搜索事件的指标区分开来。

  • SAYE 事件：为源自边输入边搜索功能的所有搜索事件分配特定 ID，例如 "experimentId": "saye-widget"。
  • 主要搜索事件：对于用户按 Enter 键或点击搜索以转到主要搜索结果页时发起的搜索，请使用其他 ID（或不使用 ID）。

通过这种方式细分事件，您可以使用 Vertex AI 控制台中的分析信息中心来过滤和比较 SAYE widget 与标准搜索体验的性能，从而获得清晰且富有实用价值的分析洞见。

总结

AI Commerce Search 提供用于创建边输入边搜索体验的组件。通过充当设计 CompleteQuery 和 Search API 之间交互的架构师，您可以构建在用户体验和性能之间架起桥梁的搜索功能。在大多数使用场景中，优化后的方法可提供与用户相关的体验，同时避免执行计算密集型操作。