預訂商品整合政策
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
以下整合政策適用於預訂服務商品整合。
優惠政策
到達網頁 (行動網頁和應用程式)
- 所有餐廳向 Google 提供的優惠,都應至少在行動版到達網頁中顯示,並附上所有相關資訊。
- 到達網頁必須直接顯示商品價值和說明文字。
- 到達網頁必須清楚且完整地列出每項優惠的資格條件。包括使用者區隔、付款方式、特定日期或時間、最低消費金額,以及優惠可用次數的限制。
- 所有其他優惠限制 (例如資格條件、兌換操作說明、條款等) 必須顯示在到達網頁上,或在到達網頁中點選 1 次即可存取 (例如彈出式對話方塊)。
- 對於
OFFER_MODE_WALK_IN
優惠以外的所有優惠,與優惠相關聯的動作流程 (例如預訂餐桌) 必須允許使用者選取與其選項相關的適用優惠 (例如 針對預訂,適用於所選時段和人數的優惠)
- 您必須清楚說明兌換說明和方法,並提供可行的操作方式 (例如,如果兌換優惠需要在結帳時透過合作夥伴系統支付帳單,您應說明如何在系統中付款,且使用者應可在結帳時透過合作夥伴系統支付帳單)。
- 當優惠網址重新導向至合作夥伴安裝的行動應用程式時,應用程式的到達網頁必須符合本節所述優惠到達網頁的所有規定。
- 使用者在 Google 服務中與優惠互動後,如果立即返回 (例如使用返回按鈕、手勢導覽),則必須返回原始的 Google 服務。
優惠資料和格式
- 合作夥伴必須遵守相關文件中所述的技術規定和資料格式。如未符合這些規定,可能會導致動態饋給處理作業發生錯誤或延遲。
- 優惠必須全面開放給所有使用者。優惠可能需要付費訂閱,但訂閱者不限於特定對象。
- 提供的所有中繼資料必須正確且在動態饋給上傳時保持最新狀態 (至少每天上傳一次)。列出的優惠必須是有效的,並且可立即或提前提供給使用者 (如
ValidityPeriod
所示);過期、售完或已過期的優惠必須從動態饋給中移除。
- 合作夥伴必須在各平台上使用一致的商品格式。動態饋給中的優惠詳細資料,不得與合作夥伴的應用程式或網站上顯示的資料不符。
- 合作夥伴必須在
offer_display_text
欄位中提供清楚簡潔的優惠詳情,如實反映優惠的價值和任何限制。
- 合作夥伴必須明確指出每項商品的商品類別 (基本商品或加購商品) 和適用的商品模式 (
OFFER_MODE_FREE_RESERVATION
、OFFER_MODE_PAID_RESERVATION
、OFFER_MODE_WALK_IN
)。
- 合作夥伴必須確保每項商品的付款方式類型正確對應。
- 合作夥伴必須至少每天自動提供更新,或依開發人員說明文件所述提供更新。資料更新頻率必須足以達到 95% 的準確度。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-05-26 (世界標準時間)。
[null,null,["上次更新時間:2025-05-26 (世界標準時間)。"],[],[],null,["# Reservations Offers Integration Policies\n\nThe following integration policies apply to the Reservations Offers integration.\n\nOffers policy\n-------------\n\n### Landing Page (mobile page \\& application)\n\n- All Offers shared with Google for any restaurant should be visible with all relevant information on at least the mobile landing page.\n - The offer value and description text must be visible on the landing page directly.\n - Landing pages must clearly and comprehensively outline the eligibility requirements for each offer. This includes restrictions related to user segments, payment methods, specific days or times, minimum spending amounts, and the number of times the offer can be used.\n - All other offer restrictions (ex: conditions of eligibility, redeeming instruction, terms ...) must be visible on the landing page or accessible within 1 click of the landing page (ex: pop-up dialog).\n- For all offers except `OFFER_MODE_WALK_IN` offers, the action flow associated with the offer (ex. reserving a table) must allow the user to select the offer(s) applicable associated with their selection (ex. For reservation, offers applicable for the time slot and party size selected)\n- The redeeming instructions and methods must be clearly stated and actionable (ex: if redeeming the offer requires paying the bill on the partner system at checkout, the instruction to pay on the system should be mentioned and the user should be able to pay the bill on the partner system at checkout).\n- When an offer URL redirects to a partner's installed mobile application, the application's landing page must meet all requirements outlined in this section for offer landing pages.\n - Upon navigating back (e.g., using the back button, gesture navigation) immediately after interacting with an offer on a Google experience, users must be returned to the originating Google experience.\n\n### Offers Data \\& Format\n\n- Partners must adhere to the specified technical requirements and data formats outlined in the relevant documentation. Failure to meet these requirements can result in feed processing errors or delays.\n- The offer must be generally available to any user. Offers may require a paid subscription, as long as anyone can subscribe.\n- All metadata provided must be accurate and up-to-date at the time of feed upload (must be uploaded at least on a daily basis). Offers listed must be active and available to users either immediately or in advance as indicated using in the `ValidityPeriod`; outdated, sold out or expired offers must be removed from the feed.\n- Partners must use consistent offer formats across platforms. Discrepancies between the offer details in the feed and those displayed on the partner's app or website are prohibited.\n- Partners must provide clear and concise offer details in the `offer_display_text` field, accurately reflecting the offer's value and any limitations.\n- Partners must clearly indicate the offer category (Base Offer or Add-On Offer) and applicable offer modes (`OFFER_MODE_FREE_RESERVATION`, `OFFER_MODE_PAID_RESERVATION`, `OFFER_MODE_WALK_IN`) for each offer.\n- Partners must ensure accurate mapping of payment instrument types for each offer.\n- Partner must provide updates automatically at least once a day or as per the [developer documentation](/actions-center/verticals/reservations/offers/integration-steps/overview). Data update frequency must be sufficient to meet 95% accuracy."]]