如何研究 LinkedIn 留言作者的公開職務

把留言和帳戶分開

已保存的一列就是一則可取得的頂層留言。它不是一個人。它不是一次反應。它不是一份完整個人檔案。它不是整條討論。

這些是列欄位：

• `commentId`
• `commentUrl`
• `postUrl`
• `postUrn`
• `authorType`
• `authorUrl`
• `authorId`
• `authorUrn`
• `authorPublicIdentifier`
• `authorName`
• `authorHeadline`
• `authorLocation`
• `authorCurrentOrganizations`
• `text`
• `observedAt`

`authorUrn` 和 `postUrn` 是 URN 值。URN 是來自公開來源、帶類型的文字識別碼。`authorId` 也是公開來源的識別碼。這些識別碼是公開的。它們不是密鑰。

`authorType` 有三個已核對的值：`person`、`organization` 或 `null`。`null` 表示沒有提供類型。不要把 `null` 讀成 person。

`observedAt` 是你觀察到該列的時間。它不是貼文發佈的時間。如果兩個時間都有，在筆記中同時寫下。不要對調。

`authorCurrentOrganizations` 可以有多於一項公開記錄。保留每一項。不要編造一個僱主。如果該欄位是 null 或是空的，機構證據就是未知。未知不是零。未知不是失業。未知不是沒有公司。

作者資料可以缺失。一次請求可以返回標題為空或機構為空的一列。把那些儲存格留作未知。不要用留言文字填寫這些儲存格。

只使用一個留言表。你不需要第二個資料集來編碼職務。

設定一次小型執行

1. 選擇已知的公開貼文。收集之前先寫下研究問題。述明收集時間。為每則貼文述明上限。當推廣留言、貼文作者的留言和機構帳戶會改變研究時，標明這些列。推廣留言主要推廣產品或服務。保留已標記的列。不要刪除。如果你把貼文作者的帳戶排除在佔比之外，就要說明，並更改總數。
2. 收集一個小樣本，並開啟作者資料。2026年10月13日已核對的已保存 Task 是 LinkedIn Comment Authors with Public Profile Details。其已保存的輸入如下：

{"startUrls": ["https://www.linkedin.com/posts/timferriss_how-to-become-dramatically-more-productive-activity-7386884213343428608-wrF3"], "maxComments": 100, "collectAllAvailable": false, "includeAuthorDetails": true}

把該樣本貼文換成你打算研究的公開貼文。第一次執行時，把 `maxComments` 設為 3。保持 `collectAllAvailable` 為 false。false 使數量上限保持有效。保持 `includeAuthorDetails` 為 true。

作者資料是獨立於留言列的另一次請求。成功取得的額外詳細資料可以造成另一項計費事件。計費事件是一項收費記錄。不是每項請求都會造成收費。詳細資料欄位仍可能返回空白。本文不述明價格。

1. 保存留言列和這次執行的 OUTPUT。為任何職務編碼之前，先讀取每則貼文的 OUTPUT。

執行層級的 OUTPUT 包含 `savedRows`、`authorProfileRequests`、`authorDetailEvents` 和 `rowsWithAuthorDetails`。讀取這些欄位，以查看記錄了多少列和多少次詳細資料請求。在詳細資料缺失時，`rowsWithAuthorDetails` 可以低於留言數目。不要把這些計數用作職務總數。不要把它們讀成帳單。

每則貼文有一個 `inputResults` 記項。在該處讀取這些欄位：

• `status`
• `statusReason`
• `pageCommentCount`
• `publicRowsOnPage`
• `savedRows`
• `isPublicPageComplete`
• `isComplete`
• `stopReason`

使用該貼文 `inputResults` 內的 `stopReason`。位於 OUTPUT 根層的 `stopReason` 不是該貼文的上限狀態。

`isPublicPageComplete` 為 true，表示已擷取公開顯示的頁面。這不表示已保存整段討論。`isComplete` 為 false，表示已保存的收集並不完整。上限、公開預覽限制、來源限制或收費上限都可以造成這個結果。讀取每個輸入的 status、原因和 stopReason。成功的執行 status 不會使該表變成完整。`pageCommentCount` 和 `publicRowsOnPage` 是頁面計數。這些頁面計數不是已觀察的個人帳戶數目。

2026年10月13日，一次有限度的檢查從 1 則貼文保存了 3 則留言。它發出了 3 次作者詳細資料請求。已顯示的頁面計數是 4 時，上限停止了這次執行。就該貼文而言，`isPublicPageComplete` 是 true，`isComplete` 是 false，`stopReason` 是 `max_comments_reached`。已保存的 3 列不是整段討論。它們只顯示可以返回公開的作者資料。它們不是一份職務報告。不要把它們用作逐步範例。

建立兩個表

保留一個留言表。每一列使用自己的 `commentId`。

如果缺少 `commentId`，把該列保留為獨立的來源觀察。為它編一個標籤，例如 `missing-comment-1`。絕不要合併兩個空白的 comment id。絕不要因為留言文字相符而合併兩列。相同的文字不是同一則留言。

先確認類型，才建立個人帳戶表。

1. 讀取 `authorType`。
2. 只有在 `authorType` 是 `person` 時，才把 id 歸組。
3. 優先以 `authorUrn` 或 `authorId` 作為安全鍵。
4. 如果沒有這些 id，一個已核對的公開個人檔案 URL 可作為臨時標籤。要說明 URL 標籤弱於穩定 id。URL 標籤不是未能解析。
5. 未能解析是指沒有安全鍵。沒有 `authorUrn`，沒有 `authorId`，也沒有已核對的個人檔案 URL。已有已核對的 URL 時，不要只因為缺少穩定 id 就把一列稱為未能解析。
6. 絕不要按 `authorName` 合併列。
7. 絕不要把空白的 id 互相合併。

`organization` 帳戶留在獨立的一組。把它們的 id 與 person id 分開。它們不計入個人帳戶總數。在總數旁邊述明它們的計數。

如果 `authorType` 是 `null`，不要把該列當作個人帳戶。如果該列也沒有安全的 person 鍵，它仍然是未能解析。不要把它配給附近的名稱。

未知職務和未能解析的身分是兩回事。未知職務是指你已找到該個人帳戶，但標題沒有述明職務。該帳戶仍計入個人帳戶總數。未能解析的身分則不計入。

為你看得見的標題編碼

計數之前先寫編碼手冊。編碼手冊是一份簡短清單，列出類別，以及每個類別所需的標題證據。

使用以下規則。

• `operations`：標題述明營運工作。
• `technical`：標題述明軟件或工程工作。
• `marketing`：標題述明市場推廣工作。
• `mixed`：標題述明多於一種上述職能，而且規則不能選出一種。
• `unknown`：標題缺失，或沒有述明職能。口號屬於 unknown。

在類別旁保存標題的原文。使用整項已述明的職能。不要從口號推斷職位。不要從留言語氣推斷職務。留言文字不是職務證據。

每個個人帳戶身分只用一個主要類別。這樣，每個身分在佔比中只加入一次。你可以在第二個欄位保留額外標籤。不要把那些標籤當成更多帳戶來加入。

同一帳戶的文字有衝突時，兩份帶日期的標題快照都要保留。每份快照都保留證據原文。不要為了使圖表較整齊而挑選職稱。報告使用一條已聲明的選定觀察規則。如果不能使用該規則，主要職務仍是 `unknown`。`conflict pending review` 只用於另一個讀者覆核狀態。不要把不同時間的職務編碼為 `mixed`。只有在選定標題述明多個職務，而且編碼手冊不能選出一個職務時，才編碼為 `mixed`。當選定標題沒有顯示一項清晰職能時，編碼為 `unknown`。

職務類別是你為已述明職能所起的標籤。它不是已核對的資格。

先各計一次，再相除

在活動表計入重複的留言。在職務表中，每個已觀察的個人帳戶身分只計一次。

分母是你用來做除數的總數。分子是被除的計數。佔比是分子除以已述明的分母。

在職務報告中，分母是已觀察的個人帳戶身分數目。機構列在分母以外。未能解析的列在分母以外。未知職務的帳戶留在分母以內。

已知職務覆蓋率用第二份報告，不是用新的對象。它的分子是主要職務不是 `unknown` 的個人帳戶身分。它的分母是全部已觀察的個人帳戶身分。`mixed` 不是 `unknown`。

你也可以只顯示已知職務組之內的佔比。該視圖的分母較小。在表上寫明該分母。在旁邊保留未知的計數。不要把這些佔比與較大分母的佔比相比。帳戶沒有改變。改變的是總數。

請第二位讀者用同一份編碼手冊為數則標題編碼。覆核你們編碼結果不同的列。這是在檢查一致性。它不證明該職位是真實的。

虛構的逐步範例

本節的貼文、標籤、名稱、標題和計數都是虛構的。它們不是 2026年10月13日那次檢查。它們不是真實的人。

一則編造的貼文得出 8 列留言。虛構的 `commentId` 值是 `c1` 至 `c8`。這 8 列沒有任何一列的 `commentId` 是空白。person 列的 person id 已核對。`c8` 沒有安全鍵。

個人帳戶表：

`org1` 的 `authorType` 是 `organization`，並有 1 則留言。它留在個人帳戶表之外。`c8` 的 `authorType` 是 `null`，而且沒有安全鍵。它是 1 則未能解析的留言。絕不要把 `c8` 歸入 `p4`。

這 8 則留言包含 4 個已觀察的個人帳戶身分、1 個機構作者，以及 1 列未能解析的作者。不要說剛好有 6 個人。未能解析的列可能是某個個人帳戶的重複。`org1` 是機構。

職務佔比以 4 個已觀察的個人帳戶身分作為分母。

operations 的佔比是 1 除以 4。那是 25%。同一計算使 technical、marketing 和 unknown 也是 25%。這四個佔比用同一個分母，所以相加是 100%。

已知職務覆蓋率以 3 為分子、以 4 為分母。3 除以 4 是 75%。未知帳戶仍可看見，是這 4 個之中的 1 個。

第二個視圖只使用 3 個已知職務帳戶。每個已知組是 1 除以 3，約為 33.3%。在這個視圖旁邊保留未知計數。該未知帳戶是 1，而且在這個分母之外。

不要把 33.3% 與 25% 相比。這些數字使用不同的分母。它們並不表示對象有改變。

留言活動是另一個總數。合計為 8。

`p1` 和 `p2` 各寫了 2 則留言。如果職務報告使用全部 8 列留言，就會把這兩個帳戶各計算兩次。留言量用活動表。組成用這 4 個個人帳戶身分。

虛構的覆蓋說明：上限是 8。已觀察的來源頁面計數是 12。在 `inputResults` 中，`stopReason` 是 `max_comments_reached`，`isComplete` 是 false。這則虛構說明不設定 `status` 或 `statusReason`。

決定：把這 4 個帳戶的職務表保留為已觀察的樣本。只有在研究需要更多覆蓋時才再收集。絕不要把這個樣本稱為全部 12 名參與者。不要把 12 讀成 12 個個人帳戶身分。

虛構發現：在這個設有上限的樣本中，每個主要職務是 4 個已觀察的個人帳戶身分的 25%。已知職務覆蓋率是 75%。這項發現只關於該樣本。它不描述全部客戶。它不顯示誰可以購買。

要交出的內容

交出這些項目。

• 個人帳戶表，每個帳戶一個主要職務。
• 編碼手冊，以及用作證據的標題原文。
• 機構計數，位於個人帳戶分母之外。
• 未能解析的身分計數，以及任何缺失 `commentId` 的讀者自訂標籤。
• 每則貼文一份來自 `inputResults` 的覆蓋說明。
• 一項範圍狹窄的發現，並寫明分母和上限。

述明收集時間。不要用貼文的發佈時間取代它。如果標題或機構清單是空的，顯示未知。不要把未知變成零。

如果 `isComplete` 是 false，要說明該表不是整段討論。如果兩份標題快照不一致，兩份都要顯示。不要隱藏你沒有編碼的那一份。