裁员通常被报道为一个单一的头条新闻。但实际上，它是以一连串公开信号的形式展开的：招聘放缓、职位空缺消失、监管通知被提交、公司发布声明，几个月后生效日期才到来。善于追踪员工变动的团队不会等待头条新闻的出现。他们会关注整个序列，并将其组装成可以信赖的事件。
本指南将介绍这些信号的来源、如何将它们转化为可靠的事件数据流，以及使这项工作聚焦于公司而非个人的边界所在。从公开数据衡量劳动力市场这一更广泛的实践，可参见招聘网站数据与劳动力市场情报。
谁需要这些数据，以及为什么”实时”很重要
招聘团队使用裁员数据，是为了在有经验的候选人刚可获得的那一周找到他们。市场情报团队将其解读为关于某个竞争对手或某个行业的信号。投资者、供应商和贷款方则将其视为麻烦的早期指标。对他们所有人来说，这些数据的价值都会迅速衰减：一个月后才得知的员工变动只是历史，而非情报。
信号强度，从强到弱
| 信号 | 它告诉你什么 | 强度 |
|---|---|---|
| 政府裁员通知 | 公司、地点、员工人数、生效日期 | 在已发布的地方为强 |
| 上市公司文件 | 重组及相关成本 | 对上市公司为强 |
| 公司声明 | 范围与理由，按公司自己的表述 | 强但有选择性 |
| 可信新闻报道 | 早期报道，有时早于任何通知 | 中等，需要佐证 |
| 职位发布撤下 | 职位空缺被撤下，招聘冻结 | 领先但嘈杂 |
| 招聘页面与办公室变动 | 团队、地点或职位被移除 | 辅助性 |
| 社区维护的裁员追踪器 | 众包整理的事件列表 | 有助于发现，需要核实 |
政府通知
在美国，联邦 WARN 规则要求拥有 100 名或以上员工的雇主在工厂关闭和大规模裁员前提前 60 天发出通知。多个州有自己的规则，门槛更低或通知期更长，许多州会公布收到的通知。这些通知是现有最强的单一来源：它们标明了雇主、地点、受影响员工人数和生效日期。
它们也以各种可以想象的格式出现。有些州发布 HTML 表格，有些是电子表格，有些是扫描版 PDF，还有些会毫无预警地改变版式。数据采集必须能处理所有这些格式，并检测来源何时发生了结构变化。
在美国以外，向当局提交的集体裁员通知往往不会公开发布，因此其他信号的权重更大。
文件与声明
上市公司经常在公开文件中披露重组计划及其成本。公司声明给出范围与理由，尽管是按公司自己选择的方式来表述的。两者对于它们所陈述的内容是权威的，但对于它们未提及的内容则保持沉默。
招聘信号
最早的信号通常是招聘方面的变化。职位空缺消失的速度快于平常，整个团队的职位发布同时被撤下，或者一家通常持续发布职位的公司突然安静下来。职位发布本身是嘈杂的，因为职位会被填补或重组，因此应将招聘下降视为需要进一步查看的理由，而非直接当作事件。持续采集职位发布以便发现变化的方法，参见招聘网站数据与劳动力市场情报，招聘作为购买信号的内容参见抓取意向信号以支持销售情报。
构建事件模型，而非文章列表
核心设计决策是追踪由多个观察结果组装而成的员工变动事件，而不是将每篇文章和每条通知单独存储。
一条有用的事件记录应包括：
- 公司，解析为规范化实体，使子公司和品牌名称能正确归并
- 事件类型：裁员、办公室关闭、招聘冻结、重组
- 受影响地点
- 员工人数，附带来源，因为声明与通知之间的数字往往不同
- 关键日期：首次信号出现日期、宣布日期、通知提交日期、生效日期
- 来源，每个来源附带其置信等级和被观察到的日期
- 状态：传闻中、已报道、已确认
当一篇新闻报道、一份 WARN 通知和一份公司声明描述的是同一次裁员时，它们应该更新同一个事件，而不是创建三个事件。基于公司、地点和日期窗口进行匹配可以捕获大多数重复项，其余的需要人工审查。公司身份解析的运作方式与构建人才地图和组织架构数据中描述的相同。
置信度，而非确定性
不同的来源会有分歧，早期报道在规模上往往有误。为每个事件设定一个随证据到来而变化的状态。
- 传闻中：单一低置信度来源，例如社区帖子。
- 已报道：可信新闻，或有佐证的强招聘信号。
- 已确认：政府通知、公司文件或官方声明。
向数据流的使用者展示该状态。招聘团队可以基于”已报道”的事件采取行动；而向管理层的报告通常应等到”已确认”。
跟上节奏的数据采集
每种来源类型都需要有自己的采集节奏。
| 来源 | 节奏 |
|---|---|
| 州通知页面 | 每日，附带变化检测 |
| 公司文件 | 一经发布即采集 |
| 新闻 | 持续或每日多次 |
| 职位发布 | 对被关注公司每日采集 |
| 招聘页面 | 每周，附带变化检测 |
新闻网站和招聘网站最有可能进行速率限制、地域过滤或提供区域版本，因此应从对应的区域采集该区域的内容。使用 Shifter 网关时，将市场信息放入针对 p.shifter.io:443 的凭据中，保持会话有助于让分页列表保持一致：
customer-USERNAME-country-us-sid-warn-watch-12-ttl-600:PASSWORD保持请求频率正常，出错时进行退避，具体内容参见速率限制与请求节流。在解析之前存储原始响应，这样当通知页面改变格式时可以重新解析而无需重新采集；相关模式参见将网页抓取 API 数据导入 SQL。
追踪公司，而非个人
裁员数据与个人紧密相关，因此边界应当明确。
采集公司层面的事实：谁、在哪里、多少人、什么时候。不要根据社交媒体帖子建立受影响员工的具名列表，也不要存储通知或文章中出现的个人详细信息，除非你的用途确实需要，并且你有合法依据。如果招聘团队想要联系受影响的人员，应通过这些人自己选择的渠道进行，例如他们自己发布的招聘网站和”open-to-work”信号，而不是通过为他们编制的名单。
在角色和组织层面而非个人层面运作的同一原则，见于构建人才地图和组织架构数据。法律层面的说明见于住宅代理与 GDPR 合规。
衡量数据流
| 指标 | 它告诉你什么 |
|---|---|
| 提前量 | 数据流相较于确认时间提前多久检测到事件 |
| 确认率 | 已报道事件后来被确认的比例 |
| 重复率 | 不同来源的事件是否被正确合并 |
| 按辖区划分的覆盖率 | 数据流在哪些地方强、在哪些地方依赖较弱的信号 |
| 来源新鲜度 | 是否有来源停止更新或改变了格式 |
常见问题
裁员数据最可靠的来源是什么？
在美国，是各州公布的 WARN 通知。在其他地方，是公司文件和官方声明，辅以新闻报道。
招聘数据能预测裁员吗？
它可以提前发出警示。职位空缺的突然撤下是一个有用的信号，但它也可能有无害的解释，因此应将其视为需要调查的提示，而非直接视为事件。
我们如何避免对同一次裁员重复计数？
对事件建模，而非对文章建模。在创建任何新内容之前，先根据公司、地点和日期窗口，将新的观察结果与现有事件进行匹配。
追踪受影响的员工是否合适？
将数据流保持在公司层面。希望被找到的个人通常会在他们自己选择的平台上表明这一点。
结论
裁员是一个序列，而非一条头条新闻。追踪整个序列：最先出现的招聘信号，随后确认的通知与文件，以及描述情况的声明与新闻。将它们组装成附带状态、置信等级和来源的事件，按各自的节奏采集每个来源，并将工作保持在公司层面。
产品视角参见招聘与人才数据页面，相关的雇主声誉指南见如何监测各网站上的雇主评价与评分。