如何連接 LinkedIn 個人檔案、貼文與留言而不錯配

先選定列粒度

列粒度是指一列代表什麼。收集列之前先選定粒度。

證據粒度是一則已選留言觀察。一則留言觀察是來自一個快照的一則已儲存頂層留言。計數粒度是一則已選貼文。留言計數與貼文計數是不同的量度。把它們加在一起之前，先把兩個意思寫進檔案。

寫下已知來源 URL。寫下報告期間。報告截止點是你納入的最後觀察時間。截止點之後的列仍留在原始資料集。它不進入這份報告。

只把這個方法用於已知公開貼文 URL、其公開頂層留言，以及已核對的個人檔案。不要把它用於帳戶搜尋、一個帳戶的每一則貼文、反應清單、回覆、傳送訊息、職位標籤或文字分數。

詞語

URN 是帶類型的文字識別碼。在 `urn:li:activity:1001` 中，URN 類型是 `activity`。類型是鍵的一部分。`ugcPost` 是另一種貼文類型。在這些 Actor 中，`member` 是個人帳戶類型。`organization` 不是個人帳戶類型。

LinkedIn URN 指南說明官方 LinkedIn API 的 URN 類型。該 API 使用 `person` URN。Actor 的個人檔案鍵使用 `member`。這兩套結構描述並不相同。不要把識別碼從一個 LinkedIn API 複製到另一個，然後稱它們相等。

JSON 是一種文字資料格式。你會使用 JSON 或文字欄，以免長識別碼失去位數。

布林欄位的值是 true 或 false。預設值是你不更改該欄位時使用的值。輸入結構描述是 Actor 接受的已發布欄位清單。父鍵是存在留言列上的貼文鍵。後備是指只有較早的鍵缺失時，你才嘗試下一個鍵。標準是指你已確認的那一個來源 URL，不是該 URL 的另一種形式。

相容的鍵有相同的 URN 類型和相同的值。衝突是指一個鍵指向兩個目標，或兩個鍵指向兩個不同目標。當相同類型的鍵指向同一則貼文時，單是 URN 類型不同並不是衝突。

三個 Actor 傳回什麼

三個公開 Actor 提供來源列。連接仍要由你建立。

LinkedIn Post Scraper 是 build 1.0.60。LinkedIn Comments Scraper 是 build 1.0.47。LinkedIn Profile Scraper 是 build 1.0.28。每次執行前先閱讀每個 Actor 頁面。較後的 build 可以更改欄位。

每個 Actor 都讀取公開頁面。它們都不使用你的 LinkedIn 登入。它們都不會傳回一個帳戶的每一則貼文。

留言輸入還有 `maxComments`、`includeAuthorDetails` 和 `collectAllAvailable`。`maxComments` 是 1 至 1000 的整數。其預設值是 100。`maxComments` 是每個貼文／輸入最多儲存的留言數。它不是一次多輸入執行的總上限。`includeAuthorDetails` 是布林值。其預設值是 false。`collectAllAvailable` 是布林值。其預設值是 false。`collectAllAvailable` 只移除數字上的儲存上限。它不會移除公開限制。它不會收集回覆。

留言計數與輸入狀態在 `OUTPUT`。`OUTPUT` 是執行摘要。它不是留言列。在其中，`inputResults` 帶有 `status`、`statusReason`、`pageCommentCount`、`publicRowsOnPage`、`savedRows`、`isPublicPageComplete`、`isComplete` 和 `stopReason`。

`pageCommentCount` 是該頁報告的計數。`publicRowsOnPage` 是在該頁看到的公開列數。`savedRows` 是已儲存的數目。這三個數字可以不同。`isPublicPageComplete` 說明 Actor 是否把該公開頁標為完成。`isComplete` 說明已儲存的集合是否完整。`stopReason` 說明儲存為何停止。部分結果可以來自儲存上限、公開預覽或計費限制。未知計數保持 null。不要在其位置寫上零。

留言 Actor 可以接受帶類型的 feed-update URL。貼文 Actor 要求 `/posts/` URL。如果你只知道 feed URL，保留留言父鍵。取得已核實且相符的 `/posts/` URL 之後，才收集貼文快照。不要編造 `/posts/` 的 slug。Slug 是網址路徑裡辨識該頁的那一段。

使用這些 Task，然後更改範例輸入。未更改的範例無法連接。貼文 Task 的範例與留言 Task 的範例不是同一則貼文。

不要把兩個留言 Task 接成兩組留言。為該貼文選擇一個留言 Task。詳情 Task 仍可能傳回一則沒有作者 ID 的留言。一次有用的詳情要求可以造成另一次計費事件。該要求不保證有 ID。它也不保證會收費。

作者詳細資料預設關閉。在該預設輸出中，穩定的留言作者鍵常常是 null。公開識別碼與公開 URL 之後可以改變。個人檔案快照顯示該檔案在其自身時間的狀態。它不能證明較早留言時間的職位。這個方法不會指派職位角色。

執行文件說明執行上限與逾時。大規模執行前先閱讀。不要把 access token 放進試算表。

如何把留言配對到貼文

按所述次序配對。保持相同類型的規則。配對鍵指向一則貼文。先檢查所有可用且相容的鍵有沒有衝突。不要跳過一個互相矛盾的較低鍵。只有在該檢查之後，才按所述次序選擇第一個受支援的配對依據。記錄該依據。依據欄是讀者自建的。Actor 不會傳回它。

1. 相等且帶類型的 `postUrn`。
2. 相等的 `activityId`，只限在 activity 類型之內。
3. 相等的 `ugcPostId`，只限在 ugcPost 類型之內。
4. 一個已核對的標準來源 URL。

留言欄位是 `postUrn`、`activityId`、`ugcPostId` 和 `postUrl`。貼文欄位是 `postUrn`、`activityId`、`ugcPostId` 和 `url`。其中任何一個都可以是 null。

先用帶類型的 URN，再用裸 ID。一個 activity 值與一個 ugcPost 值可以同時存在於同一則貼文，而且仍然不同。這是正常的。不要把 activity 值與 ugcPost 值比較。跨類型的相同數字不是證據。

虛構例子中的貼文 A 有 activity `1001` 和 ugcPost `2001`。那是同一則貼文的兩個鍵，不是衝突。當一個鍵指向兩則貼文，或可用的鍵指向兩則不同貼文時，才存在衝突。後備次序不讓較弱的鍵推翻該衝突。讓該留言保持未解決。

只有帶類型的鍵缺失時才使用 URL。兩個 URL 都必須是你已核對的同一個標準來源 URL。如果你不能核對這一點，讓該列保持未解決。URL 依據弱於帶類型的鍵。寫下依據與兩個觀察時間。

在這次連接之前，把重複的貼文快照縮減為一列已選查閱列。如果查閱表仍有兩列同一則貼文的成功列，連接會複製留言。修正查閱表。不要刪除被複製的留言列，而讓查閱表保持不變。

缺少貼文快照是缺少配對。它不是一則空貼文。成功的貼文而沒有已儲存留言，是另一個結果。失敗的貼文嘗試是另一個結果。你沒有執行的輸入是另一個結果。

如何配對個人檔案

只有在作者是指個人帳戶之後，才把個人檔案配對到留言作者。留言欄位是 `authorType`。它可以是 `person`、`organization` 或 null。貼文 Actor 可以把貼文作者類型寫成 `Person`。每個來源值都保持到達時的原樣。就這個意思檢查而言，`person` 和 `Person` 都是指個人帳戶。不要要求大小寫字母相同。不要為了讓字母相符而修改已儲存文字。

組織作者留在個人檔案連接之外。組織 URL 不能變成 `/in/` 個人檔案列。`urn:li:member:11` 與 `urn:li:organization:11` 是不同的鍵。不要去掉 URN 類型來強迫配對。

完成人士檢查後，按此次序配對：

1. 相等的 member ID：個人檔案 `profileId` 對留言 `authorId`。
2. 相等的 member URN：個人檔案 `profileUrn` 對留言 `authorUrn`。
3. 較弱的後備：`publicIdentifier` 對 `authorPublicIdentifier`，或個人檔案 `url` 與留言 `authorUrl` 的標準 `/in/` URL。

不要配對 null。不要配對空白儲存格。如果 member ID 指向個人檔案 X，而 URL 指向個人檔案 Y，該列是衝突。不要用較弱的 URL 選出勝者。

URL 或公開識別碼可以在快照之間改變。如果你使用該較弱依據，寫下兩個 `observedAt` 值與依據。null URL 保持未解決。姓名、相片和個人標題不是鍵。不要按姓名搜尋來填補缺失的連結。

相同的個人檔案欄位可以與貼文作者欄位 `authorId`、`authorUrn`、`authorPublicIdentifier`、`authorUrl` 和 `authorType` 比較。該比較只檢查貼文作者角色。它是可選的。它不是留言作者。永遠不要用貼文作者取代留言作者。永遠不要把一個帳戶的每一則貼文連到該帳戶的每一則留言。

one post snapshot
    -> many comment observations

one person profile
    -> many comments by that person

optional post-author match
    -> the post row only
    -> not the comment author

一個人可以寫許多留言。一則貼文可以有許多留言。這兩個方向是分開的。

留言身分使用 `commentId`、`commentUrl`、父鍵和 `observedAt`。ID 或連結可以是 null。保留該觀察。不要編造穩定 ID。不要把相同文字當成同一則留言。不要把試算表列號當成 ID。跨執行時，只有父鍵與 `commentId` 都穩定且相等，才選取一則觀察。沒有穩定 `commentId` 的列保持為分開的觀察。

個人檔案與貼文狀態使用 `status`、`statusReason` 和 `observedAt`。把失敗的個人檔案列留在來源檔案。不要把它當成成功的個人檔案配對。

連接前先選一個快照

查閱列是你允許連接使用的那一個快照。每則已核對貼文最多選一列成功貼文列。每位已核對人士最多選一列成功個人檔案列。在連接之前做這件事。

保留原始資料集。不要把兩個快照混成一列新列。把選取規則寫進檔案。一個清楚的規則是：報告截止點之前最新的成功快照。

如果一個人有兩個成功的個人檔案快照，選一個。如果兩個都留在查閱表，該人的每則留言會按每個快照複製一次。多出來的已連接列是查閱錯誤。修正查閱表。不要刪除那些複本，然後稱試算表正確。

然後從已選留言觀察建立左連接。先把每則留言連到一則來源貼文。再把它的人士作者連到最多一個個人檔案。沒有貼文配對的留言仍保留。沒有個人檔案配對的留言仍保留。

已連接的證據表必須與已選留言觀察有相同的列數。列數更多，表示查閱鍵仍指向多於一列。

這些讀者自建欄位屬於證據列：配對依據、配對結果、已選快照規則，以及你比較過的來源時間。把它們標為讀者自建。不要把它們呈現為 Actor 欄位。

把長 ID 保持為文字。試算表可以更改長數字並去掉位數。匯出 JSON，或在匯入前把每個 ID 欄設為文字。JSON 已在上文定義。資料集文件給出匯出路徑：選取資料集，選擇 Export，選擇格式，再選擇 Download。分開儲存 `OUTPUT`。資料集匯出不含 `OUTPUT`。

步驟

1. 寫下列粒度、已知 URL、報告截止點，以及每個計數的意思。證據檔案會為每則已選留言觀察有一列。計數檔案會為每則已選貼文有一列。在該書寫完成之前，留言總數與顯示的貼文計數保持分開。
2. 開啟用於安全資料連接的 LinkedIn 貼文與留言 ID。把範例 URL 換成一個已知公開貼文 URL。把 `maxComments` 設為 3。保持 `collectAllAvailable` 為 false。作者詳細資料保持關閉。開始執行。在你解釋一組列數很少的結果，或一組沒有列的結果之前，先開啟 `OUTPUT`。列數少可以是儲存上限、失敗的輸入、公開限制，或一組較短的公開留言。單靠列數不能說明是哪一種。
3. 如果預設留言列沒有你需要的作者鍵，改用附公開個人檔案詳情的 LinkedIn 留言作者，不要用第一個留言 Task。更換範例貼文。使用三則留言。保持不限數量關閉。把 `includeAuthorDetails` 設為 true。不要把兩份輸出貼在一起。詳情仍可能缺失。額外的詳情要求可以分開計費，而且仍可能不傳回 ID。
4. 開啟用於資料連接的 LinkedIn 貼文 ID 與作者鍵。把其範例換成同一個 `/posts/` URL。不要傳入貼文 ID。不要傳入 feed-update URL。如果你只有 feed-update URL，保留留言父鍵，並停止貼文收集，直到你有已核實的 `/posts/` URL。不要編造該 slug。把 `ok`、`failed` 和 `invalid_url` 列分開。保留 `observedAt`。缺少貼文快照仍然是缺少配對。
5. 閱讀留言作者鍵。如果留言列已經有這份報告需要的每一項作者事實，略過個人檔案 Actor。如果沒有，用用於資料連接的 LinkedIn 個人檔案 ID 與 URN收集不重複的公開 `/in/` URL。移除重複 URL。排除組織 URL。不要按姓名、相片或個人標題搜尋。把失敗的個人檔案嘗試留在來源檔案。失敗的嘗試不是已配對的人。
6. 選取查閱表。每則已核對貼文保留一個成功貼文快照。每位已核對人士保留一個成功個人檔案快照。對於重複的留言執行，按穩定父鍵加上 `commentId` 各保留一則觀察。沒有 `commentId` 的列保持為分開的觀察，即使文字相同。保留每一個原始資料集。寫下截止規則。連接之前，先在查閱表解決重複鍵與衝突。
7. 把每則已選留言左連接到一則貼文。先用相等且帶類型的 `postUrn`，再用相等的 activity ID，再用相等的 ugcPost ID，再用已核對的標準 URL。不要跨越 URN 類型。然後把人士作者連到最多一個個人檔案。先用 member ID，再用 member URN，再用帶觀察時間的公開識別碼或標準 `/in/` URL。寫下讀者自建的依據、結果，以及兩個來源時間。不要用貼文作者填補留言作者。不要把一個帳戶的所有貼文連到該帳戶的所有留言。
8. 計數證據列。數目必須等於已選留言觀察。如果更大，查閱表仍是一個鍵對應許多列。修正該查閱表並再次連接。不要把刪除重複證據列當作唯一修復。分開計數未配對父項、缺失的人士鍵、失敗的個人檔案、組織作者和衝突。
9. 按已解決的貼文鍵把留言觀察分組。只把 `commentsCount` 放在一列已選貼文列。把該次執行的 `OUTPUT` 涵蓋資料放在貼文旁邊。保留沒有已儲存留言的貼文。成功的空收集、失敗的嘗試，以及你沒有執行的輸入，保持為不同事實。把作者鍵計為已觀察的帳戶。不要稱它們為不重複的人。不要稱它們為留言者或觀看者的完整集合。
10. 匯出證據表、未解決表、每則貼文的計數表，以及來源摘要。使用上文的資料集匯出路徑。在旁邊儲存 `OUTPUT`。ID 保持為文字。在每一列結果列顯示來源鍵、讀者自建依據，以及缺失的證據。只有當你持有能填補該項確切缺口的受支援來源 URL 時，才填補該缺口。否則保持未知。

證據計數是步驟 8。貼文計數是步驟 9。不要把貼文計數用作留言計數。

一次公開檢查證明了什麼

一次公開檢查從一則已知貼文儲存了三則留言。來源顯示四則留言，並露出四列。上限儲存了三則。三個已儲存父鍵各自配對到同一則來源貼文。一位留言作者配對到一列分開的個人檔案列。所有那些已核對的配對都成功。

該次執行的留言 `OUTPUT` 有 `isPublicPageComplete` 為 true、`isComplete` 為 false，以及 `stopReason` 為 `max_comments_reached`。合起來讀，Actor 把公開頁標為完成，而儲存仍不完整，因為已達到儲存上限。

該檢查只證明那些列與該摘要。它不證明其後的每一則貼文。它不是對 ugcPost 配對、組織作者、null 鍵或衝突的一次新的即時測試。那些情況使用上文的欄位規則，以及下文的虛構計數。

虛構貼文、留言與計數

本節每個值都是虛構的。C1 至 C6 是教學標籤。短 ID 是教學 ID。它們不是已收集的 LinkedIn 值。不要把下文任何 URN 當成真實的個人檔案、貼文或留言。

報告截止點在 `time-2` 之後。已選的 member12 快照是較後的成功快照。貼文作者類型在 A 和 B 儲存為 `Person`。留言作者類型在 C1 至 C4 儲存為 `person`。這些意思相符。已儲存的字母仍然不同。貼文 C 儲存為組織作者。

Member11 有一列成功且已選的個人檔案列。Member12 有兩個成功快照。連接前先選一個。Member13 有一次失敗的個人檔案嘗試。A 和 B 由 member11 撰寫。C 由 organization11 撰寫，不是由 member11 撰寫。

C2 不是以帶類型的 activity URN 配對，因為該父 URN 是 ugcPost URN。activity ID `1001` 配對貼文 A。ugcPost ID `2001` 也配對貼文 A。兩個相同類型的鍵一致，所以這是確認，不是衝突。你寫下的依據是 activity ID。

C5 配對貼文 C，因為兩邊都使用 ugcPost `1001`。貼文 A 也包含數字 `1001`，但那些數字是 activity ID。相同數字不會把 C5 移到 A。

證據表保留六列。配對表與未解決表是檢視。當一方配對而另一方不配對時，它們可以重複一則留言。不要把那些檢視加在一起，然後稱總和為留言總數。

配對檢視有 8 行。C1、C2 和 C3 各有兩個成功方。C4 和 C5 只有貼文方。八不是留言總數。六才是留言總數。

C6 有兩個未解決部分和一列證據列。把它作為一則留言計一次。

逐項核對每個總數：

• 已選留言觀察：6。
• 左連接之後的證據列：6。
• 父貼文配對：5，即 C1、C2、C3、C4 和 C5。
• 未配對父項：1，即 C6。
• 配對到成功個人檔案的留言列：3，即 C1、C2 和 C3。
• 使用的成功個人檔案：2，即 member11 和 member12。
• 未解決的人士結果：2，即 C4 的失敗個人檔案，以及 C6 的缺失作者鍵。
• 在個人檔案範圍之外的組織作者：1，即 C5。
• 已識別的 member 鍵：3，即 member11、member12 和 member13。
• 這 3 個 member 鍵不是 2 個個人檔案，也不是 3 位已證實的人。
• 按父項計的已收集列：A 有 2，B 有 2，C 有 1，未配對父項有 1。
• 2 加 2 加 1 加 1 等於 6。

`commentsCount` 留在貼文列。如果你把它複製到每一則已收集留言，然後把複本相加，A 貢獻 10 兩次，B 貢獻 20 兩次。那是 20 加 40，即 60。已知的正確顯示總和對每則已選貼文只使用一次：10 加 20 等於 30。貼文 C 是 null。不要把 null 改成 0。不要稱 30 為完整。已收集的觀察量度是另一個：5 個已配對父項加 1 個未配對父項等於 6。

這張虛構表沒有 `OUTPUT`。真實涵蓋仍需要該次執行的 `pageCommentCount`、`publicRowsOnPage`、`savedRows`、`isPublicPageComplete`、`isComplete`、`stopReason`、`status` 和 `statusReason`。顯示計數為 10 而收集列為 2，本身並不是涵蓋率。

如果兩個 member12 快照都留在查閱表，C2 被複製，C3 也被複製。證據表由 6 列增至 8 列。先選 `time-2` 快照。證據表回到 6 列。若兩個快照仍留在查閱表，刪除那兩列額外證據列並不能修復下一次連接。

Member11 寫了兩則已選貼文 A 和 B，以及一則已選留言 C1。如果你把那兩則由其撰寫的貼文直接連到 member11 所寫的留言，C1 會出現兩次。在同時談論兩條分支之前，先分別計數。貼文作者分支有 2 則貼文。留言作者分支有 1 則留言。父項配對只把 C1 留在貼文 A。C1 配對 member11，是因為留言作者鍵是 member11，不是因為 member11 寫了貼文 A。

Member12 顯示允許的方向。一個已選個人檔案配對兩則留言。C2 留在 A。C3 留在 B。共用的個人檔案不會把任一則留言移到另一則貼文。

單是一個成功的貼文快照，不能證明留言集合是空的。只有已核對、成功、且已儲存列為零的留言輸入，才是已觀察的空結果。上限仍限制該結果。來源限制仍限制該結果。失敗的輸入保持未知。未嘗試的輸入保持未知。已觀察的空結果不是顯示為 null 的 `commentsCount`。六列例子的總數不改變。C6 是未配對的父鍵。它不是失敗的貼文嘗試。

還有三條虛構規則在這六列之外。不要把它們加進上文的總數。

member 鍵為 null 的人，在目前 `/in/` URL 完全相同時，可以配對一個已核對的個人檔案。寫下較弱的 URL 依據與兩個觀察時間。null URL 保持未解決。如果 member ID 指向 X 而 URL 指向 Y，保留衝突，不要使用該 URL。`commentId` 為 null 的留言保持為自己的觀察。相同文字不能修補缺失的 ID。試算表列號也不能修補它。

完成的檔案顯示什麼已配對、為何配對，以及什麼仍然未知。它不為人排名。它不判斷一則貼文是否成功。