このページは Cloud Translation API によって翻訳されました。

予約のエンドツーエンド統合に関するポリシー

次の統合ポリシーは、Reservations のエンドツーエンド統合に適用されます。

エンドツーエンドのポリシー

統合を開始する前に、以下にある統合の資格条件をお読みください。パートナーが Actions Center の予約のエンドツーエンドの統合と統合を行うには、以下の要件とポリシーを満たしている必要があります。

以下の要件は Actions Center プログラムに参加するために必須となる要素ですが、要件を満たしていても、Actions Center との統合またはその運用開始を行うためのパートナーの利用資格を保証するものではありません。

要件とポリシーを満たしていない場合、統合、販売者、サービスがプラットフォームから停止または削除される可能性があります。

プラットフォームの一般的な要件

パートナーは、個人を特定できる情報を含むすべての販売者とユーザーのデータを、一般データ保護規則（GDPR）やその他の該当するプライバシー法に準拠する方法で収集、処理する必要があります。
パートナーは、販売者に代わって予約を行うことを許可されている必要があります。
パートナーは、販売者の空き状況スロットやタイムスロットにリアルタイムで直接アクセスできる必要があります（すなわち、パートナーは Google からの空き状況リクエストに 1 秒以内に応答できる必要があります）。
- 特殊なケース: 販売者からの非同期の確認を必要とする予約はサポートされますが、予約フローは利用可能なタイムスロットに基づいている必要があります。パートナーは、予約を確定するために販売者からの確認が必要な場合でも、販売者のオンラインシステムなどを通じて、リアルタイムで対応できる必要があります。
パートナーは販売者の包括的な在庫を所有している必要があります。販売者の在庫が一部しかない場合や不足している場合は対象外となります。
パートナーは 30 日間以上の販売者の空き状況を確保している必要があります。
パートナーは、予約のオンラインキャンセルをサポートしている必要があります。
前払いを必要とするパートナーは、アクションセンターのお支払いポリシーに準拠する必要があり、その決済代行業者は以下のサポート対象リストに含まれていて、トークン化されたお支払いに対応している必要があります。
パートナーは、サービス費用について正確な料金データを提供できる必要があります。また、Actions Center の料金に関するポリシーに準拠する必要があります。
パートナーは、Actions Center の技術的な予約のエンドツーエンドの統合の要件を満たす必要があります。
パートナーは、Actions Center の販売者とサービスの利用資格要件に準拠する必要があります。
パートナーは、Actions Center のサポートとメンテナンスのガイドラインに準拠する必要があります。
パートナーは、リリースとモニタリングのガイドラインで定義されている許容可能なエラー率を維持する必要があります。
非同期統合で行われた予約を除き、すべての予約はリアルタイムで自動的に確認する必要があります。非同期統合を介して行われた予約は、非同期ガイドラインに準拠している必要があります。
パートナーは、Actions Center の業種または機能固有のポリシー（商品、お支払い、オンラインサービス、レストラン）に準拠する必要があります。
パートナーは、ガイドラインに沿って、販売者名、住所、サービス名、説明の標準品質のコンテンツを維持する必要があります。

translation: human page_type: lcat

クーポンに関するポリシー

ランディングページ（モバイルページとアプリ）

レストランの 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）を明記する必要があります。
パートナーは、商品ごとに支払い方法の種類を正確にマッピングする必要があります。

フードメニューのポリシーと要件

統合を開始する前に、以下にある統合の資格条件をお読みください。統合の対象となるには、パートナーは食品メニューポリシーに準拠し、次の要件を満たしている必要があります。Google は、ユーザーにとって有益な方法でメニューと料理のデータが表示されるようにする権利を有します。

要件とポリシーを満たしていない場合、統合、販売者、サービスがプラットフォームから停止または削除される可能性があります。

ポリシーと要件

パートナーは、冒とく的な表現、禁止されている画像、個人を特定できる情報（PII）、ユーザー作成コンテンツなど、メニューフィードに禁止されている情報（詳細を参照）を送信してはなりません。
パートナーは、メニューフィードを使用して、サービス（例: 店頭受け取り、プロモーションコードなど）などのメニュー以外のアイテムを共有しないでください。
パートナーは、予約 E2E メニュー仕様または注文リダイレクトメニュー仕様に記載されているすべての必須データを提供する必要があります（最大ファイルサイズ 2 MB）。技術的な要件は、予約 E2E メニュー仕様または注文リダイレクトメニュー仕様で、フィールドを省略可/必須としてマークすることで対応しています。
パートナーは、対応するレストランの店舗で利用可能なメニュー項目のみを提供する必要があります。
パートナーは、店舗ごとに完全なメニューを送信する必要があります。メニューが不完全な販売者は、表示の対象外となる場合があります。
パートナーと販売者は、メニューが正確であることを確認して、毎日更新する必要があります。
メニューアイテムの写真は、明るく、フォーカスが合った 1 つのメニューアイテムが写っている必要があります。人物や食べ物以外の画像は含めず、画像仕様に準拠している必要があります（写真のガイドラインをご覧ください）。
価格は、現地の法律や条例で義務付けられている場合を除き、メニューアイテムごとに、チップ、税金、手数料を含めずに表示する必要があります。パートナーは、現地通貨を明示的に指定する必要があります。
特別メニューはサポートされており、提供が終了した場合は削除する必要があります（例: コース料理、季節限定、期間限定スペシャル）。

お支払いリダイレクトに関するポリシー

このセクションでは、Actions Center で支払いリダイレクトを実装するための一般的なポリシーと機能固有のポリシーについて説明します。Actions Center を使用するユーザー、販売者、パートナーに一貫したエクスペリエンスを提供するため、支払いを必要とする在庫は適切なガイドラインに準拠している必要があります。これらのポリシーに準拠していない場合は、統合が停止されます。

全般

以下のポリシーは、「Google で予約」上のすべての支払いと在庫に適用されます。

ユーザーへの請求金額は、適用される法律に準拠し、取引条件で指定された金額と同じである必要があります。
パートナーは、リアルタイム更新（RTU）を使用して空き状況を更新するか、BatchAvailabilityLookup 呼び出しに正確なスロット空き状況を反映させる責任があります。
クレジットカード必須の取引については、ユーザーに請求することはできません。
Google の支払い設定プロセスに明記されているとおり、ユーザーに対して、精算時に明示的に合意されていない請求は行わないでください。
- リンクされた利用規約ページ内に含まれる支払い条件は、この要件を満たしていません。
対面型サービス¹の場合は、すべての支払いを予約時または対面で行う必要があります。その他の方法による支払いの勧誘は固く禁じられています。
取引は、販売者の所在地の通貨で表示および請求する必要があります（通貨は支払い設定プロセスで指定します）。通貨換算が行われない場合があります。

^{1. すべての対面サービス（前払いやデポジットなど、この統合を通じて提供されるサービスは除く）}

ランディングページの要件

ランディングページは、予約フローの開始点であり、参加人数と時間帯が事前に選択されている必要があります。
ランディングページは、プラットフォームプロバイダのホームページやその他のページにすることはできません。
ディープリンクのランディングページの最初のステップは、支払い情報の提供がない限り、ユーザーが予約の関連メタデータを表示できない支払いウォールであってはなりません。
ディープリンクが設定されたランディングページの最初のステップは、ログインページにすることはできません。予約フローに、ユーザーがログインしたりアカウントを作成したりしなくても予約を完了できるゲスト購入オプションを含める必要があります。
リンクアウトとランディングページで、ユーザーが予約フローを完了するためにアプリをダウンロードすることを要求することはできません。

予約のエンドツーエンド統合に関するポリシー コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。