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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

職缺追蹤指南 說明了為何跨次蒐集資料時，固定的平台和職缺 ID 很重要。合併前，先採用這項識別規則。通知傳送仍是另一項獨立工作。

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

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

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

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

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

同一筆申請有多個事件時，申請 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. 後續匯入職缺時，保留個人歷史紀錄

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

匯入前，先儲存試算表副本和原始來源輸出。檢查重複鍵值及非預期的變更。如果條件變更可能影響你的決定，請保留先前觀察到的資料。公開職缺條件比較指南 說明如何比較已儲存的職缺文字，並避免將蒐集時間當成雇主修改時間。

請分別處理以下情況：

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

職缺篩選也應獨立處理。決定哪些職位值得投入申請前，請使用職缺適合度篩選指南。這個合併方法會保留已有紀錄支持的決定；它不會為履歷評分，也不會提交申請。

8. 完成一個範例，並核對總數

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

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

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

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

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

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

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

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

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

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

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

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

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