动态搜索

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

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

本 AI Commerce Search 构建指南探讨了使用 AI Commerce Search API 实现强大的 SAYE 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。

流程

流程遵循以下顺序路径：

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

优点

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

缺点

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

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

流程

流程遵循以下顺序路径：

  1. 用户输入部分文本查询，例如 lip。
  2. 您的应用会将“lip”发送到 CompleteQuery API。
  3. 该 API 会返回建议列表，其中“lipstick”很可能是第一个结果。
  4. 您的应用会采用第一个建议（“lipstick”），并使用该字词对 Search API 进行一次调用。
  5. 系统会显示“lipstick”的自动补全建议和产品搜索结果。
  6. 当用户继续输入“lips”“lipst”等内容时，您可以添加逻辑，以便仅在第一个自动补全建议发生变化时才进行新的搜索调用。

优点

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

处理极端情形

此方法更胜一筹，但需要处理一些极端情形：

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

使用实验 ID 衡量成功与否

无论您选择哪种实现方式，都必须独立于主搜索结果页衡量 SAYE widget 的性能。如果您对两者使用相同的跟踪方式，则无法确定 SAYE 功能是否真正提高了点击率和转化率。

如需专门衡量 SAYE 微件的点击率和转化率，解决方案是在搜索事件中使用不同的 experimentIds，以便将这些指标与主搜索事件的指标区分开来。

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

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

总结

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