最佳做法

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

動態饋給

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

  • 請在商家動態饋給中提供特定的 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% 的時間以不到一秒。