最佳做法

以下最佳实践适用于 Action Center 预订端到端集成，可用于避免易用性和性能问题。 数据质量较低可能会导致商品目录被移除。

Feed

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

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

  • 确保商家 Feed 中的 Category 字段输入内容具体明确。例如，提供具体的餐厅类型（例如，是法式餐厅还是日式餐厅）。如需了解详情，请参阅地点类型，以了解可以使用的类别值。

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

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

  • 使用 gzip 压缩 Feed

预订服务器

如需优化 Google 地图预订 API 集成，请执行以下操作：

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

实时更新

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

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