步驟 5：上線及監控
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
商家上線時，Google 會在實際執行環境中啟用所有符合資格的廣告空間。到這裡就代表整合作業已完成，外部使用者將可透過 Actions Center 預訂庫存清單項目。
商家上線後，請務必監控整合作業的狀態。您必須維持下列門檻標準，否則將會導致整合遭移除。
動態饋給
- 動態饋給應每日傳送，且不可出現任何錯誤或警告
- 處理指示應設為 PROCESS_AS_COMPLETE
- 對於供應情形動態饋給，完整商品目錄每日動態饋給上傳作業不應設定任何
_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 分鐘以下 |
您可以透過各種合作夥伴入口網站資訊主頁 (包括動態饋給、預訂伺服器和即時更新資訊主頁) 來監控錯誤率。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-07-26 (世界標準時間)。
[null,null,["上次更新時間：2025-07-26 (世界標準時間)。"],[[["\u003cp\u003eGoogle enables eligible inventory for external user booking upon integration launch through Actions Center.\u003c/p\u003e\n"],["\u003cp\u003eMaintaining specific thresholds for feeds, booking server, and real-time updates is crucial for sustained integration.\u003c/p\u003e\n"],["\u003cp\u003eFailure to consistently meet these performance benchmarks, including error rates and latency, will result in integration takedown.\u003c/p\u003e\n"],["\u003cp\u003ePartners can monitor integration health and error rates through dedicated dashboards within the Partner Portal, covering feeds, booking server, and real-time updates.\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 5: 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."]]
