以下最佳实践适用于 Action Center 预订端到端集成，可用于避免易用性和性能问题。 数据质量较低可能会导致商品目录被移除。
Feed
- 如果服务未设置时长，请将可用性 Feed 中的
duration_sec设置为以下选项之一：- 以合理的方式执行服务所需的秒数。
-
完成服务所需的平均秒数。
- 确保商家 Feed 中的
Category字段输入内容具体明确。例如，提供具体的餐厅类型（例如，是法式餐厅还是日式餐厅）。如需了解详情，请参阅地点类型，以了解可以使用的类别值。 -
在商家 Feed 的
Terms字段中设置商家专用服务条款，以便在预订按钮下方显示以下备注：继续操作即表示您同意 <merchant> 的《服务条款》。
在本例中，“服务条款”是一个链接，点击该链接即可查看“条款”字段中的文字。 -
使用
gzip压缩 Feed
预订服务器
如需优化 Google 地图预订 API 集成，请执行以下操作：
- 始终使用世界协调时间 (UTC) 格式的 UNIX 时间戳。
- 在调用
CreateBookingAPI 中的新预订时，生成唯一的预订 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% 的情况下处于次秒级延迟。