从一个门户网站收集房源信息是一个爬取问题,而且是一个已经被充分理解的问题。从十几个国家的三十个门户网站收集房源信息,并将结果呈现为一个可搜索的库存清单,则完全是另一回事,而且困难几乎都不在于抓取本身。
问题在于,描述同一套公寓的两个门户网站,对其面积、房间数、价格,甚至属于哪种物业类型都会有分歧,而且它们各自按照自己当地的惯例都是”对的”。
如果你还在搭建采集环节本身,房地产数据代理一文涵盖了这方面的内容。本指南讨论的是数据到手之后会发生什么。
那些名不副实的字段
五大类问题导致了大多数跨门户网站聚合失败。
面积。 平方米、平方英尺,某些市场还有当地单位。更糟的是,计量基准本身就不同:建筑总面积、套内面积,以及某些国家法定的测量标准,会排除或折算掉物业的某些部分。单位换算很简单,但基准的调和却不简单,直接换算会在不知不觉中把不同基准混在一起。
房间数。 在欧洲大陆的大部分地区,标题里的数字统计的是房间数,包括客厅,而不是卧室数。“3 pièces”和”3 bedroom”并不是同一种物业。把两者都存进同一个bedrooms列,会得到一份表面正确、实则错误的库存清单,而这种错误只有在有人跨市场比较时才会暴露出来。
价格含义。 要价、指导价、“高于此价接受报价”(offers over)、拍卖底价、面议价,以及在租赁市场中,该数字是否包含服务费、水电费或当地税费。这些是套着相同货币符号的不同数量。
产权与所有权类型。 永久产权(freehold)、有剩余年限的租赁产权(leasehold)、分层地契(strata)或公寓产权(condominium)安排、合作社所有权。剩余年限很短的租赁产权,与同价位的永久产权,实质上是完全不同的资产。
物业类型分类体系。 每个门户网站都有自己的一套,而且彼此之间无法完美对应。将复式住宅(maisonette)、双层公寓(duplex)和带内部楼梯的公寓归为一类还是三类,是一个只需要做一次、然后在所有地方统一执行的产品决策。
保持可管理性的原则是:始终原样保存来源的原始数值,与你的标准化数值并列存储。 当你日后发现某个门户网站的面积计量基准与你原先假设的不同时,原始字段能让你重新推导。没有它们,你就只能重新采集,而历史数据就此彻底丢失。
在接入第二个门户网站之前先建好标准模型
顺序很重要。先接入第一个门户网站,然后把第二个门户网站硬塞进它的模式里的团队,最终得到的”标准模型”其实只是换了个名字的第一个门户网站的模型,后续每一次接入都会与之冲突。
一个可行的标准记录应把三层分开:
| 层级 | 内容 | 为何要分开 |
|---|---|---|
| 原始层 | 来源发布的原样字段,加上抓取元数据 | 让你能在假设改变时重新推导 |
| 标准化层 | 你自己的单位、你自己的分类体系、你自己的价格含义,并记录转换规则 | 产品实际查询的内容 |
| 派生层 | 单位面积价格、计算出的指数、评分 | 可重新计算,永远不作为权威数据来源 |
每个标准化字段都应附带说明它是由哪条规则产生的。当客户询问为什么某个物业在你的平台上显示68平方米,而在门户网站上显示73平方米时,答案应该是一次查询,而不是一次调查。
货币:切勿只存储换算后的数值
对于跨国库存清单,要存储发布时的原始金额及其货币代码,以及你所使用的汇率和该汇率对应的日期。
只存储换算后的数字会不可逆地丢失信息。汇率会变动,也会有更正发布,而查看历史房源的客户想要的是当时的要价,而不是按今天的汇率重新表达的价格。要么在查询时从存储的原始值实时换算,要么将换算结果连同其对应日期的汇率一并存储,以便日后审核和重算。
从多个门户网站中识别同一物业
同一套物业经常会出现在多个门户网站上,由不同的经纪人发布,配有不同的照片、不同的描述,有时甚至价格也不同。身份识别正是把这些信息合并成一条记录的机制,构建实时住房市场数据源一文对此有深入介绍,因为同样的机制也驱动着那里的库存计数。
聚合环节所特有的问题是:一旦重复项被归组之后,该如何决定哪个数值胜出。
按字段而不是按门户网站来定义来源优先级。某个门户网站可能面积数据最可靠,另一个可能照片质量更好,第三个可能价格更新最快。单一的全局排名会把这些差异全部抹掉。
然后明确地处理分歧。当归组后的房源在价格上的分歧超过容忍范围时,这是一个信号,而不是一个错误:它可能意味着某个经纪人还没有反映价格变动,也可能意味着归组出了错。应该标记出来,展示出价格区间,并保留所有关联的备选项。默默地选一个而丢弃其余的,正是聚合平台失去信任的原因。
一般的匹配规则,包括如何衡量并公布你的匹配率,与竞品品类和目录缺口分析一文所述的方法相同。
覆盖范围是按国家划分的,而非全球统一的
不存在一个全球统一的房地产市场,也不存在一套全球统一的门户网站集合。每个国家都有自己的主流门户网站、自己的经纪人行为方式,以及自己关于哪些信息会被公开发布的惯例。在某些市场,相当一部分交易根本不会出现在任何公开门户网站上。
因此,应把全球库存清单视为多个国家面板的并集,每个面板都有自己明确定义的门户网站集合,并按市场而非汇总地记录覆盖范围。一个跨国家汇总的头条数字,会掩盖你在某个市场只有一个门户网站、而在另一个市场有六个门户网站的事实。
两条实用规则。除非覆盖范围具有可比性,否则不要跨市场比较绝对库存数量,否则你衡量的其实只是你自己的面板。而且,只要某个市场存在授权数据源,就采用授权数据:其覆盖范围和字段质量通常远优于公开采集,法律层面也更简单。
采集层
门户网站的本地化程度很高。你所看到的内容、显示的货币、语言,有时甚至网站本身,都取决于请求看起来来自哪里。一个从单一出口点采集的跨国聚合系统,会悄无声息地只获得某几个市场中某一国的视角。
使用Shifter网关时,市场和会话信息写在凭证中,针对p.shifter.io:443:
customer-USERNAME-country-fr-sid-listings-fr-12-ttl-600:PASSWORDcountry-fr使用ISO alpha-2代码,sid-listings-fr-12让一次完整搜索(包括翻页)保持同一个出口IP,从而使结果集内部保持一致,ttl-600则将该地址保留十分钟。如果不使用sid,网关会按请求轮换IP,这对独立查询是正确的,但对分页搜索则是错误的。
保持语言区域信号与出口IP一致,因为不一致会改变某些门户网站返回的内容;同时保持请求频率正常并配合真实的退避策略,参见速率限制与请求节流。将每个门户网站在每个市场的采集成功率与房源数据一起追踪记录,因为一个悄悄开始返回更少结果的门户网站,看起来与一个供应减少的市场毫无二致。
字段完整性是一项质量指标,而非细枝末节
不同门户网站在填写可选字段方面的完整程度差异极大。一个把缺失字段视为”不存在”而非”未公布”的聚合系统,可能会报告说,例如,某个市场几乎没有带能效等级的物业,而实际上只是某个门户网站根本不公开这项信息。
按门户网站、按字段对完整性进行评分,内部公布这些评分,并在选择来源优先级时加以使用。这也能告诉你,在哪些地方引入授权数据源才能真正改善产品,而不只是徒增成本。
常见问题
我应该在数据接入时进行标准化,还是在查询时进行?
在数据接入时就进行标准化,并保留原始字段。查询时才标准化会更慢,也会让索引建立变得麻烦,但如果没有原始数值,你就无法追溯修正一条有问题的规则。
如何处理那些公布房间数而非卧室数的门户网站?
将两个概念作为独立字段存储,来源提供什么就填什么。不要从房间数推断卧室数,也不要让产品筛选功能去查询一个只在部分市场才有数据的字段。
在各国之间使用统一的标准物业类型分类体系现实吗?
浅层次的分类体系是现实的。让顶层分类保持精简且可移植,把当地特有的细分类别放进一个次级字段,而不是硬塞进主分类体系里。
最值得优先修复的是什么?
面积基准和价格含义。它们影响每一个派生指标,而其中的错误在没人跨市场比较之前都是隐形的。
结论
跨门户网站聚合本质上是一个披着爬取问题外衣的标准化问题。抓取环节其实早已被解决。
在接入第二个门户网站之前先建好标准模型,永久保留来源的原始数值,存储原始货币金额并附带日期化的汇率,按字段而非按门户网站设定来源优先级,把分歧当作信号而不是错误来处理,并按市场而非笼统地记录覆盖范围,因为不存在一个全球统一的面板。产品视图详见大规模数据采集页面,价格详见定价页面。