1つのポータルから物件情報を収集するのはスクレイピングの問題であり、よく理解された問題です。しかし、十数か国にまたがる30のポータルから情報を収集し、その結果を1つの検索可能な在庫として提示するのはまったく別の仕事であり、その難しさのほとんどは取得作業そのものにはありません。
問題は、同じアパートを説明する2つのポータルが、その広さ、部屋数、価格、さらには物件の種類についてさえ食い違うという事実にあります。しかも、それぞれが自分たちの地域の慣習に照らせば正しいのです。
まだ収集作業自体を構築している段階であれば、不動産データのためのプロキシがその領域をカバーしています。本ガイドは、データが届いた後に何が起こるかについてのものです。
額面通りの意味を持たないフィールド
ポータル間の統合失敗のほとんどは、5つのカテゴリーに起因します。
面積。 平方メートル、平方フィート、そして市場によっては現地独自の単位が使われます。さらに厄介なのは、測定基準そのものが異なることです。総内法面積、純内法面積、そしていくつかの国では法的に定義された測定基準があり、物件の一部を除外または割り引いています。単位の変換は些細なことですが、基準の調整はそうではなく、単純な変換は基準の違いを黙って混ぜ合わせてしまいます。
部屋数。 大陸ヨーロッパの多くでは、見出しの数字はベッドルームではなく居間を含めた部屋数を数えます。「3 pièces」と「3 bedroom」は同じ物件ではありません。両方を1つのbedroomsカラムに保存すると、市場間を比較したときにだけ表面化する誤りを含む在庫が生まれます。
価格の意味。 希望価格、参考価格、「offers over」、オークションの最低落札価格、価格応相談、そして賃貸市場では、その数字にサービス料、光熱費、地方税が含まれるかどうか。これらは同じ通貨記号をまとっただけの、異なる数量です。
保有形態と所有権の種類。 フリーホールド、残存期間のあるリースホールド、区分所有(strata/condominium)の取り決め、協同組合所有。残存期間の短いリースホールドは、同じ価格のフリーホールドとは実質的に異なる資産です。
物件タイプの分類体系。 どのポータルも独自の分類を持っており、それらはきれいに対応しません。メゾネット、デュプレックス、内部階段のあるアパートを1つのカテゴリーとするか3つのカテゴリーとするかは、一度決めてどこにでも適用すべき製品上の判断です。
これを扱いやすく保つ原則はこうです。ソースの元の値を、正規化した値と並べて、常にそのまま保存すること。 後になって、あるポータルの面積基準が想定と異なることが判明したときに、生データがあれば再導出できます。それがなければ再収集するしかなく、過去のデータは単純に失われます。
2番目のポータルを統合する前に正規モデルを構築する
順序が重要です。ポータル1を統合してから、そのスキーマにポータル2を後付けするチームは、結局のところポータル1のモデルに別の名前をつけただけの正規モデルにたどり着き、その後のすべての統合がそれと衝突することになります。
実用的な正規レコードは3つの層に分かれます。
| 層 | 内容 | 分ける理由 |
|---|---|---|
| 生データ | ソースが公開した通りのフィールド、そして取得時のメタデータ | 想定が変わったときに再導出できる |
| 正規化済み | 自社の単位、自社の分類体系、自社の価格の意味付け、変換の記録付き | 製品がクエリする対象 |
| 派生 | 単位面積あたり価格、算出された指数、スコア | 再計算可能で、決して正とはならない |
正規化された各フィールドには、どのルールによって導出されたかのメモを付けるべきです。あるクライアントが、なぜある物件が自社プラットフォームでは68平方メートルなのにポータルでは73平方メートルなのかと尋ねてきたとき、答えは調査ではなく参照であるべきです。
通貨、そして変換後の値だけを保存しないこと
複数国にまたがる在庫については、公開された通りの元の金額とその通貨コード、加えて適用した為替レートとそのレートの日付を保存してください。
変換後の数値だけを保存すると、情報が不可逆的に失われます。レートは変動し、修正が発表されることもあり、過去の掲載情報を見るクライアントが求めているのは、今日のレートで再表現された価格ではなく、当時提示された価格です。保存された元の値からクエリ時に変換するか、日付付きレートとともに変換結果を保存して、後から監査・再計算できるようにしてください。
複数ポータルにまたがる同一物件の名寄せ
同じ物件が複数のポータルに、異なる仲介業者によって、異なる写真、異なる説明文、そして時には異なる価格で日常的に掲載されます。名寄せ(identity resolution)によってこれが1つのレコードに変換されますが、これについてはリアルタイム住宅市場データフィードの構築で詳しく扱っています。そこでも在庫のカウントを動かしているのは同じ仕組みだからです。
集約に特有なのは、重複がグループ化された後に何をするか、つまりどの値を採用するかの決定です。
ポータルごとではなく、フィールドごとにソースの優先順位を定義してください。あるポータルは最も信頼できる面積の数値を持ち、別のポータルはより良い写真を持ち、3つ目のポータルは価格の更新が最も速いかもしれません。単一のグローバルなランキングでは、これらが失われてしまいます。
そして食い違いは明示的に扱ってください。グループ化された掲載情報が許容範囲を超えて価格で食い違う場合、それはエラーというよりシグナルです。ある仲介業者がまだ反映していない価格変更を意味することもあれば、グループ化の誤りを意味することもあります。フラグを立て、範囲を示し、代替案をリンクしたままにしてください。黙って1つを選び他を破棄することは、アグリゲーターが信頼を失う原因になります。
マッチ率の測定と公開を含む、一般的なマッチングの規律については、競合の品揃えとカタログの隙間で説明されているものと同じです。
カバレッジは国単位であり、グローバルではない
グローバルな不動産市場もグローバルなポータル群も存在しません。各国には独自の主要ポータル、独自の仲介業者の行動様式、そもそも何が公に掲載されるかについての独自の慣習があります。市場によっては、取引の大部分が公開ポータルに一切現れないこともあります。
したがって、グローバルな在庫は、それぞれが独自に定義されたポータル群を持つ国別パネルの集合として扱い、カバレッジは集計値ではなく市場ごとに記録してください。国をまたいだ単一の見出し件数は、ポータルを1つしか持たない市場と6つ持つ市場の違いを覆い隠してしまいます。
実践的なルールが2つあります。カバレッジが同等でない限り、市場間で絶対的な在庫数を比較しないでください。それをすると、結局自社のパネルを測定していることになります。そして、ある市場でライセンス供与されたフィードが存在する場合は、そのライセンスを取得してください。カバレッジとフィールドの品質は通常、公開情報の収集よりもはるかに優れており、法的な立場もより単純です。
収集レイヤー
ポータルは大きくローカライズされています。表示される内容、表示される通貨、言語、時にはサイト自体が、リクエストがどこから来ているように見えるかによって変わります。1つの視点から収集する多国間アグリゲーターは、複数の市場について、ある1つの国の視点を静かに受け取ることになります。
Shifterのゲートウェイでは、市場とセッションはp.shifter.io:443に対する認証情報の中に指定します。
customer-USERNAME-country-fr-sid-listings-fr-12-ttl-600:PASSWORDcountry-frはISO alpha-2コードを使用し、sid-listings-fr-12はページネーションを含む検索全体を通して1つの出口を保持することで、結果セットが内部的に一貫性を保つようにし、ttl-600はそのアドレスを10分間保持します。sidがなければ、ゲートウェイはリクエストごとにローテーションします。これは独立した検索には適していますが、ページネーションのある検索には不適切です。
ロケールのシグナルは出口と一貫させてください。不一致は一部のポータルが返す内容を変えてしまいます。また、レート制限とリクエストスロットリングにあるように、実際のバックオフを伴う通常のリクエストレートを保ってください。ポータルごと市場ごとの収集成功率を掲載情報とともに追跡してください。あるポータルが静かに返す結果を減らし始めると、それは供給が少ない市場とまったく同じように見えてしまうからです。
フィールドの完全性は詳細ではなく品質指標である
ポータルは、任意フィールドをどれだけ完全に埋めるかという点で大きく異なります。欠落しているフィールドを未公開ではなく存在しないものとして扱うアグリゲーターは、例えば、ある市場にはエネルギー評価付きの物件がほとんどないと報告してしまうかもしれませんが、実際にはあるポータルが単にそれを公開していないだけかもしれません。
ポータルごと、フィールドごとに完全性をスコア化し、社内で公開し、ソースの優先順位を決める際に使ってください。それはまた、ライセンス供与されたフィードが単にコストがかかるだけでなく、実際に製品を改善する場所を教えてくれます。
FAQ
取り込み時に正規化すべきか、それともクエリ時に正規化すべきか？
取り込み時に正規化し、生データフィールドを保持してください。クエリ時の正規化は遅く、インデックス作成を困難にしますが、生の値がなければ、悪いルールを後から遡って修正することはできません。
部屋数を公開していてベッドルーム数を公開していないポータルはどう扱うか？
両方の概念を別々のフィールドとして保存し、ソースが与える情報を埋めてください。部屋数からベッドルーム数を推測してはいけませんし、一部の市場でしか埋まっていないフィールドを製品のフィルターがクエリすることを許してはいけません。
国をまたいで1つの正規の物件タイプ分類体系は現実的か？
浅いものであれば現実的です。最上位レベルは小さく持ち運びやすいものにし、地域固有の詳細は主要な分類体系に無理に組み込むのではなく、二次的なフィールドに置いてください。
最初に修正すべき最も価値の高いものは何か？
面積の基準と価格の意味です。これらはあらゆる派生指標に影響を与え、その誤りは誰かが2つの市場を比較するまで見えないままです。
結論
ポータル横断の集約は、スクレイピングの問題の衣をまとった正規化の問題です。取得作業はすでに解決済みの部分です。
2番目の統合の前に正規モデルを構築し、ソースの生の値を永久に保持し、日付付きレートとともに元の通貨を保存し、ポータルごとではなくフィールドごとにソースの優先順位を設定し、食い違いをエラーではなくシグナルとして扱い、グローバルなパネルは存在しないため市場ごとにカバレッジを記録してください。製品の全体像は大規模データ収集ページにあり、料金は料金ページにあります。