# 如何在同一份試算表中整合 LinkedIn 職缺與個人申請追蹤紀錄

將 LinkedIn 公開職缺資料放在試算表的一個資料表中，並將自己的申請紀錄放在另一個資料表中。使用已核對的職缺 ID 連結兩者，再建立顯示目前申請狀態的檢視表。首先，透過帳戶中可用的方法，複製或匯出個人紀錄。公開職缺的匯出資料無法告訴你是否已申請，也無法得知雇主回覆了什麼。

在同一份試算表中使用三個工作表：「職缺」、「申請事件」和「目前狀態檢視」。事件是一次有紀錄的行動，例如提交申請或參加面試。兩個來源資料表分別保存不同的事實。檢視表將這些事實整合顯示，之後匯入職缺時也不會取代個人歷史紀錄。

## 1. 從自己的申請紀錄開始

合併任何資料前，先保留目前申請清單的原始副本。如果官方帳戶匯出功能能提供所需紀錄，就使用該功能。否則，請從自己的紀錄和憑證中，手動複製少量資料。

LinkedIn 提供申請取得個人資料的管道。其說明頁面表示，只會提供你本人的資料，以及適用於你帳戶的資料類別。這項證據無法確認是否能完整匯出私人 Job Tracker 紀錄。請檢查你的帳戶實際提供哪些資料。[LinkedIn 個人資料說明，已於 2026 年 10 月 25 日查核；尚未確認可完整匯出 Job Tracker 紀錄](https://www.linkedin.com/help/linkedin/answer/a1339364)。

每筆申請都要記錄雇主、職位、可取得的職缺連結、申請日期和佐證憑證。憑證可以是提交確認通知或雇主訊息。如果缺少日期，就保持缺漏。不要填入零，也不要使用複製紀錄當天的日期。

為每筆獨立申請設定一個申請 ID。ID 是用來識別一筆紀錄的固定標籤。同一筆申請增加事件時，應繼續使用相同的申請 ID。即使雇主和職稱相同，對另一個職缺提出的第二筆申請，也必須使用不同的申請 ID。

儲存職缺不等於提出申請。草稿也不能證明已提交。如果無法確認自己是否已提交申請，就記錄這項不確定性。不要將每個已儲存的職缺都設為「已申請」。

## 2. 蒐集少量公開職缺樣本

如果已有核對過的公開匯出資料，就使用該資料。否則，可以使用接受已知職缺 ID 或職缺網址的 [LinkedIn Jobs Scraper，已於 2026 年 10 月 25 日核對公開技術規格；未進行付費執行測試](https://apify.com/chronometrica/linkedin-jobs-scraper)。Actor 是託管執行的資料蒐集程式。這個 Actor 可為以下方法提供公開職缺資料。

以下是提供的小量蒐集輸入設定：

```json
{
  "fetchJobDetails": true,
  "jobIds": ["4251746246"],
  "maxItems": 1,
  "saveOnlyUniqueItems": true
}
```

2. 蒐集少量公開職缺樣本

將範例職缺 ID 換成自己清單中一個已知的職缺 ID 或職缺網址。ID 必須放在引號內。提供的輸入設定已依公開輸入結構規格核對；該規格定義可接受的設定。本指南未進行付費蒐集執行。實際執行是建議讀者自行進行的步驟。

`maxItems` 限制所有蒐集輸入合計可儲存的職缺數量。此處的上限是一筆職缺。`fetchJobDetails` 會要求取得完整說明和詳細資料，但僅限資料可取得時。這不保證每個欄位都會有值。`saveOnlyUniqueItems` 會移除單次執行內重複的職缺。對於後續匯入，試算表仍需有自己的處理規則。

Task 是為 Actor 儲存的一組輸入預設設定。公開的 [LinkedIn Jobs to Google Sheets Task，已於 2026 年 10 月 25 日查核；僅確認公開存在，未測試已儲存的輸入設定及實際執行](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-jobs-to-google-sheets) 也是另一個起點。使用前，請檢查其已儲存的設定，並替換範例值。不能只憑名稱，就認定它能合併個人申請紀錄或保留事件歷史紀錄。

## 3. 以已核對的職缺識別資料建立「職缺」資料表

使用平台名稱和來源職缺 ID 建立職缺鍵值。鍵值是用來連結相符紀錄的值。這兩個部分都要以文字儲存。絕不能將兩個空白 ID 視為相符，也不能只憑職稱和雇主就認定是同一職缺。

[職缺追蹤指南](/zh-Hant/articles/%E9%81%BF%E5%85%8D%E9%87%8D%E8%A4%87%E7%9A%84%E6%96%B0%E8%81%B7%E4%BD%8D%E9%80%9A%E7%9F%A5/) 說明了為何跨次蒐集資料時，固定的平台和職缺 ID 很重要。合併前，先採用這項識別規則。通知傳送仍是另一項獨立工作。

在「職缺」資料表中使用以下欄位。最後兩列說明的是需要自行維護的欄位。

| 欄位 | 應儲存的內容 |
| --- | --- |
| 平台 | 來源 ID 所屬的網站 |
| 職缺鍵值 | 平台名稱加上已核對的來源 ID |
| `jobId` | 以文字儲存的來源職缺 ID |
| `jobUrl` | 公開職缺連結 |
| `title` | 來源中的職稱 |
| `companyName` | 來源中的雇主名稱 |
| `locationRaw` | 來源中的地點文字 |
| `descriptionStatus` | 傳回的職缺說明可取得狀態 |
| `descriptionText` | 可取得時傳回的職缺說明 |
| `scrapedAt` | 該資料列附帶的蒐集時間 |
| 蒐集參考資料 | 已儲存的輸入、輸出及執行參考資料 |
| 最近一次來源查核 | 查核時間及該次查核確認的事項 |

目前的 Actor 公開技術規格記載了這些來源欄位。這些欄位描述的是職缺，而非私人申請歷史紀錄。非必填欄位可能沒有值。[公開預設建置版本 0.2.26，已於 2026 年 10 月 25 日查核；僅靜態檢查技術規格，未進行付費執行](https://api.apify.com/v2/acts/kkH2KvT3IfbFf6A6P/builds/default)。

保留原始輸出，不要修改。新增資料列前，先檢查是否有缺漏的 ID 和重複的鍵值。沒有可用 ID 的資料列應暫留待查。不要為互不相關的資料列填入「未知」之類的共用鍵值。

## 4. 建立「申請事件」資料表

將個人行動保存在「申請事件」資料表。每個有證據支持的事件各占一列。提出申請、參加面試、收到拒絕通知、撤回申請和收到錄用通知，都是個人事件，不是公開職缺欄位。

| 欄位 | 應儲存的內容 |
| --- | --- |
| 事件 ID | 此事件的唯一標籤 |
| 申請 ID | 此事件所屬的申請 |
| 已核對的職缺鍵值 | 「職缺」資料表中已驗證的鍵值，或空白儲存格 |
| 配對狀態 | 已配對或待確認 |
| 事件日期 | 行動或回覆發生的日期，如已知 |
| 行動 | 有證據支持的事件類型 |
| 來源憑證 | 確認通知或訊息的參考資料 |
| 配對證據 | 此申請對應至該職缺 ID 的依據 |
| 記錄日期 | 輸入此事件的日期 |
| 備註 | 相關背景或不確定事項 |

同一筆申請有多個事件時，申請 ID 必須重複使用。同一筆申請的提交事件和後續面試事件，應使用相同的申請 ID。但兩者的事件 ID 必須不同。

將相同的申請 ID 指派給兩筆不同申請，才是 ID 錯誤。因此，不能只因申請 ID 重複，就認定有重複資料錯誤。請檢查每個 ID 識別的是哪一筆申請。另行檢查事件 ID：每個事件 ID 只能識別一個事件。

請自行保管憑證。公開資料蒐集方法不需要你的私人訊息。如果只儲存參考資料，就足以在日後找到證據，請在試算表中儲存參考資料即可。

## 5. 配對申請，並將尚未確定的鍵值留空

聯結是透過相同的鍵值連接資料列。在這個方法中，只有驗證職缺身分後，才能將申請聯結至「職缺」資料表。

對每筆申請進行以下檢查：

1. 在申請紀錄中尋找原始 LinkedIn 職缺網址或職缺 ID。
2. 檢查該 ID 是否屬於預期的雇主和職位。
3. 確認「職缺」資料表中有相同的平台和 ID。
4. 輸入已核對的職缺鍵值，並記錄配對證據。
5. 如果證據不足以確認配對，請將職缺鍵值留空，並將配對狀態設為「待確認」。

將雇主徵才頁面的網址連結至 LinkedIn 職缺前，可能需要更多證據。相似的職稱和雇主名稱可提供線索，但不能證明兩筆紀錄描述的是同一個職缺。重新刊登且 ID 不同的職缺，也需要檢查。

將配對待確認的申請保留在目前狀態檢視表中。尚未配對，不會抹去你已確認提交的申請。這只表示，該申請與某筆公開職缺資料列的連結尚未驗證。

對於已確認的配對，應一致套用至該申請的所有事件。保留原始個人匯出資料及配對決定。如果後續證據導致配對變更，請記錄修正內容和原因。不要在未留下紀錄的情況下，將申請改連至另一個職缺。

## 6. 寫下目前申請狀態的判定規則

「目前狀態檢視」應讓每個申請 ID 各占一列。先根據「申請事件」建立檢視表，再為具有已核對鍵值的申請加入公開職缺資料。這樣即使沒有配對的公開職缺，申請仍會顯示。

寫下如何從事件判定目前狀態。小型手動追蹤表可採用以下建議規則：

1. 使用同一申請 ID 下有證據支持的事件。
2. 依事件日期排序；如有時間，也要納入排序。
3. 使用能明確確立狀態的最新事件。
4. 若事件互相衝突、缺少日期或時間相同，且先後順序會影響結果，請交由人工檢查。
5. 如果申請之後重新啟動，請明確記錄。不要假設新增備註就能取消先前的拒絕或撤回狀態。

已確認的提交紀錄可支持「已申請」狀態。有證據支持的面試事件可支持「面試」狀態。拒絕、撤回或錄用事件可支持各自對應的狀態。關於職缺頁面的備註，無法支持上述任何個人申請狀態。

將事件日期和記錄日期分開。今天輸入過去的拒絕通知，不代表拒絕發生在今天。事件日期未知時，在有證據確認之前，都應保持未知。

顯示申請 ID、目前狀態、支持該狀態的事件、已核對的職缺鍵值、配對狀態、可取得的職缺資料，以及最近一次來源查核。必要時，可在檢視表中顯示「日期未知」之類的說明。不要將這類說明儲存為日期。

## 7. 後續匯入職缺時，保留個人歷史紀錄

匯入會將新資料列帶入試算表。公開職缺匯入應僅限於「職缺」資料表。更新公開資料前，先比對既有的職缺鍵值。遇到新鍵值，就新增一筆職缺資料列。不要只因再次收到同一職缺，就建立申請事件。

匯入前，先儲存試算表副本和原始來源輸出。檢查重複鍵值及非預期的變更。如果條件變更可能影響你的決定，請保留先前觀察到的資料。[公開職缺條件比較指南](/zh-Hant/articles/%E5%A6%82%E4%BD%95%E6%AA%A2%E6%9F%A5%E8%81%B7%E4%BD%8D%E5%88%8A%E7%99%BB%E6%A2%9D%E6%AC%BE%E6%9C%89%E5%90%A6%E8%AE%8A%E6%9B%B4/) 說明如何比較已儲存的職缺文字，並避免將蒐集時間當成雇主修改時間。

請分別處理以下情況：

| 情況 | 必要處理方式 |
| --- | --- |
| 來源欄位缺少值 | 保持缺漏；不要用零取代 |
| 後續資料列缺少先前的文字 | 保留先前觀察到的資料，並記錄最新的資料可取得情況 |
| 某批資料中沒有已知職缺 | 保留該職缺最後儲存的觀察資料及申請事件 |
| 蒐集失敗或達到上限 | 記錄蒐集限制；不要推論市場上沒有該職缺 |
| 申請配對尚未確定 | 將已核對鍵值欄位留空，並保留申請 |
| 公開職缺看似已關閉或到期 | 將來源證據與申請狀態分開記錄 |

職缺從搜尋結果消失，不能證明申請遭拒、職缺已有人錄取或職缺已關閉。最近一次成功的來源查核與你的申請狀態，回答的是不同問題。

職缺篩選也應獨立處理。決定哪些職位值得投入申請前，請使用[職缺適合度篩選指南](/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. 完成一個範例，並核對總數

以下操作範例為原創虛構內容。所有職缺標籤、申請、日期、憑證和事件均為虛構，不是 Actor 輸出，也不是對雇主的調查結果。所有日期均在 2026 年 10 月。

一次公開資料匯入包含五筆資料列，具有五個不同且已核對的鍵值：

| 職缺鍵值 | 虛構職位 | 最近儲存的蒐集日期 |
| --- | --- | --- |
| linkedin:F101 | 報表分析師 | 10 月 3 日 |
| linkedin:F102 | 營運分析師 | 10 月 3 日 |
| linkedin:F103 | 資料助理 | 10 月 3 日 |
| linkedin:F104 | 研究分析師 | 10 月 3 日 |
| linkedin:F105 | 專案助理 | 10 月 3 日 |

個人清單包含三筆申請。其中兩筆具有已核對的 LinkedIn 職缺識別資料。第三筆只有雇主頁面的憑證，沒有證據支持與任何 LinkedIn 職缺配對。

事件資料表包含四筆資料列：

| 事件 ID | 申請 ID | 已核對的職缺鍵值 | 配對狀態 | 事件日期 | 行動與憑證 |
| --- | --- | --- | --- | --- | --- |
| E001 | A001 | linkedin:F101 | 已配對 | 10 月 1 日 | 已提交；確認通知 R001 |
| E002 | A002 | linkedin:F102 | 已配對 | 10 月 2 日 | 已提交；確認通知 R002 |
| E003 | A003 | 試算表中留空 | 待確認 | 10 月 2 日 | 已提交；確認通知 R003 |
| E004 | A001 | linkedin:F101 | 已配對 | 10 月 4 日 | 面試；紀錄 R004 |

「試算表中留空」只是本文用來顯示的說明。實際試算表中的該儲存格應保持空白。不要將這句話、「待確認」或其他共用佔位文字儲存為鍵值。「待確認」應填在獨立的配對狀態欄位。

申請 A001 有兩個事件，因此出現兩次是正確的。E001 和 E004 仍是兩個獨立事件。這筆申請仍只計算一次。

產生的目前狀態檢視表如下：

| 申請 ID | 目前狀態 | 配對狀態 | 公開職缺連結 |
| --- | --- | --- | --- |
| A001 | 面試 | 已配對 | linkedin:F101 |
| A002 | 已申請 | 已配對 | linkedin:F102 |
| A003 | 已申請 | 待確認 | 尚無已核對的連結 |

使用明確的單位核對計算：

- 公開資料匯入：5 筆職缺資料列，代表 5 個唯一職缺鍵值。
- 個人清單：3 個不同的申請 ID，代表 3 筆申請。
- 事件歷史紀錄：3 個提交事件 + 1 個面試事件 = 4 筆事件資料列。
- 配對總數：2 筆已配對申請 + 1 筆待確認申請 = 3 筆申請。
- 已連結的公開鍵值：2 個。未連結的公開鍵值：5 − 2 = 3 個。

在此範例中，三個未連結的職缺鍵值沒有配對的申請。這無法說明個人清單以外的紀錄情況。這些是紀錄數量，不是人數，也不是整個市場的職缺數量。

現在，再次匯入相同的五筆公開資料列。「職缺」應仍有五個唯一鍵值。「申請事件」應仍有四筆事件資料列。目前狀態檢視表應仍有三筆申請，且申請狀態和配對狀態都相同。

接著，假設後續某批資料沒有 F102。除非取得更新的查核結果，否則應保留其 10 月 3 日的觀察資料。依照上述規則，A002 仍為「已申請」。缺少職缺資料，不會新增拒絕事件。

正式採用這份試算表前，請檢查申請中每個非空白的職缺鍵值是否都存在於「職缺」資料表。確認配對待確認的申請都沒有填入佔位鍵值。確認事件 ID 各自唯一，且重複的申請 ID 都屬於同一筆申請。最後，比較重複匯入前後的個人日期、憑證、備註和狀態。

## 下一次先少量匯入，確保能逐筆檢查

先從少量個人申請紀錄和一個已知的公開職缺 ID 開始。先處理能明確配對的紀錄。讓配對尚未確定的紀錄保持可見。只有在重複匯入公開資料後，個人歷史紀錄仍完整保留，且各項總數相符，才能採用這個方法。

如果你需要公開職缺資料，請開啟 [LinkedIn Jobs Scraper，已於 2026 年 10 月 25 日核對技術規格；本指南未進行付費執行測試](https://apify.com/chronometrica/linkedin-jobs-scraper)。替換範例 ID，並在擴大蒐集範圍前檢查傳回的資料列。繼續依據自己的證據記錄申請行動。匯入公開職缺資料，絕不能用來判定你已提出申請、獲得面試或遭到拒絕。

## 來源與延伸閱讀

- [LinkedIn 個人資料說明；已於 2026 年 10 月 25 日查核；提供取得本人資料的管道，尚未確認可完整匯出私人 Job Tracker 紀錄](https://www.linkedin.com/help/linkedin/answer/a1339364)
- [Chronometrica LinkedIn Jobs Scraper；已於 2026 年 10 月 25 日查核；公開資料蒐集技術規格，未進行付費實際執行測試](https://apify.com/chronometrica/linkedin-jobs-scraper)
- [LinkedIn Jobs Scraper 預設建置版本 0.2.26；已於 2026 年 10 月 25 日查核；僅檢查輸入及輸出技術規格](https://api.apify.com/v2/acts/kkH2KvT3IfbFf6A6P/builds/default)
- [LinkedIn Jobs to Google Sheets Task；已於 2026 年 10 月 25 日查核；僅確認公開預設設定存在，未測試已儲存的輸入設定及實際執行](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-jobs-to-google-sheets)