料金配信モード

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

配信モードの概要

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

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

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

  • ARI（Push）: 料金プラン、空室状況、ホテルのメタデータを使用して、宿泊施設に対して事前定義された料金戦略を設定する料金配信フィード。プル型料金や変更済み料金とは異なり、ARI フィードは特定の料金や旅行プランをクエリしません。代わりに、さまざまな料金の詳細、制限、空室状況に基づいて、宿泊施設の料金モデルを表す情報のサブセットを含むメッセージをプッシュします。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: ARI プッシュ メッセージを Google に送信する

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

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

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

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

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

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

ARI プッシュによる客室とパッケージのメタデータの更新

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

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

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

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

pull 配信モード

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: トランザクション メッセージ

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

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

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

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

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

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

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

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

fig3

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

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

Google からお客様のサーバーに送信される Hint Request メッセージには、次のような特徴があります。

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

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

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

ステップ 2: ヒント レスポンス メッセージ

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

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

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

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

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

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

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