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

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

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

統合を開始する前に、次の統合の利用条件をお読みください。パートナーがアクション センターの予約のエンドツーエンド統合と統合するには、次の要件とポリシーを遵守する必要があります。

以下の要件はアクション センター プログラムの資格要件として必須ですが、パートナー様がこの要件を満たしても、アクション センターの統合または公開が保証されるわけではありません。

要件やポリシーに準拠していない場合、統合、販売者、サービスのプラットフォーム上での停止または削除が行われる可能性があります。

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

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

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

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

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

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

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

  9. パートナーは、Actions Center の Reservations のエンドツーエンド統合の技術要件を満たす必要があります。

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

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

  12. パートナーは、リリースとモニタリングのガイドラインで定義されている許容エラー率を維持する必要があります。

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

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

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

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

オファーが純広告のエンドツーエンド統合の一部になるには、利用条件と技術要件を満たしている必要があります。

クーポンの利用条件

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

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

オファーが資格要件を満たしていない場合は、Reservations のエンドツーエンド統合に含めることはできません。

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

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

統合を開始する前に、次の統合の利用条件をお読みください。パートナーが統合を利用するには、フードメニューに関するポリシーに準拠し、次の要件を満たす必要があります。Google は、メニューや料理のデータをユーザーの役に立つ方法で表示する権限を有します。

要件やポリシーに準拠していない場合、統合、販売者、サービスのプラットフォームへの掲載が停止されるなどの措置が講じられる可能性があります。

ポリシーと要件

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

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

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

全般

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

  1. 適用される法律に従って、ユーザーに請求される金額は、トランザクションの条件で指定されている金額と同じである必要があります。
  2. 前払い、無断キャンセル、保証金を必要とするサービスの場合、servicecancellation_policy の定義は必須です。
  3. パートナーは、リアルタイム更新(RTU)を使用して空き情報を更新するか、BatchAvailabilityLookup 呼び出しに正確なスロット空き情報を反映させる責任を負います。
  4. クレジット カードが必要な取引について、ユーザーに料金を請求しないでください。
  5. Google のお支払い設定プロセスに記載されているように、購入手続き時に明示的に同意していないユーザーに対しては請求しないでください。
  6. リンクされた利用規約ページ内に含まれる支払い条件は、この要件を満たしていません。
  7. 対面式サービス [^1]の場合、すべての支払いは予約時または対面でのみ行われます。その他の手段による支払いの要求は固く禁じられています。
  8. 取引は、販売者の所在地の通貨で表示し、請求する必要があります(通貨はお支払い構成プロセスで指定されます)。通貨の換算は行われません。

1. すべての対面サービス(この統合を通じて提供されるサービス(前払い、預金など)は含まれません)

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

  1. ランディング ページは、人数と時間枠があらかじめ選択された予約フローの開始ページである必要があります。
  2. プラットフォーム プロバイダのホームページやその他のページをランディング ページとして使用することはできません。
  3. ディープリンクされたランディング ページの最初のステップをログイン ウォールにすることはできません。ユーザーは、ログインするかアカウントを作成しない限り、予約を完了できません。
  4. ディープリンクされたランディング ページの最初のステップを「ペイウォール」にすることはできません。ユーザーは支払いの詳細を入力しない限り、予約の関連メタデータを表示できません。