以下最佳实践适用于 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% 的情况下处于次秒级延迟。