“实时房产数据”听起来像是个延迟问题，但其实不是。房产没有价格跳动。交易是稀疏的、逐单议价的，并且在成交后数周或数月才被记入公共登记簿。市场底层的任何东西都不会以秒为单位变动。
真正快速变动的是房源界面：一套房产出现、价格变化、进入待售状态、被撤下、又重新出现。这些事件每天都在发生，并且远远领先于交易记录。因此，实时房产数据源本质上是一个事件检测系统，其任务是足够快地察觉这个界面上的变化以保证有用，并足够稳定地察觉变化以获得信任。
真正困难的两个问题不是采集速度，而是房产身份识别和稳定的覆盖范围。
将房源生命周期建模为事件
每晚存储一次所有房源的快照，只能告诉你市场上有什么。它不会告诉你发生了什么，而发生了什么才是信号。
从连续的观测中推导出事件，并将其作为独立记录存储：
| 事件 | 为何重要 |
|---|---|
| 新上市 | 新增供给，是整条链中最早的领先指标 |
| 降价或涨价 | 变动的深度和频率是判断本地市场动能最清晰的读数 |
| 状态变更为待售或已附条件售出 | 需求信号，且远早于登记簿 |
| 撤回 | 通常是市场疲软的信号，且容易与成交混淆 |
| 重新上市 | 往往是同一套房产再次出现，这正是数据完整性最容易出错的地方 |
| 已售出，来自公共登记簿 | 权威结果，但到达较晚 |
每个事件都需要开启它的观测记录、结束它的观测记录，以及足够的置信度元数据，以说明这个边界是被实际观测到的，还是仅仅受限于你的采样间隔。如果你每天采集一次，你只知道价格在一天之内变化了，而不知道具体是何时变化的。
房产身份识别是整个系统的核心
同一套房产会出现在多个门户网站上，使用不同的参考编号，地址格式各不相同，有时单元编号在不同的字段中，有时甚至完全缺失。随着时间推移，它可能几个月后又作为一个全新的房源再次出现。
如果身份识别失败，两件事会同时出错。库存被夸大，因为一套房产被算成了三套。上市天数会崩溃，因为一套重新上市的房产看起来像是全新的。
第二点尤其值得注意，因为在某些市场中，通过重新上市来重置上市天数是一种蓄意的做法。如果一个数据源把每次重新上市都当作新增供给来处理，那么它将系统性地低估库存的实际挂牌时长，而恰恰是在这个数字最重要的市场中出现这种低估。
一个可行的身份识别策略，按可靠性排序：在司法辖区提供地块或产权标识符的情况下使用该标识符；其次是标准化地址加单元编号，地理编码到坐标并设定较窄的容差；然后用建筑面积、卧室数量和房产类型的属性匹配来打破平局。将每个门户网站自己的参考编号都关联到你的规范房产记录上，并保留一个上市周期记录，使一套房产可以随时间拥有多个周期而不丢失其历史。
通过人工审查样本来衡量你的匹配率，并公开发布这个数字。一个没有已知去重误差率的库存数字，是任何人都无法评估其规模的数字。
覆盖稳定性胜过覆盖广度
房产指数是作为时间序列来解读的，这意味着你能看到的范围发生任何变化，都会被记录为市场发生了变化。
在系列采集期间新增一个门户网站，供给量看起来会跳升。因被封锁而失去一个门户网站，供给量看起来会下降。开始采集更深的页面，库存量会上升。这些都不是房产市场本身的变化，但看起来却完全像是。
因此在开始之前就要固定好采集面板：明确的门户网站集合、明确的地理范围、明确的查询集合，以及每次查询明确的深度，每次都要完整采集或明确标记为不完整。为面板设定版本号，在每一行数据上都标注版本，并将对面板的任何改动都视为需要记录的方法论断点，而不是一次悄无声息的改进。
这与管理任何纵向网络面板所需的纪律是一样的，更完整的论述见于招聘网站数据与劳动力市场情报一文，可以直接套用于此处。
地理位置是观测的一部分
门户网站会做本地化处理。搜索结果、展示的房产，有时甚至展示的字段，都取决于请求看起来来自哪里，而服务多个国家的门户网站甚至可能返回完全不同的站点。
对于一个报告区域市场的数据源来说，采集必须来自它所报告的那些区域。使用 Shifter 网关时，落地点和会话信息写在针对 p.shifter.io:443 的凭据中：
customer-USERNAME-country-gb-city-manchester-sid-feed-mcr-04-ttl-600:PASSWORDcountry-gb 使用 ISO alpha-2 代码，city-manchester 将范围缩小到该市场，sid-feed-mcr-04 在一次完整搜索（包括其分页）中固定一个出口，使结果集在内部保持一致，ttl-600 将该地址保留十分钟。每次查询使用一个会话而不是每次请求使用一个会话，这正是防止第四页与第一页属于不同落地点的关键。
保持本地化信号与出口一致，因为不匹配会改变某些门户网站返回的内容；这一点在匹配代理地理位置、时区与语言环境一文中有详述。保持请求速率正常并配合真实的退避策略，如速率限制与请求节流一文所述。
按系列而非统一设置采集节奏
每日采集对房源界面上几乎所有内容都已足够，因为房源不会每小时变化，每日一次采集就能实现次日的事件检测。
有两种情况值得更快采集：一个热门市场中的小型关注列表，其中待售状态在数小时内就会变化；以及新建楼盘发布的窗口期。公共登记簿数据按其自身节奏更新，采集频率超过其发布频率只会产生重复数据。
比频率更重要的是规律性。每天在同一时间采集，因为一次从早上漂移到晚上的采集会移动你正在测量的事件边界。
由此得出的指标
有了事件和身份识别机制后，输出结果就变得直接明了，但每一项都需要在产品中标注其注意事项。
新增供给和库存量，两者都取决于去重质量。上市天数，需公开重新上市的处理政策，因为这个数字是否按周期链接会带来实质性差异。价格变动频率和幅度，这是从房源数据中能获得的最清晰的动能读数。撤回率，有用但容易与成交混淆。要价指数，这不是成交价指数，绝不应被标注成好像是成交价指数一样。已观测、已评估、要价与预估这几类数字之间的区别，在抓取估价、租金与房贷数据一文中有详细说明。挂牌成交比和去化率，这些需要登记簿数据，因此会有滞后。
有两条发布规则能保持数据源的可信度。将覆盖率指标与指数并列发布，让读者能够分辨这是市场变动还是采集变动。并抑制小样本单元：在一个邮编区域内基于九套房源计算出的中位数，只是带小数点的噪音，而它恰恰是最容易被截图传播的数字。
新鲜度约定
每一行数据都应携带其观测时间，每个使用者都应应用自己的过期阈值，而不是想当然地认为表格是最新的。正是这一个设计决定，阻止了一次延迟的爬取悄悄变成一次被报告的市场变化。这与构建实时竞争性价格数据源一文所描述的约定相同，并且在此处同样适用。
将你自己的采集情况与数据一起跟踪：每个门户网站在每个市场中的成功率，以及实际返回结果与预期结果的对比。当供给量看似下降时，第一个问题应该是市场变了，还是你的覆盖范围变了。建立这一基线的方法见于测试代理速度、成功率与位置准确性一文。
常见问题
房产数据到底能有多”实时”？
通过每日采集实现次日事件检测是可行的，并且对几乎所有用途都已足够。只有对一个小型关注列表来说，日内实时才值得投入。无论你如何采集，交易记录始终会滞后数周或数月。
为什么我们的库存计数超过了门户网站自己公布的数字？
几乎总是因为跨门户网站的重复计算。一套房产被三个中介同时挂牌，仍然只是一套房产。在信任任何库存数字之前，先衡量你的匹配率。
重新上市应该算作新增供给吗？
选定一条规则，将其记录下来，并在整个历史记录中一致应用。将各个周期链接到同一套房产通常更诚实，因为这样能保留真实的上市时长。
我们能把要价指数当作房价指数发布吗？
不能。要价领先于成交价并且会与之背离，尤其是在市场转折时。如实标注它的性质，这个指数才是真正有用的。
总结
实时房产数据源本质上是覆盖在一个缓慢市场之上的事件管道。速度是容易解决的部分。真正决定它是否可靠的，是将房产解析为稳定的身份、固定采集面板使覆盖范围的变化不会伪装成市场变动，以及将要价信号与延迟到达的成交数据诚实地区分标注。
从每个市场各自采集数据，在一次结果集中保持会话的一致性，为每一行数据附上观测时间，并将你的覆盖率与你的指数并列发布。产品视图见于数据采集管道页面，价格见于定价页面。