不動産チームはスクレイピングインフラを自ら運用したいとは考えていません。彼らが知りたいのは、どこで供給が増えているか、どこで価格が引き下げられているか、比較対象となる物件がいくらで売り出されているか、そして在庫がどれくらいの期間動いていないかです。収集レイヤーはそのための手段であり、多くのチームにとって、ブラウザ自動化やプロキシ運用のための人員を雇うことなくそれを得る最も直接的な方法がweb scraping APIです。
何を収集し、収集後にどうモデル化するかについては、本ブログの他の記事で扱っています。査定額、賃料、住宅ローンデータ、リアルタイムの住宅市場フィード、そして複数ポータルにまたがる物件情報の集約です。今回の記事は収集レイヤー自体について扱います。なぜ不動産ポータルがチームをAPIへと向かわせるのか、APIが不動産ページにどう対応するのか、そして経済性がどう成り立つのかです。
不動産ポータルの収集がやっかいな理由
不動産サイトを他の多くのサイトより扱いにくくしている性質が4つあります。
地図とスクロールのために作られており、ページ単位ではない。 検索結果は地図の移動やリストのスクロールに応じてJavaScriptで読み込まれるため、単純なHTTPリクエストでは空のシェルしか返ってこないことがよくあります。
結果はページネーションされており、カーソル駆動である。 1ページ目から2ページ目へ移動する処理は多くの場合サーバー側の状態に依存しており、これが単純なページ単位の取得を壊してしまいます。
ローカライズされている。 ポータルは国別、場合によっては地域別にサービスを提供しているため、見える内容はリクエストがどこから来ているように見えるかによって変わります。
防御されている。 価値が高く頻繁に更新される在庫は自動化されたトラフィックを引き寄せるため、ポータルはそれに応じて保護策を講じています。
この4つすべてを自社で対応するには、ヘッドレスブラウザ、プロキシ管理、リトライロジック、フィンガープリント調整が必要になります。web scraping APIはこれらを1つのリクエストにまとめてくれます。
APIが不動産ページにどう対応するか
Shifter Web Scraping APIでは、ポータルごとの問題それぞれに直接的な制御手段があります。
地図表示とリスト表示。 render_js=1は追加のクレジットコストなしにヘッドレスChromeでページを実行し、wait_for_cssはリストカードが実際にレンダリングされるまでキャプチャを保留します。JavaScriptの指示によって、キャプチャ前にスクロールしたり「もっと見る」コントロールをクリックしたりできます。JavaScriptのレンダリングを参照してください。
結果カード。 リスト型のextract_rulesは、ページ上のすべてのリストカードを、あなた側でHTMLパーサーを使うことなく、リストごとに1つのオブジェクトとしてJSONで返します。
ページネーション。 session_idはクッキー、ブラウザの状態、上流のIPをリクエスト間で保持するため、カーソル駆動の結果セットを順番にたどることができます。セッションはアイドル状態が10分続くと期限切れになり、セッションが有効な間は国を同じに保つ必要があります。セッションとプロキシを参照してください。
ローカライズ。 countryはリクエストごとにISO alpha-2コードを受け取ります。グローバルなジオロケーションとpremium_proxy=1によるレジデンシャルプールは、Growthプラン以上で利用可能です。
証跡。 screenshot=1はレンダリングされたページをキャプチャします。これは、価格の引き下げや取り下げなど、ある時点での物件情報の状態が重要な場合に役立ちます。
長時間のレンダリング。 webhook=<URL>は、接続を開いたまま待つのではなく、レスポンスが準備できた時点であなたのエンドポイントに届けます。
ある市場の検索結果に対するリクエストは次のようになります。
curl "https://scrape.shifter.io/v1?api_key=YOUR_API_KEY\
&url=https%3A%2F%2Fportal.example.com%2Fsearch%3Fcity%3Dlyon\
&render_js=1&wait_for_css=.listing-card\
&country=fr&premium_proxy=1&session_id=lyon-walk-03\
&extract_rules=%7B%22listings%22%3A%7B%22selector%22%3A%22.listing-card%22%2C%22type%22%3A%22list%22%2C%22item%22%3A%7B%22price%22%3A%7B%22selector%22%3A%22.price%22%2C%22output%22%3A%22text%22%7D%2C%22area%22%3A%7B%22selector%22%3A%22.area%22%2C%22output%22%3A%22text%22%7D%2C%22link%22%3A%7B%22selector%22%3A%22a%22%2C%22output%22%3A%22%40href%22%7D%7D%7D%7D"ターゲットURLはURLエンコードされていますが、これはそれ自体のクエリ文字列を持っているためで、そうしなければAPIリクエスト自体のパラメータとして読み取られてしまうからです。レスポンスはlistings配列を持つ1つのJSONオブジェクトです。セレクタが何も見つけられなかったフィールドはnullとして返ってきます。これは以下で扱う監視において重要な点です。
さまざまなチームによる活用方法
買収・投資チームは対象となるサブマーケットにおける新規供給と値下げを監視し、値下げのタイミングを交渉材料として利用します。彼らに必要なのは、定義された一連のエリアに対する翌日イベント検知であり、全国規模のクロールではありません。
仲介会社は自社の物件情報のシェアを競合他社とエリアごとに比較し、競合の物件情報がどれくらいの速さで動くかを追跡します。これは仲介会社レベルで留めるべきです。物件情報中の担当者連絡先は個人データであり、分析に必要となることはめったにありません。
PropTechプロダクトは自社ユーザー向けに比較物件情報やフィードを構築します。ここではAPIは正規化パイプラインへの一つの入力であり、フィールドの定義はポータルや国によって異なります。
賃貸事業者は自社のサブマーケットにおける募集賃料とコンセッション（優遇条件）を監視します。コンセッションは価格フィールドではなく説明文のテキストに含まれることが多いため、抽出ルールは見出しの賃料だけでなく説明文自体を捕捉するべきです。
貸し手や保険会社は自社がエクスポージャーを持つエリアの市場状況を追跡します。境界線は公開されている市場データまでであり、個々の借り手や居住者の情報には決して踏み込みません。
経済性:クレジットを中心に設計する
1クレジットで1回の成功したリクエストを購入できます。そのリクエストが何を返すかは関係ありません。レンダリング、抽出ルール、スクリーンショット、API自体のリトライはすべて含まれており、失敗したリクエストやターゲット側のエラーには課金されません。
これは不動産にとって直接的な設計上の帰結をもたらします。40件のリストカードを返す検索結果ページも、1件の物件情報を返す詳細ページも、同じ1クレジットのコストです。したがって効率的なパターンは、カードが必要なフィールド（価格、面積、部屋数、リンク）を持っている限り結果ページから収集し、物件情報が新規であるか、カードが変化した場合にのみ詳細ページを取得することです。
数千件のアクティブな物件情報がある市場では、この違いはクレジット面で桁違いになることが多いです。同じ支出でより頻繁に結果ページを再訪できるため、鮮度も向上します。
さらに2つのコストレバーがあります。各市場の動きの速さに合わせた頻度で更新すること。ほとんどの物件情報においては日次で十分です。そして、正しくパースされた行に対して費やされたクレジットに注意を払うこと。壊れたセレクタであっても、成功はしたが役に立たないレスポンスごとにクレジットが消費されるからです。
静かな破損を監視する
ポータルはリデザインされますが、変更されたセレクタはリクエスト自体を失敗させません。nullを返し、リクエストは成功し、クレジットは消費されます。
フィールドごと、ポータルごと、国ごとのnull率を移動ウィンドウで追跡し、ベースラインから跳ね上がったときにアラートを出してください。抽出ルールにバージョンを付け、修正内容を追跡できるようにし、パース前に生のレスポンスを保存しておくことで、修正済みルールを再取得のためにもう一度課金することなく再生できるようにしてください。読み込みパターンについてはweb scraping APIのデータをSQLに移行するにまとめてあります。
APIが適切な収集レイヤーである場合、そうでない場合
APIを選ぶのは、レンダリングとアンチボット対応が主な負担であるとき、チームが小規模でありインフラ志向よりデータ志向であるとき、そして可能な限り低い単位コストよりも成功ごとの予測可能な課金の方が重要であるときです。
自前で管理するプロキシを選ぶのは、完全にカスタムなブラウザフローが必要なとき、自前でスタックを持つ方が安く済む規模で運用しているとき、あるいはすでにスクレイピングエンジニアを抱えているときです。プロキシベースのアプローチについては不動産データのためのプロキシ活用で扱っています。
ライセンス供与されたフィードを最初に選ぶのは、それが対象市場に存在する場合であればどこでもそうすべきです。カバレッジとフィールドの品質は通常より優れており、利用条件も明確です。収集は、ライセンスが提供しないものに使ってください。
適切な範囲にとどまる
各ポータルの利用規約を尊重し、リクエスト量を適切な範囲に保ってください。所有者、仲介担当者、居住者の詳細情報はデフォルトで個人データとして扱い、分析に必要でない場合は取り込み時に取り除いてください。スクリーンショットは物件情報が何を示していたかの証跡として使い、再公開するための素材としては使わないでください。より広い枠組みはレジデンシャルプロキシとGDPR準拠にあります。
FAQ
不動産ポータルにはJavaScriptレンダリングが必要ですか?
ほとんどの現代的なポータルでは、はい必要です。物件情報の結果は初期ページの読み込み後に読み込まれるためです。静的な取得と同じクレジットしかかからないため、結果がクライアントサイドでレンダリングされる場合は有効にしない理由はほとんどありません。
1つのAPIで複数国のポータルをカバーできますか?
はい、リクエストごとにcountryを設定し、市場ごとにセッションを分けることでカバーできます。グローバルなジオロケーションにはGrowthプラン以上が必要です。
ページネーションされた検索結果を確実にたどるにはどうすればよいですか?
検索ごとにsession_idを使い、その中で国を一定に保ち、たどる作業を止めずに進めてください。セッションはアイドル状態が10分続くと期限切れになります。
詳細ページと結果ページ、どちらをスクレイピングする方が安いですか?
結果ページの方が安く、物件情報のカードが必要なフィールドを持っている場合はどこでもそうです。1クレジットで多数の物件情報が返ってくるため、詳細ページは新規または変更のあった物件情報のために取っておくことができます。
結論
ほとんどの不動産チームにとって、市場インテリジェンスの難しい部分は何を測定するかを決めることではありません。地図やスクロール、人間の訪問者のために作られたポータルから信頼できるデータを取り出すことです。web scraping APIは、レンダリング、ページネーション、ローカライズ、リトライをリクエストパラメータへと変え、データが届いたときにのみ課金します。
まず結果ページから収集することでクレジットを中心に設計し、市場ごとのセッションで検索をたどり、静かな破損についてnull率を監視し、ライセンス供与されたフィードが存在する場合はどこでもそれを利用してください。この製品はWeb Scraping APIページにあり、プランは料金ページに、より広いユースケースは不動産ページにあります。