房地产团队并不想自建抓取基础设施。他们想知道供应量在哪里上升、价格在哪里被下调、可比房源的报价是多少,以及库存挂牌的时间有多久。数据采集层只是实现这一目标的手段,对许多团队来说,web scraping API 是获取这些数据最直接的方式,无需为浏览器自动化和代理运营专门招人。
关于该收集什么以及收集后如何建模,本博客的其他文章已有论述:估值、租金和抵押贷款数据、实时房产市场数据源,以及跨门户网站聚合房源信息。本文关注的是采集层本身:为什么房产门户网站会促使团队转向使用 API、API 如何映射到房产页面,以及其经济模型如何运作。
为什么房产门户网站难以采集
房产网站有四个特性使其比大多数网站更难处理。
它们是为地图和滚动而设计的,不是为翻页而设计的。 搜索结果通过 JavaScript 在地图移动或列表滚动时加载,因此普通的 HTTP 请求往往只会返回一个空壳。
结果采用分页和游标驱动方式。 从第一页转到第二页通常依赖服务器端状态,这会破坏简单的逐页抓取方式。
它们是本地化的。 门户网站按国家、有时按地区提供服务,因此你看到的内容取决于请求看起来来自哪里。
它们受到防护。 高价值、频繁更新的房源会吸引自动化流量,门户网站因此会相应地加以保护。
要在内部自行处理这四点,意味着需要无头浏览器、代理管理、重试逻辑和指纹调整。而 web scraping API 将这些都打包进一个请求中。
API 如何映射到房产页面
使用 Shifter Web Scraping API 时,每个门户网站的问题都有对应的直接控制方式。
地图和列表视图。 render_js=1 会在无头 Chrome 中运行页面,且不额外收取信用点,wait_for_css 会等待房源卡片实际渲染完成后再进行抓取。JavaScript 指令可以在抓取前滚动页面或点击”加载更多”控件。参见渲染 JavaScript。
结果卡片。 使用列表类型的 extract_rules 可以将页面上的每个房源卡片作为 JSON 返回,一个对象对应一个房源,无需在你这一端使用 HTML 解析器。
分页。 session_id 会在多次请求之间保留 cookie、浏览器状态和上游 IP,因此可以按顺序遍历游标驱动的结果集。会话在闲置 10 分钟后过期,且在会话生命周期内国家应保持不变。参见会话与代理。
本地化。 country 每次请求接受一个 ISO alpha-2 代码。全球地理定位以及通过 premium_proxy=1 使用的住宅代理池,适用于 Growth 及以上套餐。
证据留存。 screenshot=1 会捕获渲染后的页面,当某个房源在特定时间点的状态很重要时(例如降价或撤牌)非常有用。
长时间渲染。 webhook=<URL> 会在响应准备就绪时将其发送到你的端点,而不是一直保持连接打开。
针对某一市场的搜索结果请求大致如下:
curl "https://scrape.shifter.io/v1?api_key=YOUR_API_KEY\
&url=https%3A%2F%2Fportal.example.com%2Fsearch%3Fcity%3Dlyon\
&render_js=1&wait_for_css=.listing-card\
&country=fr&premium_proxy=1&session_id=lyon-walk-03\
&extract_rules=%7B%22listings%22%3A%7B%22selector%22%3A%22.listing-card%22%2C%22type%22%3A%22list%22%2C%22item%22%3A%7B%22price%22%3A%7B%22selector%22%3A%22.price%22%2C%22output%22%3A%22text%22%7D%2C%22area%22%3A%7B%22selector%22%3A%22.area%22%2C%22output%22%3A%22text%22%7D%2C%22link%22%3A%7B%22selector%22%3A%22a%22%2C%22output%22%3A%22%40href%22%7D%7D%7D%7D"目标 URL 经过了 URL 编码,因为它自带查询字符串,否则会被误读为 API 请求的参数。响应是一个包含 listings 数组的 JSON 对象。如果某个字段的选择器找不到内容,会返回 null,这一点对于后文将提到的监控工作很重要。
不同团队如何使用它
收购和投资团队关注目标细分市场中的新增供应和降价情况,并将降价的时间点作为谈判信号。他们所需要的是对特定区域进行次日事件检测,而不是全国性的爬取。
经纪机构按区域追踪自身房源相对于竞争对手的占比,以及竞品房源的成交速度。这应保持在经纪机构层面进行统计:房源中的经纪人联系方式属于个人数据,分析工作通常并不需要这些信息。
PropTech 产品为自己的用户构建可比房源和房源信息流。在这种情况下,API 只是标准化流水线中的一个输入环节,且不同门户网站和国家的字段定义各不相同。
租赁运营商监控其细分市场中的报价租金和优惠条件。优惠条件往往出现在描述文本中而非价格字段里,因此提取规则应捕获描述内容,而不仅仅是标价。
贷款机构和保险公司关注其风险敞口所在区域的市场状况。这里的边界是已公开的市场数据,绝不涉及个别借款人或住户的信息。
经济模型:围绕信用点进行设计
一个信用点购买一次成功的请求,无论该请求返回什么内容。渲染、提取规则、截图以及 API 自身的重试都包含在内,失败的请求或目标错误不予计费。
这对房地产领域有一个直接的设计影响。一个返回四十个房源卡片的搜索结果页面,与一个只返回一个房源的详情页面,消耗的是同样一个信用点。因此高效的做法是:只要卡片包含所需字段(价格、面积、房间数、链接),就优先从结果页面采集数据,只有当某个房源是新增的或其卡片发生变化时才抓取详情页。
对于拥有数千个活跃房源的市场而言,这种差异往往能带来数量级的信用点节省。这也能提升数据的新鲜度,因为在相同支出下你可以更频繁地重新访问结果页面。
还有两个成本杠杆。按与各市场变化速度相匹配的节奏进行刷新,因为对大多数房源展示页面而言,每日更新已经足够。同时留意投入到已成功解析行上的信用点,因为一个失效的选择器仍会为每次成功但无用的响应消耗一个信用点。
监控静默失效问题
门户网站会进行改版,而选择器失效并不会导致请求失败。它只会返回 null,请求依然成功,信用点也照常被消耗。
按字段、按门户网站、按国家,在滚动窗口内追踪空值率,并在其偏离基线时发出告警。对提取规则进行版本管理,以便修复过程可追溯,并在解析之前保存原始响应,这样修正后的规则可以直接重放,而无需再次付费抓取。相关加载模式详见将 web scraping API 数据导入 SQL。
何时该用 API 作为采集层,何时不该
选择 API:当渲染和反爬处理是主要负担时;当团队规模较小或以数据为核心而非以基础设施为核心时;以及当按成功计费的可预测性比尽可能低的单位成本更重要时。
选择自行管理的代理:当你需要完全定制的浏览器流程,或运营规模已经大到自建技术栈更划算,又或者你已经拥有抓取工程师时。基于代理的方案在房产数据的代理应用一文中有详细介绍。
优先选择授权数据源:只要你所在市场存在这样的数据源。其覆盖范围和字段质量通常更好,条款也更清晰。将采集用于授权数据源无法提供的内容。
保持合规
尊重每个门户网站的服务条款,保持请求量的适度性。默认将房主、经纪人和住户的详细信息视为个人数据,在分析不需要这些信息时于摄入阶段将其剥离。将截图作为房源展示内容的证据使用,而非用于再次发布的素材。更广泛的框架参见住宅代理与 GDPR 合规。
常见问题
我需要为房产门户网站启用 JavaScript 渲染吗?
对于大多数现代门户网站来说,是的,因为房源结果是在初始页面加载之后才加载的。它与静态抓取消耗相同的信用点,所以在结果是通过客户端渲染的情况下,没有理由不启用它。
一个 API 能覆盖多个国家的门户网站吗?
可以,每次请求设置 country,并为每个市场使用单独的会话。全球地理定位需要 Growth 及以上套餐。
如何可靠地遍历分页的搜索结果?
每次搜索使用一个 session_id,在其中保持国家不变,并保持遍历持续进行,因为会话在闲置 10 分钟后会过期。
抓取详情页还是结果页更划算?
结果页,只要房源卡片包含你需要的字段。一个信用点可以返回多个房源,详情页可以留给新增或有变化的房源使用。
结论
对大多数房地产团队来说,市场情报工作中真正困难的部分并不在于决定要测量什么。困难在于从那些为地图、滚动浏览和人类访客设计的门户网站中,可靠地获取数据。web scraping API 将渲染、分页、本地化和重试都转化为请求参数,并且只在数据到达时才计费。
围绕信用点进行设计:优先从结果页面采集数据,使用每个市场对应的会话来遍历搜索,通过监控空值率来发现静默失效问题,并在存在授权数据源的地方优先使用它。该产品位于 Web Scraping API 页面,套餐信息见定价页面,更广泛的应用场景见房地产页面。