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

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

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

事前に次の統合資格要件をお読みください。 統合を開始できますパートナー様は次の要件を満たし、 統合するためのポリシーも作成する必要があります。 Reservations のエンドツーエンドの統合

以下の要件はアクション センター プログラムの資格要件を満たすための必須要素ですが、要件を満たしてもパートナーがアクション センターの統合または稼働開始の資格を保証するものではありません。

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

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

  1. パートナーは、個人を特定できる情報を含むすべての販売者とユーザーのデータを、一般データ保護規則(GDPR)やその他の該当するプライバシー法に準拠する方法で収集、処理する必要があります。
  2. パートナーは、販売者に代わって予約を行うことを許可されている必要があります。
  3. パートナーは、販売者の空き状況スロットやタイムスロットにリアルタイムで直接アクセスできる必要があります(すなわち、パートナーは Google からの空き状況リクエストに 1 秒以内に応答できる必要があります)。

    • 特殊なケース: 販売者からの非同期確認が必要な予約はサポートされていますが、予約フローは予約可能な時間帯に基づいて実行する必要があります。パートナーは、予約を確定するために販売者からの確認が必要な場合でも、販売者のオンライン システムなどを通じて、リアルタイムで対応できる必要があります。
  4. パートナーは販売者の包括的な在庫を所有している必要があります。販売者の在庫が一部しかない場合や不足している場合は対象外となります。

  5. パートナーは 30 日間以上の販売者の空き状況を確保している必要があります。

  6. パートナーは、予約のオンライン キャンセルをサポートしている必要があります。

  7. 前払いを必要とするパートナーは、アクション センターの支払いポリシーを遵守する必要があります。また、その決済代行業者が以下のサポート対象リストに記載されており、トークン化された支払いに対応している必要があります。

  8. パートナーは、サービス料金の正確な料金データを提供し、アクション センターの料金ポリシーを遵守する必要があります。

  9. パートナー様は、アクション センターの技術要件を満たす Reservations のエンドツーエンドのインテグレーション 提供します。

  10. パートナーは、アクション センターの販売者とサービスの資格要件に従う必要があります。

  11. パートナーは、アクション センターのサポートとメンテナンスのガイドラインに準拠する必要があります。

  12. パートナー様は、 リリースとモニタリングのガイドライン

  13. 非同期統合で行われた予約を除き、すべての予約はリアルタイムで自動的に確認される必要があります。非同期統合を通じて行われる予約は、 非同期ガイドライン

  14. パートナーは、アクション センターのカテゴリまたは機能に固有のポリシー(特典支払いオンライン サービスレストラン)に準拠する必要があります。

  15. パートナー様は、販売者名、住所、サービス名、説明について、ガイドラインに沿って標準品質のコンテンツを維持する必要があります。

特典に関するポリシー

純広告のエンドツーエンド統合に特典を含めるには、特典が要件を満たしている必要があります。 技術要件を遵守する必要があります

クーポンの利用条件

  • クーポンはすべてのユーザーに一般提供する必要があります。
  • メンバーシップ プログラムやメーリング リストに登録したり、特定のクレジット カードを使用したりしなくても、ユーザーがクーポンを利用できるようにする必要があります。
  • クーポンは、特定の年齢層(学生割引や高齢者割引)に限定することはできません。
  • クーポンは、利用可能かどうかが予測できない形で提供することはできません。たとえば、クーポンは午後 3 時から午後 4 時の時間限定で有効にすることはできますが、先着 10 名に限定することはできません。
  • クーポンは販売者が提供し、遵守する必要があります。

技術要件や利用条件を満たしていないクーポン

特典が資格要件を満たしていない場合は、含めないでください。 使用することもできます。

特典が技術要件を満たさない場合や Google のデータ仕様に適合しない場合は、 は、現時点では予約のエンドツーエンド統合から除外する必要があります。Google の担当者にご連絡いただき、実装をご希望の機能や変更についてお知らせください。お問い合わせの際は、クーポンの数と対象となる販売者の数、クーポンのサンプルをお知らせください。

フードメニューに関するポリシーと要件

統合を開始する前に、以下の統合資格要件をお読みください 統合できますパートナー様は、フードメニューに関するポリシーに準拠し、 統合するには次の要件を満たす必要があります。なお、Google は、メニューやユーザーの役に立つ方法で 料理データを提供することです

要件やポリシーを遵守していないと、統合、販売者による統合、 プラットフォーム上で一時停止または削除されることもあります。

ポリシーと要件

  1. パートナー様は、禁止されている情報を送信してはなりません(詳細をご覧ください)。 下品な言葉、禁止されている画像、個人を特定できる情報などのメニュー フィードに表示されること ユーザー生成コンテンツです。
  2. パートナー様は、メニュー フィードを使用してサービスなどのメニュー以外の項目を共有しないでください (例: 店先受取可、プロモーション コードなど)。
  3. パートナー様は、必要なすべてのデータを予約の E2E メニュー仕様または注文リダイレクト メニューの仕様に記載する必要があります。 (最大ファイルサイズ 2 MB)。技術的要件については、Reservations E2E メニュー仕様またはOrdering Redirect メニュー仕様をご覧ください。 フィールドを省略可/必須に設定します。
  4. パートナー様は対応するレストランで利用可能なメニューのみを提供する必要があります 提供します
  5. パートナー様は、場所ごとに完全なメニューを送信する必要があります。未完了の販売者 メニューが表示されない場合があります。
  6. パートナーと販売者は、メニューが正確であることを確認する義務があります。 更新を提供します。
  7. メニュー項目の写真は明るく、フォーカスのあるメニュー項目が 1 つになるようにしてください。 人物などの食品以外の画像を含めます。また、画像の仕様に準拠する必要があります(写真に関するガイドラインをご覧ください)。
  8. 価格は、チップ、税金、手数料を含めず、メニュー項目ごとに表示する必要があります。ただし、 法令により義務付けられている場合があります。パートナー様は現地通貨を明示的に指定する必要があります。
  9. 特製メニューはサポートされているため、ご利用いただけなくなったら削除する必要があります (例: プライス フィックス、季節限定のスペシャル、期間限定のスペシャル)。

支払いリダイレクト ポリシー

このセクションでは、アプリの一般的なポリシーと機能固有のポリシー Actions Center での支払いリダイレクトの実装。一貫した アクション センターを使用して、消費者、販売者、パートナーの エクスペリエンスを向上できます 支払いを必要とする在庫は、該当するガイドラインに準拠している必要があります。失敗 ポリシーに違反すると、統合が停止されます。

全般

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

  1. ユーザーに請求される金額が、利用規約で指定されている金額と一致していること 適用法を遵守します。
  2. 事前支払い、無断キャンセル料、デポジットが必要なサービスについては、 cancellation_policy 定義は必須です。
  3. パートナー様は、リアルタイム更新を使用して空き状況を更新する責任を負います (RTU)、または BatchAvailabilityLookup 呼び出しが正確なスロットを反映していることを確認する 可用性。
  4. 必要なクレジット カードについてユーザーに請求が行われることはありません。 あります。
  5. 明示的に同意されていないユーザーには、料金を請求しないでください。 購入手続きで使用します。
    • リンク先の利用規約ページ内に記載されている支払い条件が、この要件を満たしていません。
  6. 対面サービス1の場合、支払いはすべて予約時または予約時に行う必要があります。 対面式でのみ利用します。その他の方法による支払いの募集は、 禁止します。
  7. 取引は、その地域の通貨で表示され、請求される必要があります (通貨はお支払い設定 プロセス)。通貨の換算は行われません。

1. すべての対面サービス(このサービスを通じて提供されるものは含まない) 前払いやデポジットなどの統合機能

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

  1. ランディング ページは、人数が記載された予約フローの最初に配置する必要があります 時間枠があらかじめ選択されています
  2. ランディング ページは、プラットフォーム プロバイダのホームページなどであってはなりません できます。
  3. ディープリンクが設定されたランディング ページの最初のステップとして、ログイン ウォールを使用することはできません。 ユーザーはログインするかスペースを作成しないと、予約を続行できません あります。
  4. ディープリンクが設定されたランディング ページの最初のステップを「ペイウォール」にすることはできません。 ユーザーが提供しない限り、ユーザーは予約の関連メタデータを表示できません。 お支払いの詳細が表示されます。