PropTechチームは自社のデータ要件を「不動産データ」とひとくくりに表現しがちで、まるで評価額、賃料、住宅ローン金利が1つの表の3つの列であるかのように扱う。しかし、これらは3つの異なる問題である。それぞれ異なるソースから来ており、異なるライセンスやプライバシー上の制約を伴い、そして最も重要なことに、意味するところが異なる。
これらを1つのデータセットとして扱うことから生じる失敗は、収集の失敗ではない。ラベリングの失敗であり、それはずっと後になって、ユーザーが自社の製品が事実として提示した数値に異議を唱えたときに表面化する。
3つのデータ種別、3つのソーシングの現実
コレクターを書く前に、自分が実際にどれを取得しているのかを明確にすべきである。その答えが、手法と、何を主張できるかの両方を左右するからだ。
| データ種別 | 権威あるソース | ウェブから得られるもの | それが意味しないもの |
|---|---|---|---|
| 取引価格 | 公的記録：土地登記、権利証書、査定人記録 | 売却価格、譲渡日、区画属性 | 現在の市場価値ではない |
| 評価額 | 税査定人記録 | 課税のための評価 | 市場評価額ではない |
| ポータルの推定値 | ポータル自身のモデル | 独自モデルの出力 | 鑑定でも事実でもない |
| 募集賃料 | 掲載中の物件情報 | 今日、大家が要求している金額 | 借主が実際に支払っている金額ではない |
| 成約賃料 | ライセンスされたデータセット、事業者データ | 公開されることは稀 | 掲載情報から導出できない |
| 住宅ローン金利 | 貸し手の金利ページ、公式統計シリーズ | 商品・階層別に公表された金利 | どの借り手も実際に得た金利ではない |
PropTechデータにおける最も有用な規律は、「観測」「評価」「募集」「推定」を別々の列に保ち、valueという1つのフィールドに統合させないことである。
本来使われるべきソースから始める
以下の順序で下っていき、上位の層が実際にカバーしていないものについてのみ、下位に到達すべきである。
まず公式・バルクソース。 土地登記所、査定人事務所、統計機関はしばしばバルクファイルやAPIを公開している。これらは権威があり、許可されており、外部から再構築できない履歴を持つ。取引価格と区画属性については、通常これで答えの全てとなる。
次にライセンスされたフィード。 ブローカーやマルチリスティングデータは一般にライセンスの下で利用可能である。製品が信頼できるフィールドを備えた完全な掲載情報のカバレッジを必要とする場合、ライセンスの方が代替手段のエンジニアリングと法的リスクよりも安く済む。
最後に公開ウェブの観測を用い、上記2つでカバーされないもの、すなわち募集賃料とその譲歩条件、リアルタイムの在庫、公表された貸し手の金利表、そしてこれらが市場ごとにどう異なるかを補う。
一番下の層にいきなり飛びつくことが、このカテゴリーにおける最も一般的かつ最も高くつく間違いである。掲載情報側の作業についてはproxies for real estate dataで扱っている。
評価額：モデルを測定値として提示してはならない
ポータルの推定値は、見ることのできないデータで訓練されたモデル出力であり、ポータルが公表するかもしれないし、しないかもしれない誤差分布を持つ。それらは自社モデルの1つの特徴量としては有用だが、評価額ではない。
3つのルールがこれを弁護可能なものにする。推定値はその出所と観測日とともに保存し、単なる数値として保存しない。ラベルを付け替えない。推定値は推定値であり、「市場価値」ではない。そして自社製品が評価額を出す場合は、それとともに信頼区間を公表すること。信頼区間を伴わずに提示された点推定値は、実際には持っていない精度として読まれてしまうからだ。
正式な評価額に近いものについては、収集したデータは専門的プロセスへの入力であり、それに代わるものではない。
賃料：募集額は成約額ではなく、譲歩条件は本文の中にある
掲載賃料は募集賃料である。軟調な市場では、借主が実際に支払う額を上回ることが多く、その差額の中に譲歩条件が存在する。1ヶ月無料、手数料免除、駐車スペース込み、別価格での短期契約などである。
こうした譲歩条件は通常、構造化フィールドではなく自由記述の説明文の中にある。つまり、賃料フィールドのみから構築された募集賃料のシリーズは、人々が最も測定したい状況においてまさに系統的に誤ったものになる。説明文を譲歩条件の言葉について解析し、たとえフラグと生の文しか抽出できなくても、それを独自のフィールドとして保存すること。
さらに2つの実務的な点がある。比較可能な単位に正規化すること、通常は期間あたり寝室数あたりの賃料、あるいは床面積あたりの賃料である。混在するユニットタイプ全体の中央値は、市場と同程度にミックスそのものを測定してしまうからだ。そしてユニット単位の観測と建物単位の観測を分けて保つこと。1つのユニットを掲載している建物は、その価格で賃貸されている建物ではない。
住宅ローンデータ：金利は数値ではなくマトリックスである
公表された貸し手の金利は、商品、期間、ローン・トゥ・バリュー(LTV)帯、借り手の階層、地域、時にはチャネルによって異なる。貸し手のページから「その金利」を保存するだけのスクレイパーは、マトリックスの1つのセルだけを捕捉し、軸を捨ててしまっている。
商品、期間、LTV帯、記載されている借り手の条件、ポイントや手数料、その数値が名目金利かAPRか、貸し手が示す発効日、そして自分が観測した日を記録すること。名目金利とAPRの区別は、下流で最も混乱を引き起こすものであり、両者は比較可能ではないにもかかわらず、同じページに両方現れることがある。
中央銀行や住宅機関からの公式統計シリーズは、自分の収集結果を照合するための基準真値である。収集した平均値が公表されたシリーズから乖離している場合、変化したのは通常、収集の方である。
譲れない境界線が1つある。公表された金利と条件は収集するが、借り手個人のデータは決して収集しないこと。個々の申請、信用ファイル、個人の財務詳細は公開ウェブのデータではなく、PropTechのロードマップにあるいかなる理由も、それらを追う正当化にはならない。
収集レイヤー
これらのソースの2つの特性が、観測地点を手法の一部にしている。
貸し手の金利表とポータルのコンテンツは地域化されているため、見える金利や掲載情報は、リクエストがどこから来ているように見えるかに依存する。そして特に金利は、1つの国の中でも州や地域によって異なることがあり、単一の国内観測地点は、ある1地域の金利を市場全体の金利として黙って報告してしまうことを意味する。
Shifterゲートウェイでは、観測地点とセッションはp.shifter.io:443に対する認証情報の中に含める。
customer-USERNAME-country-us-state-tx-sid-rates-tx-11-ttl-600:PASSWORDcountry-usとstate-txは、読み取っている金利の市場にリクエストを配置し、sid-rates-tx-11は金利表の全体をたどる間、1つの出口を保持することで、スナップショットの各セルが同一のセッションから来るようにし、ttl-600はそのアドレスを10分間維持する。ttlはsidと組み合わせて初めて意味を持つ。セッション識別子がなければ、ゲートウェイはリクエストごとにローテーションし、それは独立した検索には適しているが、ページネーションされたテーブルには適さない。このトレードオフはsticky vs rotating residential proxiesで説明されている。
正確な地域一致がレスポンスを得ることよりも重要な場合は、strict-trueを追加する。そうすることで、ゲートウェイは近隣地域の応答を黙って返すのではなく502を返すようになる。
頻度は各シリーズが実際にどれだけ速く動くかに従うべきである。貸し手の金利は日次、時には日中の収集を正当化する。掲載情報と募集賃料は日次である。公的記録は独自のスケジュールで更新され、多くの場合週次または月次であり、公表よりも速く収集しても重複した行を生むだけである。実際のバックオフを伴った通常のリクエストレートを保つこと。rate limiting and request throttlingにあるとおりである。
あなたを誠実に保つスキーマ
すべてのレコードは、数値そのものに加えて次を伴うべきである。上記の表からの観測種別、ソース、ソースが示す発効日、自分が観測した日、市場、そして観測した出口の場所、そして信頼度または検証フラグである。
発効日と観測日は別のフィールドであり、これらを混同することは実際のバグである。先週火曜日に発効した貸し手の金利表を今日収集した場合、それは火曜日の金利である。観測日に基づいて構築されたインデックスは、クローラーが遅れただけなのに、実際には起きなかった動きを示すことになる。
観測がどこで、いつ行われたかを記録することの一般的な論拠はthe case for a vantage-point standardにある。
プライバシーとコンプライアンス
不動産データは、他のほとんどの商業ウェブデータよりも個人に近い位置にあり、規則は法域によって大きく異なる。
公的記録は、ある国では所有者名を明記しているが、別の国ではその情報が制限されている。所有者名、連絡先、居住者を特定できるものは、デフォルトで個人データとして扱い、根拠がある場合にのみ収集し、製品がそれを必要としない場合は取り込み時点で除去すること。賃料のインデックスに借主の名前は必要ない。
各ソースの利用規約を尊重し、量を適切に保ち、ライセンスが意図された経路である場合はライセンスを取得すること。一般的な考え方はresidential proxies and GDPR complianceとethical residential proxies for AI data collectionにある。
FAQ
ポータルの推定値を自社製品の評価額として使ってよいか?
評価額としては不可。特徴量として、あるいは明確に帰属を示した第三者の推定値としてなら、ポータルの利用規約に従う限り可能である。ラベリングこそが重要な部分である。
募集賃料ではなく成約賃料を得るにはどうすればよいか?
一般的にはライセンスされたデータセットまたは事業者との提携を通じてである。掲載情報にはそれらは含まれておらず、募集賃料からそれらを推測することはモデリングであり、そのように開示されるべきである。
バルクファイルが存在するなら、公的記録をスクレイピングする必要はあるか?
いいえ、そしてバルクファイルの方が優れている。権威があり、完全で、許可されている。ウェブは、バルクで公開されていないものにのみ使うこと。
なぜ我々の住宅ローン金利は公表されている全国平均と一致しないのか?
通常、1つの地域、1つのLTV帯、または1つの借り手階層のみを収集し、代表性のない構成で平均を取ったためである。軸を記録すれば、通常その不一致は自ずと説明がつく。
結論
評価額、賃料、住宅ローン金利は、語彙は共有していても、それ以外は何も共有していない3つの収集問題である。信頼できるPropTechデータを構築するチームは、まず公式・ライセンスされたソースに向かい、残りの部分に公開ウェブを使い、観測、評価、募集、推定を発効日と観測日の両方を伴う別々のラベル付きフィールドとして保つ。
各市場をその市場から収集し、テーブルや結果セットにわたってセッションの一貫性を保ち、モデルの出力を決して事実として保存しないこと。これらの観測をライブの市場シリーズに変える方法についてはbuilding a real-time housing market data feedで扱っている。製品としての見方はresidential proxies for data gatheringページに、料金はpricing pageにある。