最佳做法

下列最佳做法適用於 Actions Center 在地生活服務廣告端對端整合，並有助於避免可用性和效能問題。如果資料品質偏低，可能會導致商品目錄遭到下架。

動態饋給

• 如果服務沒有固定的長度，請將供應情形動態饋給中的 duration_sec 設為下列其中一個值：
  • 以合理方式執行服務所需的秒數。

  • 完成服務所需的平均秒數。

    注意：如果您在動態饋給中提交了 0 的長度，系統會將該時段視為無效，不會顯示在 Actions Center 中。
• 請在商家動態饋給中提供特定的 Category 欄位輸入內容。舉例來說，餐廳可能會提交法文或日文等特定類型資訊。詳情請參閱「地點類型」一文，瞭解可能的類別值。

• 請在商家動態饋給的 Terms 欄位中設定商家專屬服務條款，讓「書籍」按鈕下方顯示以下附註：

  選擇繼續即表示您同意「<merchant>」的《服務條款》。

  在此例中，「服務條款」是一個連結，按下後會顯示「terms」文字欄位內設定的文字。

• 使用 gzip 壓縮動態饋給

Booking Server (預訂伺服器)

如要最佳化 Maps Booking API 的整合，請按照下列步驟操作：

• 一律使用世界標準時間格式的 UNIX 時間戳記。
• 在 CreateBooking API 中呼叫新的預訂時，產生專屬的預訂 ID。

即時更新

為確保能在預訂過程中提供最佳使用者體驗，請按照下列步驟操作：

• 如果是標準導入作業，請使用 BookingNotification API 變更預約的開始時間、時間長度和預訂狀態，例如取消或未出席。
• 您向 Actions Center 上的預訂資料發生任何變更時，請務必透過 BookingNotification API 即時從系統傳送即時預訂更新，以免 Actions Center 端的資料不會過時。舉例來說，您可以在 Actions Center 中取消、重新安排或更新系統中的預訂。
• 針對 UpdateBookingRequest 的每筆預訂更新，請確認 UpdateBookingResponse 值包含預訂 ID，且「所有」更新的欄位都必須反映新的值。
• 如果已導入廣告空間 RTU
  • 每個 API 呼叫只能以 100 至 1,000 個運算單元分批更新供應情形。
  • 使用 *Restrict (例如 startTimeRestrict) 欄位來縮小編輯目標範圍、減少酬載大小，並避免重新傳送過多未變更的資料。
  • 如果您啟動多個執行緒，請實作指數輪詢，以免發生節流錯誤。如未正確執行指數輪詢，可能會發生 RESOURCE_EXHAUSTED 配額錯誤。您可以重試指數輪詢來處理這些要求，但如果您發現伺服器在執行 ReplaceServiceAvailability 時經常達到配額，請設定伺服器批次取代可用性。這項解決方案可避免配額錯誤，因為服務可以減少服務必須發出的 API 呼叫次數。
• 將 API 呼叫回應時間限制設為不到一秒。確保伺服器能每秒處理五次查詢 (QPS)，且延遲時間至少為 95% 的時間以不到一秒。