予約商品の統合に関するポリシー
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
予約オファーの統合には、次の統合ポリシーが適用されます。
クーポンに関するポリシー
ランディング ページ(モバイル ページとアプリ)
- レストランの Google と共有するすべての特典は、少なくともモバイル ランディング ページに、関連するすべての情報とともに表示する必要があります。
- オファーの値と説明テキストは、ランディング ページに直接表示する必要があります。
- ランディング ページには、各特典の利用資格要件を明確かつ包括的に記載する必要があります。これには、ユーザー セグメント、支払い方法、特定の日時、最低購入金額、特典の利用回数に関する制限が含まれます。
- その他のすべての特典の制限(利用条件、利用手順、利用規約など)は、ランディング ページに表示するか、ランディング ページから 1 クリック以内でアクセスできるようにする必要があります(ポップアップ ダイアログなど)。
OFFER_MODE_WALK_IN
特典を除くすべての特典について、特典に関連付けられたアクション フロー(例: テーブルの予約)で、ユーザーが選択内容に関連する特典(例: 予約の場合、選択した時間帯と人数に適用される特典)
- 利用手順と方法を明記し、実行可能にする必要があります(例: 特典の利用に、購入手続き時にパートナー システムで請求額の支払いが必要となる場合は、システムで支払う手順を記載し、ユーザーが購入手続き時にパートナー システムで請求額を支払えるようにする必要があります)。
- 特典の URL がパートナーのインストール済みモバイルアプリにリダイレクトされる場合、アプリのランディング ページは、このセクションで説明する特典のランディング ページの要件をすべて満たしている必要があります。
- Google エクスペリエンスでオファーを操作した直後に、ユーザーが「戻る」ボタンやジェスチャー ナビゲーションを使用して戻ると、元の Google エクスペリエンスに戻る必要があります。
オファーのデータと形式
- パートナーは、関連ドキュメントに記載されている技術的要件とデータ形式に準拠する必要があります。これらの要件を満たしていないと、フィード処理でエラーが発生したり、処理が遅れたりする可能性があります。
- 特典はすべてのユーザーが利用できるものでなければなりません。誰でも定期購入できる場合は、有料の定期購入が必要になる場合があります。
- 提供されるメタデータはすべて、フィード アップロード時に正確で最新の状態である必要があります(少なくとも 1 日に 1 回アップロードする必要があります)。リストに表示される特典は、有効で、
ValidityPeriod
を使用して示されているように、直ちにまたは事前にユーザーが利用できるものでなければなりません。古い特典、完売した特典、有効期限切れの特典はフィードから削除する必要があります。
- パートナーは、プラットフォーム間で一貫したオファー形式を使用する必要があります。フィード内の特典の詳細と、パートナーのアプリまたはウェブサイトに表示される特典の詳細が一致していない場合、そのフィードは使用できません。
- パートナーは、
offer_display_text
フィールドに特典の詳細を明確かつ簡潔に記述し、特典の価値と制限事項を正確に反映する必要があります。
- パートナーは、オファーごとにオファーのカテゴリ(基本オファーまたはアドオン オファー)と適用されるオファー モード(
OFFER_MODE_FREE_RESERVATION
、OFFER_MODE_PAID_RESERVATION
、OFFER_MODE_WALK_IN
)を明記する必要があります。
- パートナーは、商品ごとにお支払い方法の種類を正確にマッピングする必要があります。
- パートナーは、少なくとも 1 日に 1 回、またはデベロッパー向けドキュメントに従って自動的に更新を提供する必要があります。データ更新の頻度は、95% の精度を満たす必要があります。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-05-26 UTC。
[null,null,["最終更新日 2025-05-26 UTC。"],[],[],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."]]