第 7 步：发布和监控
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
发布时，Google 会在生产环境中启用所有符合条件的商品目录。这样即可完成集成，还可允许外部用户通过 Action Center 预约或预订您的商品目录。
发布后，请务必监控集成后的运行状况。相关数值应在以下阈值范围内。如未能保持在以下阈值范围内，我们将撤消集成。
Feed
- 应每天发送 Feed，且不会出现错误或警告
- 应将处理指令设置为 PROCESS_AS_COMPLETE
- 对于库存状况 Feed，每天上传的完整商品目录 Feed 不应设置任何
_restrict 字段。
预订服务器
对于所有预订服务器实现，都应包含一个 HealthCheck 路线。Google 会定期检查您的 HealthCheck 路由，如果该路由未响应或返回不健康的响应，我们将暂时停用您的集成。我们会继续定期检查您的 HealthCheck 路由，一旦其恢复返回正常响应，我们会自动恢复您的集成。
| 标准实现 |
| 方法 |
错误率阈值 |
延迟阈值 |
| CheckAvailability |
<10% |
< 5 秒 |
| BatchAvailabilityLookup |
< 3% |
<1.5 秒 |
| CreateLease |
<10% |
< 5 秒 |
CreateBooking
UpdateBooking |
< 5% |
< 4 秒 |
CreateBooking
（通过付款） |
< 5% |
< 15 秒 |
| SetMarketingPreference |
<5% |
< 5 秒 |
实时更新
对于实时更新，延迟时间是根据执行操作（例如修改预订）与“通过 Google 预订”收到实时动态更新请求之间的时间差进行衡量的。
| API |
错误率阈值 |
延迟阈值 |
| AvailabilityReplace RTU |
< 10%（每天） |
< 5 分钟 |
| BookingNotification RTU |
< 10%（每种状态每天） |
< 5 分钟 |
可通过各合作伙伴门户信息中心（即 Feed、预订服务器和实时动态更新信息中心）监控错误率。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-26。
[null,null,["最后更新时间 (UTC)：2025-07-26。"],[[["\u003cp\u003eUpon launch, your eligible inventory is activated, enabling external bookings through Google's platform.\u003c/p\u003e\n"],["\u003cp\u003eMaintaining integration requires adhering to feed, booking server, and real-time update standards to avoid deactivation.\u003c/p\u003e\n"],["\u003cp\u003eDaily error and latency thresholds are enforced for various booking server functionalities to ensure system responsiveness and reliability.\u003c/p\u003e\n"],["\u003cp\u003eReal-time updates, like availability and booking changes, must be relayed to Google within defined timeframes for accurate reflection on the platform.\u003c/p\u003e\n"],["\u003cp\u003ePartners can actively track integration performance through dedicated dashboards for feeds, booking servers, and real-time updates within the Partner Portal.\u003c/p\u003e\n"]]],["Upon launch, all eligible inventory is enabled for external user booking. Post-launch, daily feeds must be sent error-free with `PROCESS_AS_COMPLETE` and no `_restrict` fields in Availability feeds. A functioning HealthCheck route is crucial; failure results in temporary integration disablement. Booking server and real-time updates have strict error and latency thresholds. These are monitored via the Feeds, Booking Server, and Real-time Updates dashboards. Consistent failure to meet standards will result in integration removal.\n"],null,["# Step 7: Launch and monitoring\n\nAt launch, Google enables all of your eligible inventory in our production\nenvironment. This completes the integration and allows any external user to\nbook or reserve your inventory through the Actions Center.\n\nOnce you've launched, it's important to monitor the health of your\nintegration. The following thresholds must be maintained. Failure to maintain\nthese thresholds consistently will result in integration take-down.\n\nFeeds\n-----\n\n- Feeds should be sent on a daily basis with no errors or warnings\n - Processing instructions should be set to PROCESS_AS_COMPLETE\n - For Availability feeds, the full inventory daily feed upload should not set any `_restrict` fields.\n\nBooking server\n--------------\n\nFor all booking server implementations, there is a HealthCheck route that\nshould be included. Google will periodically check your HealthCheck route\nand should it not respond or return an unhealthy response, we will\ntemporarily disable your integration. We will continue to periodically\ncheck your HealthCheck route and once it resumes returning a healthy\nresponse we will automatically restore your integration.\n\n| Standard implementation |||\n| Method | Error Rate Thresholds | Latency Thresholds |\n|-------------------------------|-----------------------|--------------------|\n| CheckAvailability | \\\u003c10% | \\\u003c5s |\n| BatchAvailabilityLookup | \\\u003c3% | \\\u003c1.5s |\n| CreateLease | \\\u003c10% | \\\u003c5s |\n| CreateBooking UpdateBooking | \\\u003c5% | \\\u003c4s |\n| CreateBooking (with payments) | \\\u003c5% | \\\u003c15s |\n| SetMarketingPreference | \\\u003c5% | \\\u003c5s |\n\nReal-time updates\n-----------------\n\nFor real-time updates, latency is measured by the time difference between\nwhen an action is taken (e.g. modifying a booking) and when Reserve with\nGoogle receives the real-time update request.\n\n| API | Error Rate Thresholds | Latency Thresholds |\n|-------------------------|----------------------------------|--------------------|\n| AvailabilityReplace RTU | \\\u003c10% each day | \\\u003c5 mins |\n| BookingNotification RTU | \\\u003c10% each day \\& for each state | \\\u003c5 mins |\n\nError rates can be monitored through the various Partner Portal dashboards,\nnamely the\n[Feeds](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/feeds),\n[Booking Server](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/bookingserver), and\n[Real-time Updates](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/realtimeupdates) dashboards."]]
