「リアルタイムの住宅データ」と聞くとレイテンシの問題のように聞こえるが、そうではない。住宅にはプライスティックが存在しない。取引はまばらで、個別に交渉され、成立から数週間から数か月後に公的登記簿に記録される。この市場の根底にあるものが数秒単位で動くことはない。
速く動くのはリスティングの表面だ。物件が掲載され、価格が変わり、商談中になり、取り下げられ、再び戻ってくる。これらの出来事は日々起きており、取引記録を大きく先行する。したがってリアルタイムの住宅フィードとはイベント検出システムであり、その仕事はこの表面上の変化を、役に立つほど速く、かつ信頼できるほど一貫して察知することにある。
難しい二つの問題は収集速度ではない。物件の同定と、安定したカバレッジである。
リスティングのライフサイクルをイベントとしてモデル化する
すべてのリスティングの夜間スナップショットを保存しても、市場に何が出ているかは分かる。しかし何が起きたかは分からない。そしてシグナルとなるのは何が起きたかである。
連続する観測からイベントを導き出し、それ自体を独立したレコードとして保存する。
| イベント | 重要な理由 |
|---|---|
| 新規リスティング | 新規供給であり、連鎖の中で最も早い先行指標 |
| 価格の値下げまたは値上げ | その深さと頻度が地域のモメンタムを最も明確に示す |
| 商談中や条件付き成約へのステータス変更 | 需要を示し、登記簿よりはるかに早い |
| 取り下げ | しばしば軟調な市場のシグナルであり、成約と混同されやすい |
| 再掲載 | 同一物件が戻ってきているケースが多く、データの整合性が崩れやすい箇所 |
| 公的登記簿による成約 | 権威ある結果だが、到着が遅い |
各イベントには、それを開始した観測と終了させた観測、そして境界が実際に観測されたのか、単に収集間隔によって区切られただけなのかを示すのに十分な信頼度メタデータが必要である。毎日収集しているなら、価格が1日以内に変わったことは分かるが、いつ変わったかは分からない。
物件の同定こそがシステムの核心
同じ物件が複数のポータルに、異なる参照番号で、異なるフォーマットの住所で掲載されることがある。部屋番号のフィールドが異なっていたり、そもそも欠落していることもある。時間が経つと、その物件は数か月後に新規リスティングとして再び現れる。
同定の解決に失敗すると、二つのことが同時に壊れる。在庫数が水増しされる。一つの物件が三つとしてカウントされるからだ。そして、掲載日数(days-on-market)が崩壊する。再掲載された物件が新規のものに見えてしまうからだ。
後者は特に注意が必要である。掲載日数をリセットするための再掲載は、一部の市場では意図的な慣行だからだ。すべての再掲載を新規供給として扱うフィードは、在庫がどれだけ長く滞留しているかを体系的に過小評価することになる。しかもそれは、その数値が最も重要となる市場においてこそ起きる。
実用的な同定戦略を信頼性の高い順に挙げると、まず司法管轄区が提供している場合は区画(parcel)または権利証(title)の識別子。次に、正規化された住所と部屋番号を組み合わせ、狭い許容誤差でジオコーディングした座標。そして床面積、寝室数、物件種別による属性マッチングで残りのタイを解消する。各ポータル独自の参照番号を自社の正規化された物件に紐付けて保持し、リスティングのエピソードレコードを保持することで、一つの物件が履歴を失うことなく時間をかけて複数のエピソードを持てるようにする。
サンプルを手作業でレビューしてマッチ率を測定し、それを公開する。既知の重複排除エラー率のない在庫指標は、誰にも規模を把握できない数値である。
カバレッジの広さよりも安定性
住宅指数は時系列として読まれる。つまり、観測できる範囲に何らかの変化があれば、それは市場の変化として記録されてしまう。
シリーズの途中でポータルを一つ追加すれば供給は急増したように見える。一つがブロックされて失われれば供給は減少したように見える。より深いページまで収集を始めれば在庫は増加する。そのいずれも住宅市場そのものではないが、見た目にはまったく同じに映る。
だからこそ、開始する前にパネルを固定する。定義されたポータルの集合、定義された地理的範囲、定義されたクエリセット、そしてクエリごとの定義された深さ。それぞれを完全に収集するか、明示的に不完全とマークするかのいずれかにする。パネルにバージョンを付け、すべての行にそのバージョンを刻印し、パネルへの変更は静かな改善としてではなく、文書化された方法論の断絶として扱う。
これはあらゆる縦断的なWebパネルを支配するのと同じ規律であり、より詳しい議論はjob-board data and labour-market intelligenceにある。それはそのままここにも当てはまる。
地理的条件は観測の一部である
ポータルはローカライズされている。検索結果、表示される物件、時にはどのフィールドが表示されるかまでもが、リクエストがどこから来ているように見えるかに依存する。複数の国にサービスを提供するポータルは、まったく別のサイトを返すこともある。
地域市場を報告するフィードにとって、収集はその報告対象の地域から行われなければならない。Shifterのゲートウェイでは、視点(vantage point)とセッションはp.shifter.io:443に対する認証情報の中に組み込まれる。
customer-USERNAME-country-gb-city-manchester-sid-feed-mcr-04-ttl-600:PASSWORDcountry-gbはISOアルファ2コードを使用し、city-manchesterで市場を絞り込み、sid-feed-mcr-04はページネーションを含む検索全体にわたって一つの出口を保持することで結果セットの内部的な整合性を保ち、ttl-600はそのアドレスを10分間維持する。リクエストごとではなくクエリごとに一つのセッションを使うことで、4ページ目が1ページ目とは異なる視点に属することを防げる。
出口とロケールのシグナルは一致させておく。不一致は一部のポータルが返す内容を変えてしまうためで、これはmatching proxy geo, timezone and localeで扱っている。リクエストレートは実際のバックオフを用いて通常の範囲に保つ。これはrate limiting and request throttlingで扱っている通りである。
頻度はシリーズごとに、一律の設定ではなく
日次収集はリスティング表面のほぼすべてに十分である。リスティングは時間単位では変化せず、日次パスで翌日のイベント検出が可能になるからだ。
より速い収集が正当化されるのは二つのケースだ。ホットな市場における小規模なウォッチリストで、商談中ステータスが数時間以内に変わる場合。そして新築物件のリリース時の発売期間だ。公的登記簿データは独自のスケジュールで更新されるため、その公表頻度より頻繁に収集しても重複が生じるだけである。
頻度よりも重要なのは規則性である。毎日同じ時刻に収集する。朝から夕方へとずれていくパスは、測定しているイベントの境界そのものを動かしてしまうからだ。
そこから導き出される指標
イベントと同定の仕組みが整えば、出力はシンプルになる。ただしそれぞれに、製品上で明示すべき注意点がある。
新規供給と在庫は、いずれも重複排除の品質に依存する。掲載日数は、再掲載のポリシーを開示した上で使う。エピソードが連結されているかどうかで数値が大きく変わるためだ。価格変更の頻度と深さは、リスティングから得られる最もクリーンなモメンタムの読みである。取り下げ率は有用だが、成約と混同されやすい。売り出し価格指数は取引価格指数ではなく、そのように扱ってはならない。観測値、査定値、売り出し値、推定値の区別はscraping valuations, rents and mortgage dataで示されている。成約価格対売り出し価格比と吸収率は登記簿データを必要とするため遅れて算出される。
二つの公開ルールがフィードの信頼性を保つ。カバレッジ指標を指数の隣に公開し、読者が市場の動きと収集の変化を見分けられるようにすること。そして小さなセルを抑制すること。ある郵便区画の9件のリスティングから算出された中央値は小数点付きのノイズであり、それこそがスクリーンショットされやすい数値である。
鮮度の契約
すべての行にその観測時刻を持たせるべきであり、すべての利用者はテーブルが最新であると信頼するのではなく、自分自身の陳腐化しきい値を適用すべきである。この単一の設計判断こそが、遅延したクロールが静かに「報告された市場の変化」に化けることを防ぐ。これはbuilding a real-time competitive price feedで説明されているのと同じ契約であり、ここでもそのまま適用される。
自社の収集状況もデータと並べて追跡する。ポータルごと、市場ごとの成功率、そして期待される結果数に対する実際の結果数だ。供給が減少したように見えたとき、最初に問うべきは市場が変化したのか、それとも自社のカバレッジが変化したのかということだ。その基準を確立する方法はtesting proxy speed, success rate and location accuracyにある。
FAQ
住宅データはどれくらいリアルタイムになり得るか?
日次パスによる翌日のイベント検出は達成可能であり、ほぼすべての用途に十分である。日中の更新が見合うのは小規模なウォッチリストのみだ。どのように収集しようとも、取引記録は常に数週間から数か月遅れる。
なぜ自社の在庫数がポータル自身の数値を上回るのか?
ほぼ常にポータル間の重複が原因である。3社の仲介業者に掲載された1件の物件は、あくまで1件の物件である。在庫指標を信頼する前にマッチ率を測定すること。
再掲載を新規供給としてカウントすべきか?
ルールを一つ決め、それを文書化し、全履歴にわたって適用する。エピソードを一つの物件に連結する方が誠実であることが多い。実際の市場滞留期間を保持できるからだ。
売り出し価格指数を住宅価格指数として公開してもよいか?
いいえ。売り出し価格は先行し、特に市場の転換点では取引価格から乖離する。それをそのものとして表示すれば、その指数は本当に有用なものになる。
結論
リアルタイムの住宅フィードとは、緩慢な市場の上に構築されたイベントパイプラインである。速度は容易な部分だ。誰かがそれを信頼できるかどうかを左右するのは、物件を安定した同定に解決すること、パネルを固定してカバレッジの変化が市場の動きに偽装されないようにすること、そして到着の遅い取引データに対して売り出し価格シグナルを誠実にラベル付けすることである。
各市場をその市場から収集し、結果セット全体にわたってセッションの整合性を保ち、すべての行に観測時刻を付与し、指数の隣にカバレッジを公開する。製品ビューはdata gathering pipelinesページにあり、料金はpricing pageにある。