为房地产科技平台抓取估值、租金和抵押贷款数据

PropTech团队常常把他们的数据需求笼统地称为”房产数据”，仿佛估值、租金和抵押贷款利率只是一张表里的三列。它们其实是三个不同的问题。它们来自不同的来源，带有不同的许可和隐私限制，最重要的是，它们代表的含义各不相同。

由于把它们当作同一个数据集处理而产生的失败，并不是采集环节的失败。它们是标注环节的失败，而且往往要到很久之后才会暴露出来，也就是当用户对你的产品呈现为”事实”的某个数字提出质疑的时候。

三种数据类型，三种数据来源现实

在着手编写采集器之前，先明确你实际获取的是哪一种数据，因为答案将决定采集方法本身，也决定你可以对外做出什么样的声明。

数据类型	权威来源	网络能提供什么	它不是什么
成交价格	公共记录：土地登记处、契约、估价名册	成交价格、过户日期、地块属性	不是当前市场价值
评估价值	税务估价名册	用于征税的评估值	不是市场估值
门户网站估值	门户自身的模型	专有模型的输出结果	不是评估报告，不是事实
挂牌租金	在售/在租房源	房东今天要价多少	不是租客实际支付的金额
实际成交租金	授权数据集、运营商数据	很少公开	无法从房源数据推导得出
抵押贷款利率	放贷机构利率页面、官方统计系列	按产品和档位公布的利率	不是某个具体借款人拿到的利率

在PropTech数据领域最有用的一项原则，就是把”实际观测值（observed）”、“评估值（assessed）”、“要价（asked）“和”估算值（estimated）“分别存放在不同的列中，绝不让它们合并塌缩成一个叫做value的字段。

从本应使用的来源开始

按以下顺序逐层向下推进，只有在上层确实无法覆盖时，才使用下一层。

首先是官方和批量数据来源。 土地登记处、估价机构和统计机构经常发布批量文件或API接口。它们是权威的、被允许使用的，并且带有你无法从外部重建的历史数据。对于成交价格和地块属性来说，这通常就是全部答案。

其次是授权数据源。 经纪人和多重挂牌数据通常可以通过许可获得。当你的产品需要完整的房源覆盖以及可靠的字段时，购买许可证比起替代方案所带来的工程和法律风险要便宜得多。

最后才是公开网络观测，用于弥补前两层无法提供的内容：挂牌租金及其优惠条件、实时库存、公布的放贷机构利率表，以及这些数据在不同市场之间的差异。

直接跳到最底层，是这一领域最常见也最昂贵的错误。房源方面的相关工作在面向房地产数据的代理一文中有所涉及。

估值：永远不要把模型输出当作实测数据呈现

门户网站的估值是基于你看不到的数据训练出的模型输出结果，其误差分布门户网站可能公开也可能不公开。它们可以作为你自己模型的一个特征来使用，但它们不是估值本身。

有三条规则可以让这一做法站得住脚。存储估值时要连同其来源和观测日期一起保存，不能只存一个裸数字。不要给它重新贴标签：估算值就是估算值，不是”市场价值”。如果你自己的产品生成了一个估值，请同时公布一个置信区间，因为一个没有置信区间的点估计会被解读为你并不具备的精确度。

对于任何接近正式估值的场景，采集到的数据只是专业流程的一项输入，而不能替代这个流程本身。

租金：要价不等于成交价，优惠条件藏在文字里

房源上的租金是要价租金。在疲软的市场中，它们往往高于租客实际支付的金额，而这中间的差距正是各种优惠条件所在：免一个月租金、减免手续费、附带停车位、以不同价格签订更短的租期。

这些优惠条件通常出现在自由文本描述中，而不是结构化字段里，这意味着仅凭租金字段构建的要价租金序列，恰恰会在人们最想衡量的市场条件下系统性地出错。要解析描述文本以提取优惠信息，并将其存储为独立字段，哪怕你能提取到的只是一个标记和原始句子。

还有两点实用建议。将数据归一化为可比较的单位，通常是按周期和卧室数量或按建筑面积计算的租金，因为混合户型的中位数所衡量的更多是户型结构而非市场本身。还要把单套房源和整栋楼的观测数据分开存放，因为一栋楼里挂出一套房源，不代表整栋楼都以这个价格出租。

抵押贷款数据：利率是一个矩阵，不是单一数字

放贷机构公布的利率会因产品、期限、贷款价值比（LTV）档位、借款人等级、地区乃至渠道的不同而有所差异。一个只从放贷机构页面存储”利率”的爬虫，只捕捉到了矩阵中的一个单元格，而丢弃了所有的维度轴。

要记录产品类型、期限、LTV档位、任何注明的借款人条件、点数或费用、该数字是名义利率还是年化百分率（APR）、放贷机构注明的生效日期，以及你观测到该数据的日期。名义利率与APR之间的区别是造成下游混淆最多的一点，因为二者不可直接比较，却常常出现在同一个页面上。

来自央行和住房机构的官方统计系列，是用来核对你采集数据的基准真值。当你采集到的平均值与已发布的统计系列出现偏差时，通常是采集环节出了问题。

有一条边界是不容商榷的：只采集已公布的利率和条款，绝不采集借款人层面的数据。个人申请信息、信用档案和个人财务细节不属于公开网络数据，PropTech的产品规划中没有任何理由可以证明去获取这些数据是正当的。

采集层面

这些数据源有两个特性，使得观测点本身成为方法论的一部分。

放贷机构的利率表和门户网站内容都是按地区划分的，因此你看到的利率或房源取决于请求看起来是从哪里发出的。而利率尤其会在同一个国家内部因州或地区不同而有差异，这意味着单一的全国性观测点会在不知不觉中把某一个地区的利率报告成整个市场的利率。

使用Shifter网关时，观测点和会话信息会写入针对p.shifter.io:443的凭据中：

customer-USERNAME-country-us-state-tx-sid-rates-tx-11-ttl-600:PASSWORD

country-us和state-tx将请求定位到你所读取利率所属的市场，sid-rates-tx-11在完整的利率表遍历过程中固定使用同一个出口，使快照中的每个单元格都来自同一个会话，而ttl-600则将该地址保持10分钟。ttl只有配合sid使用才有意义；如果没有会话标识符，网关会按请求轮换，这对独立查询是合适的，但对分页表格来说就不对了。这一权衡在粘性代理与轮换住宅代理对比中有详细说明。

当精确的地区匹配比获得响应本身更重要时，添加strict-true，这样网关会返回502错误，而不是悄悄地给你返回一个邻近地区的数据。

采集频率应当跟随每个数据系列实际变化的速度。放贷机构利率值得每天甚至日内多次采集。房源和挂牌租金则按天采集。公共记录按自己的节奏更新，通常是每周或每月一次，采集频率超过其发布频率只会产生重复的行。保持请求速率的正常水平，并配合真实的退避机制，正如速率限制与请求节流一文所述。

让你保持诚实的数据模式

每条记录除了数字本身之外，还应携带：上表中的观测类型、来源、来源方注明的生效日期、你的观测日期、市场以及你观测所用的出口位置，还有一个置信度或验证标记。

生效日期和观测日期是两个不同的字段，把它们混为一谈是一个真实存在的问题。一份上周二生效的利率表，今天才被采集到，那它就是一个”星期二的利率”。一个基于观测日期构建的指数，会显示出一次实际上并未发生的变动，只是因为你的爬虫延迟了而已。

关于记录观测发生的地点和时间的一般性论证，见关于建立观测点标准的论证。

隐私与合规

房产数据比大多数商业网络数据更接近个人隐私，而相关规则因司法管辖区不同而差异悬殊。

在一些国家，公共记录会标明业主姓名；而在另一些国家，这类信息受到限制。默认将业主姓名、联系方式以及任何能够识别住户身份的信息视为个人数据，只有在你具备合法依据的情况下才采集这些信息，并在你的产品不需要它们时于数据摄取环节就将其剥离。一个租金指数并不需要租客的姓名。

尊重每个数据源的使用条款，将采集量控制在合理范围内，如果许可证是预期的合法途径，就去获取许可证。总体框架见住宅代理与GDPR合规和面向AI数据采集的合乎道德的住宅代理。

常见问题

我可以把门户网站的估值当作我产品中的估值使用吗？

不能当作估值使用。可以作为一个特征，或者作为明确标注来源的第三方估算值来使用，前提是遵守门户网站的使用条款。标注方式才是关键所在。

我要如何获取实际成交租金而不是挂牌租金？

一般通过授权数据集或运营商合作获得。房源数据中不包含这些信息，从挂牌租金推断实际成交租金属于建模行为，应当明确标注为建模结果。

如果已经存在批量文件，是否还有必要抓取公共记录？

不必要，而且批量文件更好：权威、完整且被允许使用。只在批量数据未公布的内容上才使用网络采集。

为什么我们的抵押贷款利率与公布的全国平均值不一致？

通常是因为你采集的只是某一个地区、某一个LTV档位或某一个借款人等级的数据，却对一个不具代表性的混合样本取了平均值。记录好各个维度轴，分歧通常就能自行得到解释。

结论

估值、租金和抵押贷款利率是三个共享一套词汇、却毫无其他共同点的采集问题。那些能够构建出可靠PropTech数据的团队，会优先使用官方和授权数据源，把公开网络用于弥补剩余部分，并将”实际观测值”、“评估值”、“要价”和”估算值”作为独立标注的字段分别存放，同时保留生效日期和观测日期两者。

从相应的市场采集相应的数据，在一张表或一个结果集内保持会话的一致性，绝不把模型输出当作事实存储。将这些观测数据转化为实时市场数据系列的做法，参见构建实时住房市场数据流。产品层面的介绍见用于数据采集的住宅代理页面，价格信息见定价页面。