# 如何用重复职位快照衡量招聘趋势

要在不把重新发布计为增长的情况下衡量招聘趋势，请保持搜索范围固定，将不同的来源职位 ID 与重复观察分开计数，并在解读趋势之前标出失败或达到上限的采集日。一条职位发布是广告，不是已完成的录用，也不是整个劳动力市场。一次采集运行使用 actor（一种托管的数据程序）和 task（一种已保存的输入预设）。

## 采集设置

打开 [Indeed Jobs Scraper Actor](https://apify.com/chronometrica/indeed-jobs-scraper) 和 [Indeed Job Market Data Task](https://apify.com/chronometrica/indeed-jobs-scraper/examples/indeed-job-market-data-weekly-hiring-trends)。当前预设使用五条查询、美国来源、最近七天、最大条目五百、最大页数十五、按日期排序，并且仅保存唯一条目为 true。先用一条查询和较小的限制做一次试点。最大条目数是共享的。国家、查询和批次是输入证据，不是承诺会出现的行字段。保留 jobId、jobUrl、title、companyName、locationRaw、postedAt、postedAtRaw 和 scrapedAt。缺失的 ID 在不同 ID 计数之外保持未解决。单次运行内的唯一性不会对跨天的观察去重。检查输出中的已保存行、重复项、筛选条件和停止证据。当前对照检查的是来源数据结构，不是多日趋势基准。保留失败日的未知状态，以及达到上限日的受限状态。

该 task 使用已保存的输入值：`country` 设为 `us`，`searchTerm` 包含五条查询，`postedWithinDays` 设为 `7`，`maxItems` 设为 `500`，`maxPagesPerSearch` 设为 `15`，`sortBy` 设为 `date`，`saveOnlyUniqueItems` 设为 `true`。试点将 `searchTerm` 替换为一条查询，并设置较小的行数和页数限制。`maxItems` 限制在各关键词之间共享。当前的两行、一批次对照检查的是来源数据结构，不是实际的多日趋势。

## 采集面板方法

1. 定义一个采集面板。使用相同的职位角色查询、来源国家、网站、地点、筛选条件、排序策略、行数或页数上限，以及计划中的检查时间。如果你改变问题，请开始一个新的比较面板，或标出范围变化。不要在不标明的情况下延长旧序列。
2. 保存一份运行清单。记录批次 ID、计划时间、实际时间、输入值、运行结果、已保存行数、停止状态和警告。缺失或失败的采集日保持为缺失，而不是零。
3. 按批次、来源和职位 ID 为观察建立键。在每个已接受的批次内，每条来源职位只计一次。跨批次时，保留每一次观察，并更新首次见到职位表。不要自动把标题相同的职位计为同一条。
4. 报告原始返回行数、该批次中观察到的不同职位、在该面板中首次见到的 ID、此前见过的 ID，以及来源限制或采集限制。今天首次见到，是指你的流程首次采集到，不一定是雇主首次发布。
5. 只比较能支持你的问题的范围和采集状态。达到上限的样本可以显示供复查的新 ID，但不能确立总体职位存量的增长或下降。失败日不能当作市场偏低的日子来使用。
6. 在数字旁边用缺失或受限标记显示序列。保留一张说明表，使分母和单位清楚。不要把折线跨过一个未知日连接起来，仿佛你测量过那一天。
7. 陈述范围有限的结果。说明这个固定的观察面板发现了什么，以及哪些比较仍然未知。如果你需要更广的招聘结论，请采集更广的样本，或使用提供劳动力市场信息的官方来源。
8. 交付每日面板表、首次见到台账和覆盖情况说明。这个结果支持进一步的来源检查和一致的抽样。它不衡量已完成的录用或雇主意图。

## 虚构示例与已核对的计数

本节中的所有职位、时间和结果都是编造的。一个固定面板使用一条分析师职位查询、一个来源国家、相同的筛选策略，以及计划在 12:00 UTC 进行的每日检查。

- 第 1 天已接受的小型源测试集有四条不同职位：J1、J2、J3 和 J4。首次见到为四。此前见过为零。
- 第 2 天已接受的集合有四条不同职位：J2、J3、J4 和 J5。首次见到为一，即 J5。此前见过为三。每日总数相同，并不表示没有新的来源 ID。
- 第 3 天采集失败。没有已接受的集合。观察到的计数和首次见到计数是未知的，不是零。保留第 2 天最后一份已接受台账。
- 第 4 天已接受的集合有四条不同职位：J3、J4、J5 和 J6。首次见到为一，即 J6。此前见过为三。J6 在第 4 天首次被观察到，但它可能在缺失的第 3 天已经出现。不要把它的创建时间归到第 4 天。
- 第 5 天达到上限的受限集合有两条不同的已保存条目：J4 和 J7，因为达到了上限二。首次见到为一，即 J7。此前见过为一。其较低的计数是由变更后正在生效的上限造成的，因此不要把它用于不加限定的下降结论。记下这次范围变化，或在它旁边标为受限。

已接受观察的并集包含七个不同的来源 ID，即 J1 至 J7。观察到的职位出现总次数等于四加四加四加二，即十四。每个键首次观察之后的重复出现次数等于十四减七，即七。这些是观察，不是七个被重新发布的空缺职位。新计入台账的次数等于四加一加一加一，即七。第 3 天不参与运算，因为它是未知的，不是一次结果为零的测量。不要把每日的不同职位计数四、四、四和二相加，然后称之为十四个互不重复的机会。

当前的运行时检查是一个批次，不是实际的多日趋势基准。这个示例里已接受的第 1 天、第 2 天和第 4 天集合，只对此虚构面板而言是完整的，并不是真实平台的保证。

| 日 | 运行结果 | 已保存行数 | 不同职位 | 首次见到 | 此前见过 | 备注 |
| --- | --- | --- | --- | --- | --- | --- |
| 第 1 天 | 已接受 | 4 | 4 | 4 | 0 | 完整的小型源测试集 |
| 第 2 天 | 已接受 | 4 | 4 | 1 | 3 | 新 ID J5 |
| 第 3 天 | 失败 | 未知 | 未知 | 未知 | 未知 | 数据缺失，不是零 |
| 第 4 天 | 已接受 | 4 | 4 | 1 | 3 | J6 在第 4 天首次被观察到；缺失的第 3 天期间的创建时间仍然未知 |
| 第 5 天 | 受上限限制 | 2 | 2 | 1 | 1 | 已达到上限 2 |

| 职位 ID | 首次见到的日期 | 状态 |
| --- | --- | --- |
| J1 | 第 1 天 | 初始批次 |
| J2 | 第 1 天 | 初始批次 |
| J3 | 第 1 天 | 初始批次 |
| J4 | 第 1 天 | 初始批次 |
| J5 | 第 2 天 | 新观察 |
| J6 | 第 4 天 | 新观察 |
| J7 | 第 5 天 | 新观察 |

## 下一步

打开 [Indeed Jobs Scraper Actor](https://apify.com/chronometrica/indeed-jobs-scraper) 和 [Indeed Job Market Data Task](https://apify.com/chronometrica/indeed-jobs-scraper/examples/indeed-job-market-data-weekly-hiring-trends)，选择一个小型固定面板，保存其采集清单，并且只在记录该次运行的覆盖状态之后比较来源 ID 集合。

## 来源和延伸阅读

- [美国劳工统计局 JLT 定义](https://www.bls.gov/jlt/jltdef.htm)
- [Indeed Jobs Scraper Actor](https://apify.com/chronometrica/indeed-jobs-scraper)
- [Recruiting Hell 每日样本讨论](https://www.reddit.com/r/recruitinghell/comments/1r3a8jj/i_tracked_63336_us_job_postings_last_week_feb_26/)