最佳实践

以下最佳实践适用于 Actions Center 本地生活服务广告端到端集成，可用于避免易用性和性能问题。 数据质量较低可能会导致商品目录遭到移除。

Feed

  • 如果服务没有固定时长，请将可用性 Feed 中的 duration_sec 设置为以下其中一项：
    • 以合理的方式执行服务所需的秒数。

    • 完成服务所需的平均秒数。

  • 在商家的 Feed 中输入特定的 Category 字段。例如，餐馆可以提交特定的类型，如法式或日式。如需了解详情，请参阅地点类型，了解可能的类别值。

  • 在商家 Feed 的 Terms 字段中设置商家专用服务条款，以便在预订按钮下方显示以下备注：

    继续操作即表示您同意 <merchant> 的服务条款。
    在本例中，“服务条款”是一个链接，点击该链接可查看“条款”文本字段中设置的文本。

  • 使用 gzip 压缩 Feed

预订服务器

如需优化 Maps Booking API 的集成，请执行以下操作：

  • 始终使用世界协调时间 (UTC) 格式的 UNIX 时间戳。
  • 调用 CreateBooking API 中的新预订时，生成唯一的预订 ID。

实时更新

为确保在预订过程中提供最佳用户体验，请执行以下操作：

  • 对于标准实现，请使用 BookingNotifications API 更改预约的开始时间、时长和预订状态，例如取消或未出席。
  • 如果您这边对 Actions Center 预订有任何更改，请始终使用 BookingNotification API 从系统实时发送实时预订更新，以免 Actions Center 端的数据过时。例如，您可以在操作中心内取消、重新安排或更新预订。
  • 对于来自 UpdateBookingRequest 的每次预订更新，请确保 UpdateBookingResponse 值包含预订 ID，并且所有更新后的字段都必须反映新值。
  • 如果实现了 Inventory RTU
    • 每次调用 API 时，只能批量更新 100-1,000 个槽。
    • 使用 *Restrict（例如 startTimeRestrict）字段可缩小修改目标范围、缩减载荷大小并避免重新发送过多未更改的数据。
    • 如果拆分了多个线程，请实现指数退避算法以防止限制错误。如果未正确实现指数退避算法，则可能会收到 RESOURCE_EXHAUSTED 配额错误。您可以重试指数退避算法来处理它们，但如果您发现服务器在运行 ReplaceServiceAvailability 时经常达到配额，请将服务器配置为批量替换可用性。此解决方案可以防止出现配额错误，因为它可以减少您的服务必须进行的 API 调用次数。
  • 将 API 调用响应时间限制设置为不超过 1 秒。确保您的服务器每秒可处理五次查询 (QPS)，且至少在 95% 的时间内都能实现亚秒级延迟。