最佳实践

以下最佳实践适用于 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% 的时间内都能实现亚秒级延迟。