# 如何閱讀 LinkedIn 職位申請人數

保留公開職位申請人數顯示的原文，記下觀察時間，並把所計數的事件視為未知。單靠 LinkedIn 申請人數顯示，無法得知有多少合資格人士正在競爭該職位。Actor 是託管的資料收集程式。Task 是已儲存的輸入預設。

## 收集設定與欄位限制

要設定收集，請取代目前的預設輸入：其中 `searchTerm` 有三個職位角色，`startUrls` 為 `[]`，`saveOnlyUniqueItems` 為 `true`。把整個職位角色清單換成一個預定的 `searchTerm` 及地點，把 `maxItems` 設為 `3`，`maxPagesPerSearch` 設為 `1`，`fetchJobDetails` 設為 `true`。

公開組建 0.2.19 提供列欄位 `jobId`、`jobUrl`、`title`、`companyName`、`applicantsRaw`、`postedAtRaw`、`postedAt` 及 `scrapedAt`。`applicantsRaw` 欄位是可為空值的字串。像「35 applicants」、「72 applicants」及「88 applicants」這類原生字串值，只證明欄位可用。衍生的 `postedAt` 欄位來自相對文字，並非確切刊登時間的證明。像 `requestedMaxItems`、`jobsSaved`、`candidateItemsSeen`、`pagesParsed`、`detailRequests`、`detailFailures`、`blockedRequests`、`failedRequests` 及 `stopReason` 這類執行輸出，用來追蹤收集程式這次執行。`stopReason` 為 `max_items_reached` 時，只證明已達到項目上限，而不是完整的市場覆蓋。

已標明類型的表格，指每一欄都有一個已說明的值類型。整數顯示是可見整數的精確謄寫，但底層所計數的事件仍然未知。像「2K」這類捨入顯示，並非已核實的確切數值或捨入區間。像「Over 100」這類下限顯示，表示高於 100 的界限，而不是恰好 100。

## 逐步收集方法

1. 先寫明真正的問題。已顯示的計數器並不顯示工作者技能、職位資格、每人只計一次的不同人士，或已完成的表格。這個方法建立一份清楚的證據紀錄，而不是聘用分數，也不是勸你放棄的建議。
2. 收集一個公開職位樣本。檢查職位 ID 與 URL，並把原始申請人文字連同擷取時間一併儲存。該顯示日後可能改變或消失。不要把非公開的招聘人員報告放進你的公開資料。
3. 分開各種顯示狀態。把文字分類為整數顯示、捨入顯示、下限顯示、非數字片語，以及無法取得。保留確切用字，加上剖析規則。整數只是文字副本，並非事件確切或每人只計一次的證明。不要刪去 over 或 plus 這類標記。
4. 只按文字本身的意思剖析。「35 applicants」表示整數 35。「Over 100 applicants」表示高於 100 的下限，而不是恰好 100。「2K applicants」是簡寫，沒有已核實的捨入規則。像「Be among the first 25 applicants」這類片語是推廣文字，不是直接計數。null 值表示無法取得，而不是零。
5. 加入事件定義狀態與證據。這個公開頁面沒有官方定義時，把事件保持為未知。Campaign Manager 的點擊次數與申請次數屬於另一個工具，並不定義這個公開計數器。
6. 把刊登時長與收集時間分開。像「3 days ago」這類相對標籤，加上一次快照，並不能得出確切的每日速率。較後的觀察只有在職位 ID 與顯示規則相符時，才顯示差異。這並非市場增長的證明。
7. 用這份紀錄查看你的選擇有甚麼限制。不要用 1 除以該人數，來找出你獲得該職位的機會。不同的申請人各自提出申請，事件未知，也沒有量度任何甄選過程。請閱讀職位詳情並[評估你的證據](/zh-Hant/articles/%E6%8C%89%E6%8A%80%E8%83%BD%E6%8E%92%E5%BA%8F%E8%81%B7%E4%BD%8D%E5%88%97%E8%A1%A8/)，而不要信賴公開排名。
8. 交付一份已標明類型的表格，包含原始文字、顯示狀態、數值證據、事件定義、日期證據，以及未解決原因。讓未知項目保持可見，而不要猜測真實申請人數。

## 原創虛構的完整原始顯示帳冊

以下例子與表格列均為原創虛構。

| 職位 ID | 來源參照 | 原始顯示文字 | 顯示狀態 | 數值證據 | 事件定義 | 日期證據 | UTC 觀察時間 | 未解決原因 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| J1 | fictional_src_01 | 35 applicants | integer_display | 35 | unknown | 3 days ago | 2026-10-13T06:00:00Z | 事件類型未定義 |
| J2 | fictional_src_02 | Over 100 applicants | lower_bound_display | 高於 100 | unknown | 1 week ago | 2026-10-13T06:00:00Z | 有界限的下限 |
| J3 | fictional_src_03 | 2K applicants | rounded_display | 未核實 | unknown | 2 weeks ago | 2026-10-13T06:00:00Z | 簡寫捨入 |
| J4 | fictional_src_04 | Be among the first 25 applicants | nonnumeric_phrase | 無 | unknown | 4 days ago | 2026-10-13T06:00:00Z | 推廣文字 |
| J5 | fictional_src_05 | null | unavailable | 無 | unknown | 5 days ago | 2026-10-13T06:00:00Z | 欄位缺失 |
| J6 | fictional_src_06 | 0 applicants | integer_display | 0 | unknown | 6 days ago | 2026-10-13T06:00:00Z | 計數為零，並非缺失 |

在這組虛構資料中，有 6 列觀察、2 個整數顯示、1 個下限顯示、1 個捨入顯示、1 個非數字片語，以及 1 個無法取得的欄位。這裡沒有任何一組包含 6 個已知的申請人數。不要把這些狀態加總成市場總規模。未知值仍然與零分開。

若具有相同身分的 J1 在 2026-10-14T06:00:00Z 被觀察到，並顯示「40 applicants」，可比較的顯示差異是加 5。這並不是 5 個已確認、新的、每人只計一次的已完成申請。若改為顯示「Over 100」，則沒有確切可比較的差值。相對時長為 3 日，並不支持把 35 除以 3，從而聲稱每日有 11 個申請。

## 下一步

在把申請人數用於職位選擇之前，先使用 [LinkedIn Jobs Scraper Actor](https://apify.com/chronometrica/linkedin-jobs-scraper) 與 [LinkedIn Applicant Pressure Task](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-applicant-pressure)，儲存一則原始申請人數顯示，連同其精確度與未知的事件意義。

## 來源與延伸閱讀

- [LinkedIn Campaign Manager 定義](https://www.linkedin.com/help/linkedin/answer/a414844/)
- [資料工程職位帖文討論](https://www.reddit.com/r/dataengineering/comments/1s46fea/why_are_data_engineering_job_posts_getting/)