劳动力市场情报看起来像是一个爬取问题,实际上却是一个测量问题。输出结果是一个时间序列,会有人将其解读为招聘状况的信号,而失败模式并非任务崩溃。它是图表因与劳动力市场毫无关系的原因而发生变动。
如果某地区本月招聘信息下降了百分之十八,有两种解释。雇主发布的职位减少了,或者你的采集遗漏了一些数据。从数据管道内部看,这两者是无法区分的,除非你在构建时就设计了区分方法。这正是构建指数与单纯抓取列表之间的区别,而大多数招聘板面板正是在这里悄悄出错的。
如果你关注的是招聘工作流程而不是总量测量,配套文章是面向招聘和劳动力市场数据的住宅代理。这篇文章讲的是面板。
覆盖缺口看起来像趋势
劳动力市场序列的定义性特征在于,它是与自身在时间上进行比较的。绝对数量远不如变化量重要,这意味着任何你能看到的内容的变化,都会被记录为实际存在事物的变化。
三种情况经常在不改变任何真实事物的前提下改变覆盖范围:
部分封锁。 某个招聘板开始每次查询返回更少的结果,或在结果集较深的页面上出现验证挑战。你仍然能获取数据,所以看起来没有任何问题,而你的计数却在下降。
地理漂移。 你的请求看起来所来源的位置发生了变化,结果集也随之变化。大多数招聘板会按邻近程度筛选招聘信息,因此这直接影响地区计数。
分页静默截断。 你原来能采集八页,现在只采集到三页,因为后面的页面比第一页受到更严密的防护。数量下降了,却没有人注意到消失的是哪些页面。
以上每一种情况都会产生一个干净、看似合理、但错误的数字。它们都不会引发任何错误提示。
招聘信息按位置提供
几乎所有主要招聘板都会根据它认为你所在的位置来解析查询。如果不带位置搜索”仓库助理”,你会得到地区性结果。如果带上位置参数搜索,但请求来源的IP却在千里之外,你得到的结果集既不是本地候选人所看到的,也不是全国性的视角。
对于试图测量地区招聘状况的面板来说,这就是关键所在。位置信号必须在整个序列的历史中保持稳定,并且在声明的位置参数与请求的表观来源之间保持一致。在你所测量的地区使用住宅出口节点可以让这两者相符,这在操作层面上正是”本地视角”的含义。
相关的陷阱是地区设置不匹配,即IP显示一个国家,而浏览器标头显示另一个国家。这种不一致会改变国际招聘板上的结果集,值得尽早消除。详细内容见匹配代理地理位置、时区和语言设置。
先设计面板,再采集数据
使劳动力市场数据可用的关键做法是,在编写采集器之前先确定面板的定义,然后不随意更改它。
固定来源列表。 一组确定的招聘板,保持不变。中途添加一个招聘板会造成一个阶跃变化,除非你回填数据或对序列进行版本标记,否则这会被误读为招聘增长。
固定地理范围。 一组确定的地区,每个地区有明确的位置参数。而不是”请求来自哪里就算哪里”。
固定查询集。 相同的职业查询,以相同的方式,按相同的频率运行。
固定深度。 每次查询规定的结果页数,要完整采集,否则标记为不完整。绝不采用尽力而为的方式。
以上任何一项的变更都是方法论上的变更,应当作为变更加以记录,并在每一行数据上标注版本号。分析人员可以处理序列中有记录的中断。他们无法处理未记录的中断。
配置采集层
使用 Shifter 网关时,地区和会话信息编码在针对 p.shifter.io:443 的凭据中:
customer-USERNAME-country-gb-city-manchester-sid-mcr01-ttl-600:PASSWORDcountry-gb 使用的是 ISO alpha-2 代码,即 gb 而非 uk。city-manchester 将出口节点缩窄到你正在测量的招聘信息所在的都市区。sid-mcr01 保持了一个粘性会话,使整个查询(包括其分页)都从单一IP运行,而 ttl-600 将该IP保留十分钟。为每个地区和查询(而非每个请求)设置一个会话标识符,这正是保持分页结果集内部一致性的关键。
如果某个地区和城市的筛选条件过于狹窄而无法满足,网关会返回502,而不会用附近的出口节点替代。对于一个测量面板来说,这是正确的行为:一个你能看到的缺失观测值,胜过一个你无法察觉的静默替代。
采集节奏应当稳定、不引人注目。每天或每周在固定时间进行采集,配合适度的并发量和真正的错误回退机制,比激进的扫描能产生更清晰的序列,而且更不容易因触发防御机制而改变你的覆盖范围。相关机制详见速率限制与请求节流。
去重是一项测量决策
同一职位通常会出现在多个招聘板上,出现在公司招聘页面上,两周后又作为重新发布的信息再次出现。你如何处理这一点,决定了你的指数实际测量的是什么,而这没有中立的选择。
一种可行的方法是使用标准化雇主名称、标准化职位名称、位置和发布日期窗口组成的复合键,并为每次合并记录一个决策。比具体算法更重要的是,规则要固定、有文档记录,并在整个历史中一致地应用。追溯性地更改去重逻辑会改写过去,而一个不断改变过去的劳动力市场序列根本不是一个序列。
重新发布的信息值得单独处理。每月重新发布的职位,可能是难以填补的空缺,也可能是常青广告,两者都值得关注,但前提是你能将其与新的需求区分开来。
验证覆盖范围,而不是假定它
将可辩护的面板与不可辩护的面板区分开来的唯一做法是:测量你自己的采集过程,而不仅仅是招聘信息本身。
在每个采集窗口内,从同一地区的两个不同出口节点运行一小组对照查询两次,并比较结果计数。结果一致意味着你的视角是稳定的。结果不一致意味着招聘板正在对你请求中的某些特征做出反应,该窗口的序列存在疑问。
将运营指标与数据本身一并追踪:每个招聘板的成功率、实际采集页数与预期页数的对比,以及每次查询随时间变化的结果计数。招聘信息下降百分之二十,若恰好与你自身成功率的下降同时发生,那说明这是一个采集问题,而不是劳动力市场问题,在有人据此构建预测之前,你需要知道自己面对的是哪一种情况。
对于需要在采集层本身建立可辩护基准的团队,测试代理速度、成功率和位置准确性一文涵盖了测量方面的内容。
站在数据使用的正确一边
招聘信息是发布给人们阅读的,这确实是采集它们的一个合理理由,但这并不意味着可以毫无限制。
招聘信息往往包含具名招聘人员、直接电话号码和电子邮箱地址。这属于个人数据,而招聘需求指数并不需要这些信息。在采集入口处就将其剔除,而不是先存储下来再承诺不使用。发布聚合数据,遵守每个招聘板声明的条款,保持请求量的适度,并在招聘板提供研究访问渠道时诚实地标识你的流量。
总体框架见面向AI数据采集的合乎道德的住宅代理,这一原则在此处更加适用,因为劳动力市场工作比大多数商业数据采集更贴近个人。
常见问题
一个可信的全国性面板需要多少个地区?
要多到足以使任何单一都市区不会主导总量,并且从第一次观测起就保持一致。十个精心挑选的地区,以一致的方式采集一年,胜过四十个地区不均匀地采集三个月。
我应该采集薪资字段吗?
应该,并将原始字符串与你解析后的数值一并存储。薪资披露因司法辖区和招聘板而异,因此薪资数据占比上升往往是一种政策变化,而非市场变化,你需要原始文本才能分辨。
为什么不使用带公开API的单一招聘板?
因为单一招聘板的覆盖范围只是那一个招聘板的业务状况,其在招聘信息中的份额会随时间变化。单一来源的序列只测量该来源。这是否可以接受,取决于你所声称的内容。
这种方法适用于国际覆盖吗?
适用,前提是使用与之匹配的按国家出口节点和语言设置。预计在大多数市场中,全国性招聘板会占主导地位,这会改变来源列表而非方法本身。相关内容见招聘用例。
结论
招聘板数据在你能够解释序列中每一次变动(包括你自己的数据管道所造成的那些变动)时,才转变为劳动力市场情报。这需要一个固定的面板、地理上一致的采集方式、稳定的去重规则,以及真实的覆盖率指标。
住宅代理是使地理位置真实且可重复的关键部分,从而使地区数字名副其实。剩下的就是方法论,而方法论正是使这个数字值得引用的原因。针对这种规模面板的带宽规划内容见估算每月住宅代理带宽用量,费率见住宅代理定价页面。