概要と利用条件

以下では、Actions Center の予約の包括的な統合プロセスについて詳しく説明します。

統合

エンドツーエンドの統合ガイドに記載されている標準の統合プロセスの概要に従います。

エンドツーエンドの予約機能の統合に関するオンボーディングの概要。
エンドツーエンドの予約機能の統合に関するオンボーディングの概要。

エンドツーエンドの予約に関する主なガイダンス

以下の概要は、予約のエンドツーエンド統合に必要な主な機能の例とチュートリアルです。

  • フィード:
    • 予約のエンドツーエンドの統合では、販売者、サービス、空き状況のフィードを毎日 SFTP 経由で送信する必要があります。
    • 販売者フィード内 - 各店舗の名前、住所、電話番号、URL が Google のリスティングとほぼ一致している必要があります。
    • エンドツーエンドの予約システムを使用している販売者が空き状況の表示に使用できるサービスは 1 つのみです。
    • 予約が販売者が提供する唯一のサービスである場合は、すべての販売者の service_id に同じ静的値を設定することをおすすめします。必要に応じて、サービス フィードで schedule_rules と cancellation_policy を指定します。
    • 予約のエンドツーエンド在庫の主な違いは、すべての空き情報で party_size を定義する必要がある点です。詳しくは、次のガイドをご覧ください。
  • 予約サーバー:
    • 予約サーバーは、Google サーフェス経由で行われた予約の空き状況の確認、作成、更新、削除、変更を行うための Google のエントリポイントとして機能します。
    • ユーザーに快適なエクスペリエンスを提供するため、これらのリクエストに対するレスポンスは、エラー率とレイテンシのしきい値内に収める必要があります。
    • リクエストとレスポンスの例については、以下のガイドをご覧ください。
  • リアルタイム更新:
    • リアルタイム更新は必須ではありませんが、ユーザーが空き状況にアクセスする前に、予約のキャンセルや空き状況の変更に関する最新情報を非同期で Google に送信できます。これにより、BatchAvailabilityLookup が失敗した場合に、ユーザーに表示される予約不可の時間が全体的に減ります。詳しくは、リアルタイム更新の構造化に関するドキュメントをご覧ください。
  • その他の注意:
    • 空き情報フィード ファイル（圧縮後）のサイズが 200 MB を超える場合は、 シャーディング を行って、200 MB 未満（圧縮後）のファイルに分割する必要があります。
    • エンドツーエンドの予約機能の販売者が利用できるサービスは 1 つのみです

エンドツーエンドの予約機能の追加

予約のエンドツーエンドの統合を完了する際には、以下の機能をご検討ください。これらはいずれも必須ではありませんが、Actions Center で自社のビジネス ロジックに沿って在庫を配信するには、多くの機能が必要になります。