新手上路流程

本文將說明如何為帳戶啟用並整合選單 API。以下將詳細說明新手上路程序和啟動前置條件。規劃整合作業時，請參照本頁面。

圖 1： 新手上路流程

新手上路流程包含三個階段：

1. 設定：帳戶設定和開發程序的規劃。
2. 開發：資料動態饋給開發和測試。
3. 發布：發布前評估資料。

設定

在此階段，請務必確認您在合作夥伴入口網站中的帳戶已完成設定，並且可以接受靜態選單資料的相關資料動態饋給。如果您有現有的有效 OwG Redirect 或 RwG 整合，且要為其新增選單中繼資料，系統會重複使用您現有的帳戶進行整合。如果這個平台已整合 OwG Direct，或是完全沒有整合，系統會建立新帳戶，並透過電子郵件分享存取詳細資料。

在合作夥伴入口網站中存取帳戶，然後前往「動態饋給」設定頁面：「設定」>「動態饋給」。有兩個 SFTP 伺服器與菜單資料動態饋給整合相關：一般和商家。請確認兩部安全檔案傳輸通訊協定伺服器都已設定 SSH 公開金鑰。如要進一步瞭解如何設定 SSH 金鑰，請參閱這個頁面。

注意：如果帳戶有有效的 OwG 重新導向或 RwG 整合，實體動態饋給或 Merchants 應已完全導入該整合。請確認菜單動態饋給中的所有餐廳都列在實體動態饋給或商家動態饋給中。

通用 SFTP 伺服器可接受各種可遵循不同資料結構的動態饋給。接受結構化選單資料的動態饋給類型名稱為 google.food_menu，通常會在你開始新手上路時，預設為帳戶啟用。如果嘗試提交動態饋給時看到以下錯誤訊息：「動態饋給處理失敗。我們在剖析動態饋給時遇到內部問題。未啟用「google.food_menu」 請修正並再試一次。」，請與 Google 聯絡窗口聯絡，啟用這類動態饋給。

最後，請前往「設定」>「聯絡資訊」頁面，確認所有聯絡詳細資料都已更新。

開發

開發階段包含實作工作的重點部分，也就是產生及測試資料動態饋給。您必須每天建立資料動態饋給，並提交至目標安全檔案傳輸通訊協定伺服器。提交後，系統預計會在一小時內開始處理動態饋給。產生動態饋給時，請參閱資料動態饋給規格和範例。雖然規範採用 protobuf 格式呈現，但我們建議以 JSON 格式上傳動態饋給檔案，因為這樣比較容易排解問題。因此，動態饋給樣本也會以 JSON 格式提供。

您可以使用動態饋給驗證工具線上工具，快速測試單一資料動態饋給檔案，驗證該檔案是否符合規格。這項工具會顯示檔案是否符合資料結構定義，如果不符合，則會輸出錯誤清單。如要測試包含多個檔案的完整資料動態饋給，請在沙箱環境中上傳該動態饋給，並在擷取完成後前往合作夥伴入口網站查看結果。在動態饋給擷取期間，系統會套用其他驗證規則，以測試部分業務邏輯和資料品質。

圖 2： 動態饋給攝入結果

注意：google.food_menu 動態饋給會依賴商家或實體動態饋給，才能將菜單與正確的餐廳建立關聯。實體或商家必須與 Google 上的地點正確比對。詳情請參閱「商家比對和測試」和「比對規範」相關文章。

啟動

所有整合工作完成後，您就可以啟動發布階段，正式版動態饋給會正確反映餐廳菜單的完整商品目錄。

啟動必要條件

如要啟動整合，必須符合下列條件：

• 資料動態饋給會在實際工作環境中處理，且沒有任何錯誤。
• 實際資料動態饋給包含在整合開始時，為此整合作業設定的完整商品目錄範圍。
• 您大部分的商家資料都與 Google 地圖上的地點比對相符。
• 正式版動態饋給通過資料品質評估。
• 這項整合作業符合所有餐飲菜單政策和規定。

資料評估

在正式版資料動態饋給擷取完成且沒有錯誤後，系統可能會進行內部程序，評估選單資料的品質。這個程序旨在找出資料品質上的不一致之處，例如菜色說明中含有非食物相關的內容、菜名或價格不符等。如果發現這類問題，我們會將意見回饋提供給開發團隊。