最佳做法

下列最佳做法適用於「透過 Google 預訂」端對端整合，並可用來避免可用性和效能問題。 資料品質不佳可能導致廣告空間下架。

動態饋給

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

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

  • 請在商家動態饋給中為 Category 欄位提供具體資訊。舉例來說，餐廳可以提交特定類型，例如法文或日文。詳情請參閱地點類型來瞭解可能的類別值。

  • 在商家資訊提供的 Terms 欄位中設定商家專屬的服務條款，在 [Book] 按鈕下方顯示下列注意事項：

    選擇繼續即表示您同意 <merchant> 的《服務條款》。
    在這種情況下，「服務條款」是一種連結，按下後就會顯示 terms 文字欄位中設定的文字。

  • 使用 gzip 壓縮動態饋給

Booking Server (預訂伺服器)

為了最佳化 Maps Booking API 的整合作業，請進行下列步驟：

  • 一律使用 UNIX 時間戳記 (世界標準時間)。
  • 呼叫 CreateBooking 中的新預訂時，系統會產生專屬預訂 ID。

即時更新

為確保在預訂過程中享有最佳使用者體驗，請執行下列操作：

  • 如果是標準導入作業，請使用 BookingNotifications API 更改預約的開始時間、時間長度和預訂狀態，例如取消或未預約。
  • 來自「透過 Google 預訂」的預訂變更時，請一律使用包含 BookingNotification API 的系統即時傳送預訂更新資料，這樣您的資料就不會在「透過 Google 預訂」端過時。舉例來說，您可以透過「透過 Google 預訂」系統取消、重新排程或更新預訂。
  • 每次 UpdateBookingRequest 的預訂更新時，請確認 UpdateBookingResponse 值包含預訂 ID，且「所有」更新的欄位都必須反映新的值。
  • 如果已導入 Inventory RTU
    • 每個 API 呼叫僅可更新 100 至 1000 個運算單元的可用性。
    • 使用 *Restrict (例如 startTimeRestrict) 欄位可縮小編輯目標、縮減酬載大小，並避免重新傳送過多未變更的資料。
    • 如果您去除多個執行緒，請導入指數輪詢，以避免節流錯誤。如果您未正確實作指數輪詢，可能會收到 RESOURCE_EXHAUSTED 配額錯誤。您可以重試指數輪詢來處理這些要求，但如果在執行 ReplaceServiceAvailability 時，如果伺服器經常達到配額上限，請將伺服器設定為批次取代可用性。這項解決方案可避免配額錯誤，因為這樣可以減少服務必須執行的 API 呼叫次數。
  • 將 API 呼叫回應時間限制設定為不到一秒。請確認您的伺服器每秒可處理五次查詢 (QPS)，且延遲時間不到一秒。至少 95% 的時間。