料金配信モード

配信モードにより、ホテルと旅行プランの組み合わせの料金の更新情報を Google に送信する方法が決まります。初期設定時に、お客様とテクニカル アカウント マネージャー（TAM）が協力して配信モードを設定します。

配信モードの概要

デフォルトでは、空室状況の 330 日前から最大 30 泊までホテルをクエリできますが、旅行プランの最大数（チェックイン日と滞在日数の組み合わせ）を決定できます。

サポートする宿泊プランが多いほど、参加するオークションが増えます。ただし、サポートする旅行プランが多いほど、料金データの正確性を維持するために Google に送信するデータも多くなります。

料金を更新する一般的な方法では、次のいずれかの方法で Transaction メッセージを使用します。

  • ARI（プッシュ）: 料金プラン、空室状況、ホテル メタデータを使用して、宿泊施設に対して事前定義された料金戦略を設定する料金配信フィード。プル型料金や変更済み料金とは異なり、ARI フィードでは特定の料金や旅行プランはクエリされません。代わりに、さまざまな料金の詳細、制限、空室状況に基づく宿泊施設の料金モデルを表す情報のサブセットを含むメッセージを push します。ARI フィードは、OTA XML 仕様（OTA_HotelRateAmountNotifRQ と OTA_HotelAvailNotifRQ）を使用して在庫状況と価格を定義します。ARI 配信モードの詳細や、このフィードタイプがお客様のアカウントに適しているかどうかは、アカウント マネージャーにお問い合わせください。詳細については、ARI の使用をご覧ください。

  • pull: Google はお客様のサービスに定期的にクエリを実行し、料金と空室状況のデータのキャッシュを更新します。このモデルでは、Google がサーバーにリクエストを送信し、サーバーは更新されたデータで応答します。このモデルは、料金情報がいつ変更されるのか正確にわからない場合や、1 日のうちに料金情報が不定期に変化する場合に最適です。料金は、パートナー固有の以前の価格変更履歴に基づいて、Google のアルゴリズムが料金が古くなったと判断するまでキャッシュに残ります。詳細については、pull 配信モードの使用をご覧ください。

  • 変更済み料金（旧称: ヒントを使用したプル）: プルと似ていますが、Google はすべての宿泊施設ではなく、一部の宿泊施設のデータのみをリクエストします。このモードでは、宿泊施設の料金と空室状況を更新する際にネットワーク トラフィックの量を大幅に削減できます。料金は、更新されるまで無期限にキャッシュに残ります。詳細については、変更済み料金の使用をご覧ください。

料金の更新だけでなく、トランザクション メッセージを使用して在庫から宿泊施設を削除することもできます。詳しくは、インベントリの削除をご覧ください。

トランザクション メッセージの例など、料金設定の更新データの提供について詳しくは、料金の更新をご覧ください。

ライブ料金クエリ

また、Google はライブ料金クエリを使用して、オークション時に最新の料金情報をリクエストできます。ライブ料金クエリは、現在のオークションに対する Google からの料金設定リクエストです。指定された時間内に応答すると、広告はオークションにかけられます。

Google は、他のトランザクション メッセージと同様に、ライブ料金クエリへのレスポンスを保存します。その結果、Google は今後別のライブ料金クエリを送信しなくても、キャッシュから料金を提示できます。

詳しくは、ライブ料金クエリをご覧ください。

コンテキスト

通常、プル型料金クエリと変更済み料金クエリでは、ユーザーに関する情報は指定しません。これは、Google がレスポンスを使用してキャッシュを埋めるためです。このキャッシュは、さまざまなユーザーに対応するために使用される可能性があります。

可能性のあるユーザー コンテキストの完全なセットに対応する価格を返すとコストが高くなる可能性があるため、一般的なユーザー コンテキストをクエリの一部として指定して機能をテストしています。ユーザー コンテキストは、料金を表示する機会があったユーザー リクエストに基づいており、ユーザー リクエストの大部分に対応するように計算されます。非常に人気のあるプロパティや旅行プランでは多数のユーザー コンテキストが表示されることがありますが、ユーザー コンテキストの平均数は 10 未満に抑える必要があります。追加の料金を返すことも、指定したユーザー コンテキストを無視することもできます。特定のクエリに対して返す料金の決定は、任意です。ただし、提案されたユーザー コンテキストを無視すると、トラフィックが減少する可能性があります。

ARI プッシュ配信モード

ARI プッシュ配信モードでは、1 泊の料金、空室状況、在庫数、その他の制限が変更されるたびに、増分更新が Google に送信されます。プル型料金や変更済み料金とは異なり、ARI プッシュでは、別の料金モデルを使用して、料金情報のさまざまなコンポーネントを Google に効率的に更新できます。

次の図は、ARI プッシュ配信モードのリクエストとレスポンスのフローを示しています。

fig1

ステップ 1: Google に ARI プッシュ メッセージを送信する

ARI プッシュを使用してデータを更新するには、データが変更されるたびに ARI リクエスト メッセージを送信します。ARI プッシュ配信モードは、さまざまなメッセージ タイプと料金戦略をサポートしています。メッセージの push の詳細については、ARI の使用をご覧ください。

料金は Google によって配信され、メッセージの受信から 15 ～ 20 分以内にユーザーに表示されます。

ステップ 2: Google によってデータが正常にキャッシュに保存されていることを確認する

ARI プッシュ メッセージを受信するたびに、Google は HTTP 接続ステータスと ARI 処理結果を返します。サーバーへの接続が成功すると、Google は HTTP 200 OK を返します。また、更新が正常に適用されたか、配信モードの警告やエラーが発生したかどうかを示すレスポンス メッセージを含む本文も含まれています。

IP アドレスを許可リストに登録

ARI メッセージを Google にプッシュする際に使用する IP アドレスを許可リストに登録するには、Hotel Center ARI の料金設定ページを使用します。詳しくは、Hotel Center で料金設定を更新する方法をご覧ください。

ARI プッシュを使用して客室とパッケージのメタデータを更新する

Transaction（宿泊施設データ）メッセージ タイプを使用して、各宿泊施設の有効な客室タイプと料金プラン（パッケージ）を定義します。客室タイプや料金プランが追加、削除、変更されるたびに、更新をプッシュする必要があります。この場合、<RoomData> 要素と <PackageData> 要素に新しい情報を含む XML メッセージを送信します。これらの要素は <PropertyDataSet> 要素の子です。

接続エラーまたはコンテンツ エラー

XML の形式が正しくないため配信モードエラーが発生した場合は、フィード ステータスのエラー メッセージで推奨される解決策を確認してください。

Google に ARI メッセージを送信する際に HTTP 接続エラーが発生した場合は、1 分、5 分、20 分間隔でリクエストを再試行します。3 回再試行しても問題が解決しない場合は、メッセージの送信を中止し、Google サポートにお問い合わせください。

pull 配信モード

プル配信モードでは、Google は定期的にクエリ メッセージをお客様のサーバーに送信して料金の更新をリクエストします。サーバーは、更新された料金と空室状況のデータを含むトランザクション メッセージでこれらのメッセージに応答します。

次の図に、pull のリクエスト/レスポンスのフローを示します。

fig2

Google は通常、料金の更新の受信後、新しい料金と在庫状況のデータを約 5 分以内に処理します。

以降のセクションでは、これらの各ステップについて詳しく説明します。

ステップ 1: クエリ メッセージ

デフォルトでは、Google はホテルリストで定義されているすべての宿泊施設に対してクエリ メッセージを送信します。これは、料金変更プロセス中に複数の Query メッセージを受信する必要があることを意味しています。

Google からお客様のサーバーに送信する料金クエリ メッセージには、次の特徴があります。

  • ルート要素は <Query> です。
  • 初期設定時に定義されたエンドポイントに送信されます。詳細については、テクニカル アカウント マネージャー（TAM）にお問い合わせください。
  • HTTP POST メソッドを使用します。（HTTPS を使用している場合は、正式な認証局によって署名されたドメインを取得する必要があります）。
  • Content-Type ヘッダーが application/xml に設定されている。
  • 各メッセージには、Google が料金と空室状況のデータをリクエストする宿泊施設が最大 100 件含まれます。
  • User-Agent ヘッダーが Google-HotelAdsPrices に設定されている。

ステップ 2: トランザクション メッセージ

クエリ メッセージを受信したサーバーは、リクエストされた旅行プランの料金情報を含む Transaction メッセージで応答する必要があります。

トランザクション メッセージのルート要素は <Transaction> です。詳しくは、トランザクション メッセージと料金の更新をご覧ください。

客室とパッケージのメタデータを更新する

pull で料金データを更新するだけでなく、Transaction メッセージを使用して客室とパッケージのメタデータを更新することもできます。詳しくは、客室とパッケージのメタデータの定義をご覧ください。

料金の配信モードを変更しました

変更済み料金を使用すると、料金更新のためのクエリ メッセージとトランザクション メッセージのサイズと量を削減できます。変更済み料金を使用すると、料金が更新された宿泊施設のリストを Google に送信します。Google は、それらの宿泊施設の料金のみを要求する Query メッセージで応答します。

Google が Hint Request メッセージを送信するエンドポイントを構成するには、テクニカル アカウント マネージャー（TAM）にお問い合わせください。この設定は、初期設定時に行います。

次の図は、変更済み料金のリクエストとレスポンスのフローを示しています。

fig3

以降のセクションでは、このフローの各ステップについて説明します。

ステップ 1: Hint Request メッセージ

Google からお客様のサーバーに送信するヒント リクエスト メッセージには、次の特徴があります。

  • ルート要素は <HintRequest> です。
  • 最初の構成で定義したエンドポイントに送信されます。詳しくは、担当のテクニカル アカウント マネージャー（TAM）にお問い合わせください。
  • HTTP POST メソッドを使用します。（HTTPS を使用している場合は、正式な認証局によって署名されたドメインを取得する必要があります）。
  • Content-Type ヘッダーが application/xml に設定されている。
  • 指定された頻度で、お客様が最後に Hint Request メッセージに応答した時刻を定義するタイムスタンプを Google からサーバーに送信します。
  • User-Agent ヘッダーが Google-HotelAdsPrices に設定されている。

頻度は 5 分に設定することをおすすめします。Hint Request メッセージの頻度を設定または変更するには、Google にお問い合わせください。

Google からヒント リクエスト メッセージを受信したら、そのタイムスタンプ以降に更新されたすべての料金で応答します。詳しくは、Hint Request メッセージをご覧ください。

ステップ 2: Hint Response メッセージ

サーバーはヒント リクエスト メッセージに対してヒント応答メッセージで応答します。このメッセージには、前回ヒント リクエスト メッセージを受け取って応答した後に料金が変更された宿泊施設のホテル ID と旅行プランが含まれます。

ヒント応答メッセージのルート要素は <Hint> です。詳しくは、ヒント応答メッセージをご覧ください。

ステップ 3: クエリ メッセージ

標準の pull モードの場合と同様に、Google はヒント応答メッセージを受け取り、クエリ メッセージで応答します。違いは、クエリ メッセージには、Hint Response メッセージで指定した宿泊施設のホテル ID と旅行プランのみが含まれるようになったことです。クエリ メッセージのルート要素は <Query> です。

変更済み料金で料金をリクエストするホテル ID を決定する際、Google はホテルリスト フィードの内容を無視します。これにより、Google から受信するクエリ メッセージのサイズと、レスポンスのトランザクション メッセージのサイズが大幅に削減されます。

ステップ 4: トランザクション メッセージ

Google のクエリ メッセージへのレスポンスとして、料金の更新データを含む Transaction メッセージを送信します。トランザクション メッセージのルート要素は <Transaction> です。詳しくは、pull 配信モードをご覧ください。