料金配信モード

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

配信モードの概要

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

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

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

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

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

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

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

Transaction メッセージの例など、料金更新の提供について詳しくは、料金の更新をご覧ください。

ライブ料金クエリ

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

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

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

コンテキスト

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

可能性のあるユーザー コンテキスト全体に対応する価格を返すには費用がかかる可能性があるため、一般的なユーザー コンテキストがクエリの一部として指定されている機能をテストしています。ユーザー コンテキストは、料金を表示する機会があったユーザー リクエストに基づいており、大半のユーザー リクエストに対応できるよう計算されます。非常に人気のあるプロパティや旅行プランでは多数のユーザー コンテキストが表示されることがありますが、ユーザー コンテキストの平均数は 10 未満でなければなりません。追加の料金を返すことも、指定したユーザー コンテキストを無視することもできます。また、特定のクエリに対してどの料金を返すかはデベロッパーが決定します。ただし、提案されたユーザー コンテキストを無視すると、トラフィックが低下する可能性があります。

ARI プッシュ配信モード

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

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

fig1

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

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 は定期的にクエリ メッセージをお客様のサーバーに送信して料金の更新をリクエストします。お客様のサーバーは、更新された料金と空室状況のデータを含む Transaction メッセージでそれらのメッセージに応答します。

次の図は、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> です。詳細については、トランザクション メッセージと料金の更新をご覧ください。

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

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

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

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

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

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

fig3

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

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

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

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

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

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

ステップ 2: ヒント応答メッセージ

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

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

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

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

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

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

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