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

Reservations のエンドツーエンドの統合ポリシー

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

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

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

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

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

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

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

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

ランディングページ

レストランについて Google と共有したすべての特典は、関連するすべての情報とともにランディングページに表示する必要があります。
- オファーの値と説明テキストは、ランディングページに直接表示する必要があります。
- 最小請求額、最大割引額、必須の定期購入に関連する特典の制限は、ランディングページに直接表示する必要があります。
- その他のすべての特典の制限（利用条件、利用手順、利用規約など）は、ランディングページに表示するか、ランディングページから 1 クリック以内でアクセスできるようにする必要があります（ポップアップダイアログなど）。
OFFER_MODE_WALK_IN 特典を除くすべての特典について、特典に関連付けられたアクションフロー（例: テーブルの予約）で、ユーザーが選択内容に関連する特典（例: 予約の場合、選択した時間帯と人数に適用される特典）
利用手順と方法を明記し、実行可能にする必要があります（例: 特典の利用に、購入手続き時にパートナーシステムで請求額の支払いが必要となる場合は、システムで支払う手順を記載し、ユーザーが購入手続き時にパートナーシステムで請求額を支払えるようにする必要があります）。
オファーの URL がパートナーアプリ（インストールされている場合）にリダイレクトされる可能性がある場合は、モバイルアプリのページにも上記と同じ要件が適用されます。

特典

この特典は、すべてのユーザーが利用できるものである必要があります。誰でも定期購入できる場合は、有料の定期購入が必要になる場合があります。
指定するメタデータはすべて、フィードのアップロード時に正確かつ最新のものでなければなりません。
- 在庫切れの商品は、フィードアップロード時にフィードに含めてはなりません。

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

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

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

ポリシーと要件

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

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

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

全般

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

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

^{1. すべての対面サービス（前払いやデポジットなど、この統合によって提供されるものは含まない）}

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

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