旅行は最も正確に収集するのが難しい価格帯であり、それも僅差ではない。小売商品ページの価格は、多かれ少なかれ「事実」だ。特定の市場においては誰にとっても同じであり、変化も緩やかだ。しかしフライト運賃はそのどれにも当てはまらない。同じ便の同じ座席でも、どこから検索しているか、どの通貨を使っているか、以前に検索したことがあるか、そして航空会社の収益管理システムが直近数分間に何を決定したかによって、異なる価格が提示されうる。ホテルの料金も同様の挙動を示す。
運賃集約や旅行インテリジェンスを扱うチームにとって、これは一文に集約できる問題だ。買い手に提示される運賃は、プロバイダーがその買い手を誰だと、どこにいると判断するかに依存する。 単一のオフィスIPからこのデータを収集すれば、単に部分的な情報しか得られないだけでなく、間違った運賃、つまり自分がいない市場向けに提示された運賃を得ることになる。本稿はなぜ旅行運賃の集約にプロキシが必要なのかで扱った内容をさらに掘り下げ、レジデンシャルプロキシがフライトおよびホテルデータにとって正しいアクセス層である理由となる仕組みに焦点を当てる。
収集対象となるもの
旅行データの収集は、いくつかの関連する領域にまたがる。
- フライト運賃 — 路線、日付、キャビン、運賃クラスごとの価格、さらに空席状況、運賃規則、追加サービス(手荷物、座席指定)を、航空会社およびそれらを再販するOTAやメタサーチエンジンにわたって収集する。
- ホテル料金 — 物件、日付、部屋タイプ、宿泊人数ごとの1泊料金、さらに空室状況とキャンセル条件。
- レンタカーおよびパッケージ — 同様の構造で、場所と日付によって価格が決まる。
共通するのは、これらすべてが特定の瞬間に、特定の市場にいる特定の買い手に対して提示されるという点であり、これこそがアクセスの問題である理由だ。
なぜ旅行が特にプロキシの問題となるのか
小売のスクレイピングには地理的な要素が1つしかない。旅行にはそれが積み重なる4つの特性があり、そのすべてがプロキシ層に関わってくる。
1. 運賃は販売地点(POS)ごとに価格設定される。 これが決定的な特徴だ。航空会社やOTAは、同じ旅程でも販売地点、つまり買い手が予約している市場によって異なる価格を設定する。ニューヨークとロンドン間の往復便は、米国のPOSから予約する場合と、英国やインドのPOSから予約する場合とで、異なる運賃、異なる通貨になりうる。これは例外的なケースではなく、ビジネスの核心であり、そもそもクロスマーケットの運賃比較が存在する理由でもある。特定の市場の買い手が実際に目にする運賃を捉えるには、その市場にいるように見える必要があり、つまりその地域のレジデンシャルIPが必要になる(国やシティレベルのターゲティング)。
2. 運賃はセッションベースである。 運賃検索は単一のリクエストではなく、検索、結果表示、旅程選択、価格確認という一連の流れだ。プロバイダーはそのセッション内で運賃を提示し保持するため、途中でIDが変わると本物の買い手には見えない。これが、他の分野では単に便利とされるスティッキーセッション(スティッキーとローテーティングの比較)が、旅行では必須である理由だ。運賃フローの全体が一貫した一つのIDから発生する必要がある。
3. 運賃は消滅性を持つ。 収益管理システムは絶えず価格を更新し、空席状況もリアルタイムであるため、1時間前に収集した運賃はすでに間違っている可能性がある。鮮度は最優先要件であり、定期的な巡回ではなく継続的で大量の収集が求められる。
4. 旅行業界は厳重に防御されている。 航空会社は実際の予約数に対する検索数の比率である「ルック・トゥ・ブック比率」を監視し、成約に至らない大量の検索トラフィックをコストであり脅威だと見なす。GDSシステム、OTA、メタサーチエンジンはいずれも本格的な不正ボット対策を実施している。データセンターIPはすぐに検知され、CAPTCHA、ブロック、あるいは最悪の場合は異なる運賃を提示される。つまり、実際の旅行者には決して提示されない価格を記録してしまうことになる(スクレイパーがブロックされる理由)。
まとめると、旅行データを正確に収集するには、正しい市場において、一貫したセッションを保ちながら、大規模かつ継続的に、本物の買い手のように見える必要がある。これはまさにレジデンシャルプロキシが解決すべき問題だ。
レジデンシャルプロキシが果たす役割
レジデンシャルプロキシは、実際の消費者IPを経由してリクエストをルーティングするため、旅行プロバイダーは本物の現地の買い手に対するのと同じように価格を提示する。具体的には以下の通りだ。
真の販売地点(POS)運賃。 必要な国へのジオターゲティングにより、実際にそのPOSから予約する買い手として運賃を収集できる。米国からの運賃は米国から、ドイツからの運賃はドイツから、それぞれ市場ごとにラベル付けされる。これにより、クロスマーケット比較は最終的に、1つの地点から外挿した数値ではなく、実際のPOSごとの価格に基づくものとなる。
ボット版ではない本物の運賃。 レジデンシャルIPは実際のユーザーとしての信頼性を持つため、疑わしいトラフィックに提示される劣化した、ブロックされた、またはCAPTCHA付きの応答ではなく、実際に提示される価格と空席状況を取得できる。旅行分野では「ボット運賃」が実際に異なる数値になりうるため、これが使えるデータとノイズの分かれ目となる。
セッション一貫性のある収集。 運賃フローの間、スティッキーセッションを保持し、検索、選択、価格確認がすべて同一のIDから行われるようにする。これはプロバイダーが期待する挙動であると同時に、提示価格の整合性を保つためにも必要だ。検索間ではなく、1つの検索内ではなく、新しいIDにローテーションする。
完全で鮮度の高いカバレッジ。 大規模なローテーティングプールがあれば、少数のIPがレート制限に引っかかることなく、多数の路線、日付、市場にわたって継続的に収集を実行できる。これが消滅性のある運賃データを陳腐化させずに最新に保つ鍵となる(データ収集の質に関する原則はデータ収集のためのレジデンシャルプロキシと同様)。
仕組み
Shifterゲートウェイでは、プロキシのユーザー名に国コードを埋め込むことで販売地点(POS)をターゲットにできる。エンドポイントは1つで、IPリストは不要だ。
# 米国から予約する買い手として運賃を収集するcurl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://fare-source.example
# 同じ路線を、英国の販売地点から価格取得するcurl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 https://fare-source.example仕組み自体よりも重要な、旅行特有の実践事項が2つある。第一に、ロケールと通貨を販売地点に合わせること。英国POSのリクエストが米国ロケールを送信したり、USDを要求したりするのは矛盾であり、誤った結果やブロックにつながる。Accept-Languageとサイトの通貨選択をその市場に合わせること。第二に、運賃フロー全体でスティッキーセッションを保持すること。ユーザー名に-sid-<id>-ttl-<seconds>を追加することで、複数ステップの検索が同一のIPで維持されるようにする。断続的ではなく一貫したブロックが発生する場合は、IPの品質またはリクエストの挙動に問題があることを示しており、これについてはブロックを回避する方法で扱っている。また、プールの品質は提示される価格にも影響する(IPレピュテーション)。
まず認可されたソースを検討し、責任を持って収集する
旅行分野において特に強調すべき点が2つある。
適合する場合は公式チャネルを利用する。 多くの航空会社、ホテルチェーン、OTAはAPI、アフィリエイトフィード、またはGDSアクセスを提供している。認可されたフィードがニーズをカバーしている場合、それが最初の選択肢として優れている。安定していて、構造化されており、許可されているからだ。プロキシは、そうしたチャネル外の公開運賃データや、単一のフィードでは得られない市場やプロバイダー横断的な幅広さのために使うものだ。適合する場合はまずAPIから始めるのが単純に良い実践だ。
ルック・トゥ・ブック比率に配慮する。 旅行プロバイダーは、各検索に実質的なコストがかかるため、成約に至らない検索量に対して異常に敏感だ。適切なペースで収集し、プロバイダーに過度な負荷をかけず、利用規約とレート制限を尊重し、認証が必要なものではなく公開運賃データを収集すること。これは良識ある行為であると同時に自己防衛でもある。積極的すぎる収集は、まさにソース側の防御を強化させる原因となる。個人データには一切関わらず、不確かな点については法的助言を得ること(ウェブスクレイピングは合法か)。プロキシはリクエストがどのIPから発信されるかを変えるものであり、そのリクエストを行うべきかどうかを変えるものではない。Shifterで許可されている事項については、当社の利用規約が正式な情報源となる。
FAQ
フライトやホテルのデータになぜプロキシが必要なのか? 運賃は販売地点ごとに価格設定されるため、同じ旅程でも予約する市場によって金額が異なり、プロバイダーは自動アクセスに対して厳重に防御しているからだ。単一の場所からでは、ある1つの市場の運賃、しかもしばしばボット版しか見えない。レジデンシャルプロキシを使えば、各市場の買い手に実際に提示される本物の運賃を収集できる。
販売地点(POS)価格設定とは何か? 航空会社やOTAは、買い手が予約している市場、すなわち販売地点に基づいて同じフライトに異なる価格を設定する。これが、同じ座席でも米国と英国とで異なる金額(かつ異なる通貨)になりうる理由であり、正確な運賃データを市場ごとに収集しなければならない理由でもある。
旅行データにはスティッキーセッションが必要か? 通常は必要だ。運賃検索は複数ステップのフロー(検索、選択、価格確認)であり、プロバイダーはセッション内で価格を提示するため、そのフローは一貫した1つのIPから行われるべきだ。フロー中はスティッキーセッションを使い、検索間でローテーションし、1つの検索内ではローテーションしないこと。
航空会社やOTAのAPIを使うべきか? 認可されたAPI、アフィリエイトフィード、またはGDSアクセスがニーズをカバーしている場合はそうすべきだ。安定していて許可されているからだ。プロキシは、そうしたチャネル外の公開運賃データや、単一のフィードでは提供されないクロスマーケットの幅広さのために使う。適合する場合はAPIから始めること。
旅行運賃にはレジデンシャルプロキシとデータセンタープロキシのどちらが良いか? レジデンシャルだ。旅行プロバイダーはデータセンターIPを積極的に検知しブロックし、異なる運賃を提示する場合がある。そのため、データセンターでは誤った、またはブロックされた結果しか得られない。レジデンシャルIPは、本物の買い手が目にする、販売地点として正確な本物の運賃を確認できる。
結論
旅行運賃データは、販売地点ごとに価格設定され、セッションベースであり、消滅性があり、かつ厳重に防御されているという、これらすべてを同時に備えているという点で特異に難しい。運賃集約製品の正確さは、その市場から予約する本物の買い手として、一貫したセッションを保ちながら、データが求める鮮度で各市場の運賃を収集できるかにすべてかかっている。適合する場合は認可されたフィードを使い、それ以外は販売地点に合わせたレジデンシャルIPを経由させ、ロケールと通貨を一致させ、各運賃フローにわたってスティッキーセッションを保つこと。
これを正しく行えば、実在しない予約を表す平均化された数値ではなく、各市場で旅行者が実際に提示されている運賃を得ることができる。高品質なレジデンシャルプロキシネットワークこそが、その収集を販売地点として正確かつ完全なものにする要であり、料金ページにはGB単位のプランが用意されており、製品が依存する路線、物件、市場に対して試すことができる。