# 建立雇主追蹤名單，分清仲介與委託客戶

若要從匯出的職缺資料辨認實際徵才的公司，請將刊登機構、招募仲介公司和列明的最終雇主分開記錄。透過公司官方公開頁面核對公司身分。保留原始職缺資訊，以及每項關係的證據。如果仲介未列出委託客戶名稱，請記錄為「委託客戶不明」。單憑公司標示，無法確認雇主、職缺是否仍開放，或是否已完成聘僱。

先人工核對公司官方頁面。匯出資料提供的是待查的名稱和說法。最終結果應是一份公司追蹤名單，清楚記錄角色、佐證來源和未解問題。

## 開始前，先定義公司角色

刊登機構是職缺資訊中顯示為發布該職缺的組織。招募仲介公司是替委託客戶招募人員的組織。列明的最終雇主，是職缺資訊指稱為該職位雇主的公司。這些角色可能分屬不同組織。同一組織也可能同時擔任多種角色。

為每種角色保留獨立欄位。不要用委託客戶的名稱取代仲介名稱。這樣會刪除誰刊登該職缺的證據。

公司身分是指經過核對後，確認某個名稱所指的公開營業企業。公司關係則記錄證據中兩家企業之間的關聯。核對仲介的身分，並不能確認它與特定委託客戶的關係。

當多家仲介看似刊登同一職缺時，這項區分尤其重要。在一則[於 2023 年 12 月 7 日發布、2026 年 10 月 25 日擷取的公開討論；問題背景未經核實](https://www.reddit.com/r/jobsearchhacks/comments/18d452q)中，一位讀者描述不同仲介的職缺資訊，其薪資、聘用方式用語和合約期限各不相同。這項疑問說明有必要核查每種說法由誰提出。但它不能證明這些資訊指向同一職缺，也不能確認雇主。

追蹤名單只回答一個範圍明確的問題：出現了哪些具名公司、各自擔任什麼角色，以及有哪些證據？它不能確定這些公司計畫聘用多少人。

## 分開儲存來源欄位與審查欄位

保留一份未經修改的匯出資料副本。在另一份工作表中加入審查註記。為每筆來源資料列指定參照編號，讓其他讀者能再次找到該筆資料。

經核對的 Google Jobs Scraper 公開建置版本宣告了以下欄位。若來源或欄位規則允許，已宣告的欄位仍可能缺少值。

| 來源欄位 | 本次審查應保留的內容 |
| --- | --- |
| `companyName` | 原始公司標示，不以核對後的名稱取代 |
| `title` | 來源提供的原始職稱 |
| `description` | 可取得的說明，包括委託客戶名稱及其上下文 |
| `location` | 可取得的地點文字 |
| `jobId` | 來源識別碼，以文字形式保留 |
| `jobUrl` | 職缺資訊的網址（如有提供） |
| `observedAt` | 記錄的觀察時間 |
| `via` | 原始值，不假設它能確認雇主身分 |
| `status` | 原始狀態值 |
| `statusReason` | 原始原因值 |

URL 是網頁位址，也就是網址。識別碼是用來指稱一筆記錄的值。請將 `jobId` 與來源名稱和觀察紀錄的參照編號一併保留。不要將它用作公司識別碼。

這些欄位來自[公開預設建置版本 0.2.30，已於 2026 年 10 月 25 日核對；僅檢查欄位宣告與靜態驗證，未實際執行](https://api.apify.com/v2/acts/1dwlZdSypmIQ5vq5X/builds/default)。這次核對不能證明資料可取得、涵蓋範圍完整，或資料收集成功。

建立三份小型審查表。登錄表是已儲存、附有固定參照編號的清單。請保留公司登錄表、關係表和來源資料列審查表。

| 表格 | 建議由分析人員建立的欄位 | 用途 |
| --- | --- | --- |
| 公司登錄表 | `entityRef`, `originalName`, `checkedName`, `aliases`, `officialUrl`, `identityEvidence`, `identityState` | 將公司身分與職缺資訊中的說法分開記錄 |
| 關係表 | `relationshipRef`, `sourceRowRef`, `advertiserRef`, `recruiterRef`, `statedEmployerRef`, `clientState`, `relationshipEvidence` | 記錄各方角色與所聲稱的委託客戶關係 |
| 來源資料列審查表 | `sourceRowRef`, `sourceName`, `importRef`, `jobId`, `jobUrl`, `observedAt`, `reviewState`, `reviewReason`, `reviewer`, `reviewedAt`, `nextCheck` | 讓每項判斷都能追溯至來源 |

這些是建議的審查欄位，不是 Actor 額外提供的輸出欄位。Actor 是在託管環境中執行的資料收集程式。

別名是公司使用的另一個名稱。儲存別名時，請一併保留能將它連結至已核對公司身分的證據。拼寫相似只能作為進一步調查的理由。

每份證據註記都應保留網頁位址、核查日期、相關原文，以及它支持的結論。請將身分證據與關係證據分開記錄。同一頁面可能只能支持其中一種結論。

## 依照八個步驟建立追蹤名單

### 1. 保留每個原始公司標示

將 `companyName` 原樣複製到來源記錄中。在旁邊保留職缺資訊的網址、說明和觀察時間。

如果欄位缺值，請記錄缺值狀態。不要用搜尋詞或刊載該職缺的網站名稱，填補缺少的公司名稱。如果缺少網址，請保留匯入參照編號，並將網址標記為無法取得。

不要在這次審查中重新進行職缺資訊的配對。公司是否為同一家公司，與職缺是否為同一職缺，是兩項不同的判斷。如需另行審查職缺配對，請使用[重複職缺資訊與可能重新刊登的職缺指南](/zh-Hant/articles/%E7%A7%BB%E9%99%A4%E9%87%8D%E8%A4%87%E8%81%B7%E4%BD%8D%E5%88%8A%E7%99%BB%E4%B8%A6%E6%AD%B8%E7%B5%84%E5%8F%AF%E8%83%BD%E9%87%8D%E6%96%B0%E5%88%8A%E7%99%BB%E7%9A%84%E8%81%B7%E4%BD%8D/)。

### 2. 根據明確用語指定角色

一併閱讀公司標示和說明。記錄哪個組織以刊登機構身分出現、哪個組織負責招募，以及哪個組織被列為最終雇主。

在每項角色指定旁保留作為證據的原文。說明中列出委託客戶名稱，可支持「該資訊聲稱存在委託客戶關係」的記錄。但這不能獨立確認該關係。

如果說明只寫「我們的委託客戶」，請將雇主身分保留為不明。如果組織角色不清楚，請標記為尚未釐清。不要強行將每個公司標示都填入雇主欄位。

也請將 `via` 保留為來源資訊。經核對的欄位宣告，不足以支持將該欄位值視為招募方或雇主角色的證明。

### 3. 尋找可能對應的公司官方頁面

人工搜尋具名組織的官方網站。在頁面內容足以支持對應關係之前，請將每個搜尋結果視為候選來源。

核對網站列出的企業名稱和地點，並與職缺資訊比較。如有相關的公司介紹、聯絡資訊或徵才頁面，請閱讀內容。記錄哪些事實一致，哪些資料仍缺少。

熟悉的名稱或看似合理的網址都不夠。不要將網站位址視為一家獨立法人公司的證明。如果公開證據只支持某個營業名稱或品牌，就只描述這項公開身分，不要另行聲稱其法律身分。

### 4. 分別核對公司身分與職缺編號

職缺申請編號是雇主為某個職缺指定的代碼。如果職缺資訊或公司官方頁面出現這種編號，請將它保留為審查註記。它不屬於本文使用的已宣告輸出欄位。

一併比較名稱、地點，以及可取得的職缺申請編號。明確記下相符之處。也要記下衝突，例如地點不符，或官方頁面指向另一家企業。

公司官方頁面可能支持公司身分，卻無法支持所刊登的職位。官方徵才頁面若列出該職缺，就能對職缺資訊中的雇主說法提供更直接的證據。請將這些結論分開記錄。

如果找不到支持說法的公開證據，請保留為尚未釐清。找不到相符頁面，並不能證明公司或職缺是假的。

### 5. 只合併證據已確認為同一身分的記錄

為每家經核對的公司指定一個固定的 `entityRef`。只有證據支持對應關係時，才將名稱變體連結至該參照編號。

不要因為公司同名就合併記錄。不要將仲介與其委託客戶合併。不要將多個身分不明的委託客戶合併成一家未具名公司。

如果兩筆資料列出現相同名稱，但身分核對尚未完成，請保留各自的候選參照編號，並說明不確定之處。名稱重複不能證明它們是同一家公司。

確認別名時，請保留原標示及其來源。其他審查人員應能看出你為何將這些標示連結在一起。

### 6. 保留每一項仲介與委託客戶關係的說法

在關係表中，分別儲存仲介與列明委託客戶的參照編號。將這項關係連結至支持該說法的職缺資訊。

不要將一則職缺資訊中的委託客戶說法，套用到該仲介的所有職缺資訊。A 列列出的委託客戶，不能用來確認 B 列未具名的委託客戶。

使用少量、定義清楚的審查狀態。例如，「僅有職缺資訊中的說法」表示該關係只由職缺資訊提出。「有公開證據支持」表示你已另行儲存支持該關係的公開證據。「尚未釐清」表示證據不足以作出判斷。

這些狀態由分析人員自行選用，並非聲稱由 Actor 提供的分類。請在每個狀態旁保留支持該狀態的理由。

### 7. 按實際審查的單位計數

分別報告職缺資訊觀察紀錄、具名候選公司、已核對的公司身分，以及尚未釐清的委託客戶關係。說明每個數量所採用的計數單位。

在精確計算已知且不重複的雇主數量時，不要納入未具名的委託客戶。該客戶可能已出現在追蹤名單的其他位置。目前沒有足夠證據作出判斷。

缺少委託客戶名稱，不代表委託客戶數量為零，而是其身分不明。公開資料核查未能完成，也不代表雇主數量為零，而是這次核查未能釐清問題。

職缺資訊的數量也不能衡量聘僱意圖。重複觀察與趨勢分析請另依[重複職缺快照指南](/zh-Hant/articles/%E9%87%8D%E8%A4%87%E8%81%B7%E4%BD%8D%E5%BF%AB%E7%85%A7%E9%87%8F%E5%BA%A6%E6%8B%9B%E8%81%98%E8%B6%A8%E5%8B%A2/)處理。

### 8. 對公司作出決策前，先選定下一項核查

公司決策是針對某家公司的決定，例如是否將它加入研究名單。請審查所有可能改變該決定、但尚未釐清的身分或關係。

為每筆尚未釐清的記錄指定一項明確的後續核查。例如，查看官方徵才頁面、釐清互相衝突的地點，或尋求具名委託客戶關係的確認。

將研究候選對象與有公開證據支持的雇主關係分開記錄。即使雇主說法尚未釐清，追蹤名單中的一筆記錄仍可作為進一步研究的理由。

## 使用 Actor 收集來源資料列

人工核對身分仍是主要方法。Google Jobs Scraper 有文件列明的輸入與輸出欄位，適合用於這項工作的資料收集部分。但欄位適用不代表身分準確度已經測試，也不能證明它能完成追蹤名單。

Task 是為 Actor 儲存的一組輸入設定。[Company Hiring Monitor with Google Jobs Task，已於 2026 年 10 月 25 日核對；僅確認頁面存在，未驗證已儲存設定與執行狀況](https://apify.com/chronometrica/google-jobs-scraper/examples/company-hiring-monitor-with-google-jobs)，可作為起點。其確切 Task ID 為 `lc9Xg20bumfb452dl`。

使用以下建議的小規模輸入設定：

```json
{
  "market": "US-en",
  "maxItems": 3,
  "queries": ["data analyst"]
}
```

使用 Actor 收集來源資料列

將 `data analyst` 替換為你要研究的職位。如果目標市場不同，請將 `US-en` 替換為支援的市場值。這裡提供的值符合已核對的輸入規則。在這項建議的小規模測試中，請將 `maxItems` 維持為 3。

這組輸入設定已通過靜態檢查。靜態檢查是將設定與已宣告的輸入規則比較，不會收集資料。本篇說明未執行任何 Actor。這個範例是建議的替代輸入設定，不是 Task 目前已儲存設定的副本。上限設為 3，不保證會傳回三筆資料列，也不保證會得到三家雇主。

自行完成資料收集後，請先檢查傳回的欄位，再開始審查身分。原樣保留 `status` 和 `statusReason`。不要自行賦予它們意義，也不要將已儲存的一筆資料列視為資料收集完整的證明。

這個方法使用公開職缺資訊和公司公開頁面，不需要僅限擁有者存取的記錄，例如非公開的應徵者狀態、收件匣訊息或內部聘僱核准。日後若取得非公開確認，請與公開證據分開保留，並註明其受限的適用範圍。

## 逐步分析原創虛構範例

原創虛構教學範例。這不是 Actor 執行結果、客戶成果，也不是實際觀察到的公司發現。

三筆虛構的職缺資訊觀察紀錄包含以下說法。A、B 和 C 是教學標示，不是實際的來源識別碼。

| 觀察紀錄 | 刊登機構 | 招募方 | 列明的最終雇主 | 虛構職缺資訊中的證據 |
| --- | --- | --- | --- | --- |
| A | Birch Talent | Birch Talent | North Mill | 說明列出 North Mill 為委託客戶 |
| B | Birch Talent | Birch Talent | 委託客戶不明 | 未列出委託客戶名稱 |
| C | North Mill | 未說明 | North Mill | 職缺資訊直接列出 North Mill |

在 A 和 B 中，保留 Birch Talent 的刊登機構與招募方角色。在 A 和 C 中，保留 North Mill 作為列明的最終雇主。B 的委託客戶應維持不明。

C 中的「未說明」不代表沒有招募方，而是這份虛構證據未指出招募方。同樣地，B 缺少委託客戶名稱，也不代表 B 沒有委託客戶。

這份追蹤名單包含兩個擔任不同角色的具名實體，以及一項尚未釐清的委託客戶關係。重複出現的名稱提供了可供核查的候選關聯，但不能取代透過官方資料進行的身分核對。

計算採用以下單位：

1. 職缺資訊觀察紀錄：A 的 1 筆 + B 的 1 筆 + C 的 1 筆 = 3 筆觀察紀錄。
2. 虛構範例中提供的不重複名稱：Birch Talent + North Mill = 2 個具名實體。
3. 列明 North Mill 為最終雇主的觀察紀錄：A + C = 2 筆包含雇主說法的觀察紀錄。
4. 委託客戶未具名的觀察紀錄：B = 1 項尚未釐清的委託客戶關係。

不要將 2 個具名實體與 1 項委託客戶不明的關係相加，報告為 3 家已確認雇主。這些數量描述的是不同事物。Birch Talent 擔任仲介角色。身分不明的委託客戶可能是 North Mill，也可能是其他組織。這個範例未能判定。

本範例未提供透過官方資料進行的身分核對。因此，已確認雇主的數量仍無法確定。不要用零填補這項缺口。這三筆觀察紀錄無法推算員工人數、職缺數量或已完成的聘僱數量。

下一輪審查應核對 Birch Talent 和 North Mill 的公開企業身分。接著，應另行尋找支持 A 所述委託客戶關係的證據。在證據指出 B 的委託客戶身分前，B 應維持為尚未釐清。單憑核對 North Mill 的身分，無法確認任一仲介與委託客戶的關係。

## 使用結果前，檢查未能完成核查的情況

將追蹤名單用於公司研究前，請審查完整名單。

| 審查情況 | 應記錄的內容 | 仍未釐清的事項 |
| --- | --- | --- |
| 缺少公司標示 | 來源值缺失的狀態與資料列參照編號 | 公司身分 |
| 未列出委託客戶名稱 | 委託客戶不明的關係 | 最終雇主身分 |
| 無法存取官方頁面 | 核查未能完成的情況、網址與核查日期 | 正在審查的說法 |
| 名稱相似，但沒有證據支持關聯 | 分開保留的候選對象與待解問題 | 這些名稱是否指同一家公司 |
| 公司身分有證據支持，但關係沒有 | 已核對的身分，以及僅由職缺資訊聲稱的關係 | 仲介與委託客戶之間的關聯 |
| 公開證據互相衝突 | 雙方來源與衝突內容 | 應採用哪項說法 |
| 資料收集失敗，或傳回的證據不明確 | 資料收集結果與可取得的狀態欄位 | 是否已收集到預定樣本 |

絕不可因核查未能完成，就聲稱職缺已關閉或公司已停止徵才。保留舊證據的日期。後來的頁面變更，不會抹去所保留職缺資訊在觀察當時記載的內容。

也請清楚標示匯出資料的範圍。小規模搜尋所得的是資料收集樣本，不是完整的公司名錄。日後若要比較資料收集來源，請另依[職缺來源涵蓋範圍指南](/zh-Hant/articles/%E6%AF%94%E8%BC%83-linkedin-%E8%88%87-indeed-%E8%81%B7%E4%BD%8D%E8%A6%86%E8%93%8B/)處理，不要將資料較多的檔案視為更準確的雇主名單。

## 建立小型追蹤名單，選定下一項核查

先從現有的職缺資訊開始。保留原始標示，分別指定三種公司角色，並在官方公開頁面核對其中列出的企業。一併交付公司登錄表、關係表和來源資料列審查表。每一項採用的關聯都應附上證據和理由。

如果需要新的來源資料列，請搭配 [Google Jobs Scraper Actor，規格已於 2026 年 10 月 25 日核對；未驗證實際執行](https://apify.com/chronometrica/google-jobs-scraper)，使用本文建議的小規模輸入設定。使用結果前，先自行檢查。接著判斷哪些公司關係已有足夠的公開證據，可供下一步研究使用，哪些仍需核查。身分不明的委託客戶應維持不明。

## 來源與延伸閱讀

- [Google Jobs Scraper 公開預設建置版本 0.2.30 — 已於 2026 年 10 月 25 日核對；僅核對宣告欄位與靜態輸入驗證，未實際收集資料，也無涵蓋範圍的證明](https://api.apify.com/v2/acts/1dwlZdSypmIQ5vq5X/builds/default)
- [Company Hiring Monitor with Google Jobs Task — 已於 2026 年 10 月 25 日核對；已確認確切 Task ID 與頁面存在，未驗證已儲存輸入設定與執行狀況](https://apify.com/chronometrica/google-jobs-scraper/examples/company-hiring-monitor-with-google-jobs)
- [關於人力仲介職缺條件不一致的公開提問 — 於 2023 年 12 月 7 日發布，2026 年 10 月 25 日擷取；僅供了解問題背景，並非經核實的雇主事實或需求證據](https://www.reddit.com/r/jobsearchhacks/comments/18d452q)