最佳做法

以下最佳做法適用於 Actions Center 端對端在地生活服務廣告整合，可避免發生可用性和效能問題。資料品質不佳可能會導致廣告空間遭到下架。

動態饋給

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

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

• 請在商家動態饋給的 Category 欄位中輸入具體資訊，舉例來說，餐廳可以提供料理類型資訊 (例如法式或日式料理)，若想進一步瞭解詳情，請參閱地點類型頁面來瞭解可能適用的類別值。

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

  繼續操作即表示您同意 <merchant> 的服務條款。

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

• 使用 gzip 壓縮動態饋給

預訂伺服器

如要改善 Maps Booking API 整合作業，請採取下列做法：

• 請一律使用 UTC 格式的 UNIX 時間戳記。
• 在呼叫 CreateBooking API 中的新預訂時，產生唯一的預訂 ID。

即時更新

為確保預訂過程中提供最佳使用者體驗，請採取下列做法：

• 如要進行標準導入作業，請使用 BookingNotifications API 變更預約的開始時間、時間長度和預約狀態 (例如取消或未報到)。
• 在你這端的 Actions Center 預訂發生任何變更時，請務必透過 BookingNotification API 即時傳送系統的即時預訂更新，以免資料在 Actions Center 端過時。舉例來說，您可以在 Actions Center 中取消、重新安排或更新系統中的預訂。
• 對於 UpdateBookingRequest 的每項預訂更新，請確認 UpdateBookingResponse 值包含預訂 ID，且所有更新的欄位都必須反映新的值。
• 如果已導入商品目錄 RTU
  • 每個 API 呼叫只能批次更新 100 到 1000 個時段的預訂情況。
  • 使用 *Restrict (例如 startTimeRestrict) 欄位來縮小編輯目標、減少酬載大小，並避免重新傳送太多未變更的資料。
  • 如果您衍生出多個執行緒，請導入指數輪詢，以免發生節流錯誤。如果您未正確導入指數輪詢，可能會收到 RESOURCE_EXHAUSTED 配額錯誤。您可以重試指數型延遲來處理這些問題，但如果您發現在執行 ReplaceServiceAvailability 時，伺服器經常達到配額上限，請將伺服器設為批次取代預訂情況。這個解決方案可減少服務器必須發出的 API 呼叫次數，進而避免配額錯誤。
• 將 API 呼叫回應時間限制設為不到一秒。請確認伺服器可在至少 95% 的時間內，每秒處理五次查詢 (QPS)，且延遲時間不到 1 秒。