# 已知 LinkedIn 貼文網址：Chronometrica 與 API Maestro 比較 如果你已有公開 LinkedIn `/posts/` 網址，而且需要記錄每次輸入嘗試，請選擇 Chronometrica。其文件所述的輸出包括 `inputUrl`、`status`、`statusReason`、`observedAt`，以及獨立的貼文識別欄位。這些欄位可協助你將來源清單與傳回的資料列逐一核對。缺少的公開計數會保留為 `null`。[Chronometrica LinkedIn Post Scraper](https://apify.com/chronometrica/linkedin-post-scraper) 如果你需要使用不含網址的貼文 ID，或需要其巢狀的作者與媒體輸出，請選擇 API Maestro。它透過 `post_urls` 接受貼文網址及不含網址的 ID。[API Maestro LinkedIn Post Detail](https://apify.com/apimaestro/linkedin-post-detail) Actor 是託管執行的資料收集程式。Chronometrica 是我們的 Actor。本比較針對一項特定需求推薦它：清楚記錄每個提供的貼文網址有何處理結果。這項建議以已查核的文件為依據，並非根據實測效能比較。 這 2 個 Actor 都適用於收集已知貼文的階段。如果你還沒有貼文連結，請先完成搜尋。接著依下一項工作的需要，選擇適合的輸入與輸出。擴大作業前，先用一份小清單檢查。 ## 哪個 Actor 符合你的需求？ 如果你首先想知道「我們提供的每個貼文網址有何處理結果」，Chronometrica 就適合你。其文件所述的輸入嘗試資料列，讓你能一併檢視可用紀錄與尚未解決的結果。獨立的 `activityId`、`ugcPostId` 及 `postUrn` 欄位會保留各貼文識別碼的類型。識別碼是用來指向某篇貼文的值。[Chronometrica 文件](https://apify.com/chronometrica/linkedin-post-scraper) 請用下表作初步選擇。表中說明的是已查核的文件內容，並非實測效能。 | 需求 | Chronometrica | API Maestro | | --- | --- | --- | | 已知貼文連結 | 已查核的輸入使用公開 `/posts/` 網址 | 接受貼文網址 | | 不含網址的貼文 ID | 不在已查核的輸入格式範圍內 | 可透過 `post_urls` 輸入 | | 輸入核對 | 文件說明每次輸入嘗試會有資料列，並明確記錄狀態 | 本次未測試失敗資料列的處理行為 | | 輸出結構 | 依識別類型分開的欄位，以及觀測時間 | 巢狀的作者、媒體、心情反應及貼文資料 | | 本次確認的輸入上限 | 未知 | 最多 1,000 筆 | 產品資訊來自已查核的 [Chronometrica 文件](https://apify.com/chronometrica/linkedin-post-scraper)及 [API Maestro 文件](https://apify.com/apimaestro/linkedin-post-detail)。 如果你需要在單次執行中處理超過 1,000 筆輸入，API Maestro 就不符合這項需求。[API Maestro 輸入文件](https://apify.com/apimaestro/linkedin-post-detail) 上限未知不代表容量無限。這些證據未能確認 Chronometrica 的最高上限。執行前，請依預定作業檢查實際設定。 也請先定義何謂完整結果。記錄每次輸入嘗試，與從每篇貼文取得可用文字，是不同的事。這 2 項產品經查核的公開文件，都無法證明它們能完整存取所有公開貼文。如果你必須從每個提供的網址取得可用文字，現有證據無法確認其中任何一項工具符合這項要求。 ## 為何輸入嘗試資料列很重要 內容審查需要可用的貼文文字。對於未能提供可用文字的輸入，也需要說明原因。只包含已接受內容的資料表，無法同時滿足這 2 項需求。 Chronometrica 文件所述的輸出可支援這項審查。請用 `inputUrl` 將資料列對應至提供的網址。閱讀 `status` 與 `statusReason`，了解回報的結果。保留 `observedAt`，讓後續審查人員知道觀測時間。[Chronometrica 輸出文件](https://apify.com/chronometrica/linkedin-post-scraper) 觀測時間與發佈時間的意思不同。發佈時間表示貼文何時發佈。觀測時間表示收集作業何時記錄貼文狀態。請在紀錄中保留這項區別。 貼文識別資訊也需要謹慎處理。請保留 `activityId`、`ugcPostId` 及 `postUrn` 的原始欄位名稱。不要將它們合併為一個沒有標籤的值，並假定它們意思相同。分開的欄位能保留資訊，這些資訊在日後連結紀錄時可能很重要。[Chronometrica 輸出文件](https://apify.com/chronometrica/linkedin-post-scraper) 完全相同的重複輸入字串只會檢查 1 次。同一篇貼文的不同網址形式，可能產生不同的嘗試紀錄。這是依字串完全相同與否來處理重複輸入。它不保證會將指向同一篇貼文的所有連結合併。[Chronometrica 輸入文件](https://apify.com/chronometrica/linkedin-post-scraper) 這項區別會影響預期的資料列數。請計算工作用輸入清單中不重複的字串數量；只有完全相同的字串才算重複。除非已另外查核貼文識別資訊，否則不要使用假定的不重複貼文數。保留原始清單，才能說明準備過程中的變動。 這些紀錄有助於回答一個實際問題：為何已接受內容表的資料列數少於提供的清單？已記錄的結果能說明原因，無須事後嘗試重建收集過程。 ## 依 5 個步驟進行驗收檢查 驗收檢查用來判斷收集到的每筆資料列是否符合你所列的需求。請在完整作業前定義規則。執行完成本身，並不能證明資料列適合你的工作。 1. 備妥確切的輸入清單。 保留一份原始網址。建立工作用清單，移除完全相同的重複字串。記錄此步驟前後的項目數。用工作用清單設定預期的嘗試次數。 使用 Chronometrica 時，請輸入公開 `/posts/` 網址。只有這種網址格式符合已查核的輸入證據。依本方法操作時，不要改用 `/feed/update/` 網址。如果多個連結似乎指向同一篇貼文，請保留此問題，留待審查。不要假定 Actor 會合併這些連結。[Chronometrica 輸入文件](https://apify.com/chronometrica/linkedin-post-scraper) 1. 定義可接受的資料列必須包含哪些內容。 列出下一項工作需要的欄位。內容編碼是為內容加上標籤，以供分析。這項工作需要可用文字與來源網址。輸入核對還需要每次嘗試的結果。日後比對紀錄時，可能需要現有的各類貼文識別碼。 請為你的工作定義何謂可用文字。短貼文也可能完整且有用。文字為空時，必須先審查，再進行內容分析。不要只依文字長度決定是否接受。請先決定缺少計數是否會阻礙工作，或沒有該計數仍可使用文字。 1. 用一份小清單核對傳回的結果。 選擇少量輸入，確保你能逐列檢查。檢查前先設定數量上限。使用所選 Actor 的實際設定。這項檢查用來判斷文件所述的行為是否適合你的工作，無法據此確認一般成功率。 使用 Chronometrica 時，請透過 `inputUrl`，將嘗試紀錄對應至工作用清單。閱讀 `status` 與 `statusReason`。依驗收規則檢查傳回的文字。這些文件所述的欄位，可支援輸入與結果的核對。[Chronometrica 輸出文件](https://apify.com/chronometrica/linkedin-post-scraper) 如果輸入與輸出總數不同，請查明原因。檢查完全相同的重複字串、網址形式及回報的結果。不要編造成功或失敗紀錄，來填補原因不明的缺口。 1. 將未知計數與 0 分開處理。 0 是已知數值。計數為 `null` 表示缺少該值。Chronometrica 文件說明，缺少的公開計數會保留為 `null`。匯出或計算結果時，請保留這項區別。[Chronometrica 計數處理方式](https://apify.com/chronometrica/linkedin-post-scraper) 不要將缺少計數描述為沒有活動。如果要計算平均值，請說明有多少筆紀錄的值已知。不要將缺少的計數改為 0。文字為空的情況應另外審查：計數已知，並不能證明該資料列包含分析所需的內容。 1. 匯出已接受的內容，並保留排除項目的結果。 將通過規則的資料列放入內容表。保留來源網址與觀測時間。將被排除的輸入結果存入另一份稽核表。稽核表用來記錄你檢查了什麼，以及接受或排除各項目的原因。 請使用這些驗收欄位：`inputUrl`、解析後網址、附類型的貼文識別資訊、`status`、文字可用與否、`observedAt`，以及接受或需審查的原因。這些是審查欄位，不表示每個欄位名稱都是 Actor 的輸出欄位。請保留未知值，不要編造解析後網址或識別碼。 確認已接受與已排除的結果合計涵蓋工作用輸入清單。保留每項排除原因。後續審查人員應能分辨缺少文字、輸入無法存取，以及嘗試失敗等情況，無須猜測。 ## 檢查前先備妥輸入 [LinkedIn 貼文文字與互動資料 Task](https://apify.com/chronometrica/linkedin-post-scraper/examples/linkedin-post-text-engagement-data) 提供可作為起點的預設輸入。Task 是已儲存的輸入預設組態。為本次研究任務說明進行查核時，其公開頁面傳回 HTTP 200。這確認了當時頁面可供存取，但未驗證 Task 目前儲存的輸入。執行前，請檢查輸入，並套用目前結構定義中的設定。 結構定義會列出允許的輸入欄位與值。以下輸入已依儲存的公開結構定義，通過本機格式檢查。其中的欄位名稱存在於該結構定義中。這項檢查未證明來源貼文可供存取。未為本次研究任務說明執行資料收集作業。[Chronometrica 輸入文件](https://apify.com/chronometrica/linkedin-post-scraper) ```json { "startUrls": [ "https://www.linkedin.com/posts/timferriss_i-took-my-whole-genome-dumped-it-into-ai-activity-7333162625675038720-TJPX" ] } ``` 檢查前先備妥輸入 範例網址來自儲存的公開結構定義或範例。請將它替換為你打算使用的公開來源。不要將它視為新收集的結果。 已查核的結構定義要求 `startUrls` 必須是至少包含 1 個項目的陣列。陣列是一組值的清單。這項最低要求不能用來確認輸入數量上限。首次檢查請使用小份工作用清單，再將傳回的資料列與保留的清單核對。[Chronometrica 輸入結構定義](https://apify.com/chronometrica/linkedin-post-scraper) 即使預設組態的名稱符合你的工作，也請檢查其內容。頁面檢查與輸入格式檢查回答的是不同問題。前者關乎公開頁面，後者關乎允許的輸入結構。兩者都不能取代收集後的資料列驗收檢查。 ## 以 12 個網址作選擇的虛構範例 以下範例純屬虛構。它不是 Actor 測試、客戶成果、買方引述，也不是實測成本比較。 一位研究人員有 12 個不重複的網址字串，重複與否以字串是否完全相同為準。這項作業需要貼文文字來進行內容編碼，也需要記錄每次輸入嘗試。這項需求符合 Chronometrica 文件所述的輸入核對優勢。 在這次虛構檢查中，9 筆資料列包含可用文字。2 筆資料列說明輸入無法存取。1 筆資料列說明嘗試失敗。研究人員保留全部 12 筆輸入嘗試資料列，但只接受其中 9 筆可用資料列進行內容編碼。 計算如下： - 9 筆可用資料列 + 2 筆輸入無法存取的資料列 + 1 筆嘗試失敗的資料列 = 12 次輸入嘗試。 - 9 ÷ 12 = 75%，即本次虛構檢查中可用資料列的比例。 75% 只描述這些虛構結果。它不是產品成功率。這 12 次嘗試也不代表 12 筆成功付費結果。依 Chronometrica 文件所述的契約，失敗嘗試不算成功付費結果。[Chronometrica 文件](https://apify.com/chronometrica/linkedin-post-scraper) 研究人員現在有 2 份有用的紀錄。內容表可支援 9 篇貼文的分析。稽核表則說明為何另外 3 筆輸入未納入分析。保留兩份紀錄，可避免他人以為原始清單只有 9 篇貼文。 這 9 筆已接受的資料列可能適合內容編碼，但從全部 12 筆輸入取得可用文字的原始要求仍未達成。符合其中一項用途的驗收標準，不會消除這個缺口。研究人員分享結果時，必須清楚保留這項區別。 如果作業改以不含網址的 ID 開始，而且只需要解析後的詳細資料紀錄，API Maestro 可能更適合。[API Maestro 文件](https://apify.com/apimaestro/linkedin-post-detail) ## 證據能確認什麼 產品證據收集於 2026 年 10 月 20 日。查核的建置版本為 Chronometrica 1.0.60 及 API Maestro 0.1.18。這些是特定日期的文件查核結果。本文未新增在相同條件下進行的對照測試。[Chronometrica 公開契約](https://apify.com/chronometrica/linkedin-post-scraper)、[API Maestro 公開契約](https://apify.com/apimaestro/linkedin-post-detail) 這些證據可支援依文件所述的輸入與輸出行為作選擇。但無法支持成本更低、收集更快、準確度更高或可靠性更好的主張。對於另一項產品，本次未測試失敗資料列或資料遺失缺陷。文件未記載的行為仍屬未知。 買方需求也有明確範圍。一則公開討論詢問如何收集 LinkedIn 貼文，供潛在客戶開發機器人使用。該討論未要求比較這些供應商，也未要求核對輸入與結果。本文將該收集需求調整為讀者已有公開貼文連結的階段。選擇比較這 2 項產品，是我們的編輯決定。本文不保證取得合格潛在客戶、找到個人檔案或進行對外聯繫。[LinkedIn 貼文收集的公開討論](https://www.reddit.com/r/learnprogramming/comments/1fi1zf5/how_do_you_scrape_linkedin_posts_now_that_the) 收集完成後，評估貼文中的主張是另一項工作。請搭配已接受的文字與來源網址，參閱[如何比較 LinkedIn 貼文中的主張與佐證](/zh-Hant/articles/%E6%AF%94%E8%BC%83-linkedin-%E5%B8%96%E6%96%87%E4%B8%BB%E5%BC%B5%E8%88%87%E6%94%AF%E6%8C%81%E8%AD%89%E6%93%9A/)。該指南檢視內容中的證據。本比較則用來選擇收集工具，並定義開始分析前所需的檢查。 ## 從 Chronometrica Actor 開始 如果你已有公開 `/posts/` 網址清單，而且需要清楚記錄每次輸入嘗試，請選擇 Chronometrica。其文件所述的狀態欄位與獨立貼文識別碼符合這項需求。擴大作業前，請先用一份小清單套用上述驗收方法。 開啟 [Chronometrica LinkedIn Post Scraper Actor](https://apify.com/chronometrica/linkedin-post-scraper)，檢查目前的輸入設定，並開始檢查。保留已接受的內容與被排除的結果，讓成果同時說明已收集到什麼，以及哪些項目仍須審查。 ## 來源與延伸閱讀 - [Chronometrica LinkedIn Post Scraper：公開契約與輸入結構定義；證據收集於 2026 年 10 月 20 日，查核的建置版本為 1.0.60；文件記載輸入嘗試資料列、inputUrl、status、statusReason、observedAt、獨立的貼文識別欄位、缺少計數保留為 null、完全相同字串的重複處理方式，以及失敗嘗試在付費上的區別；範例輸入通過本機結構定義檢查，但未執行收集作業或完整存取測試](https://apify.com/chronometrica/linkedin-post-scraper) - [API Maestro LinkedIn Post Detail：公開契約與輸入結構定義；證據收集於 2026 年 10 月 20 日，查核的建置版本為 0.1.18；文件記載網址或不含網址的 ID 輸入、1,000 筆輸入上限，以及巢狀詳細資料輸出；未進行相同條件下的效能對照測試、失敗資料列測試或資料遺失測試](https://apify.com/apimaestro/linkedin-post-detail) - [Chronometrica LinkedIn 貼文文字與互動資料 Task：可作為起點的輸入預設組態；2026 年 10 月 20 日研究任務說明所記錄的公開頁面檢查傳回 HTTP 200；頁面可供存取，並不能驗證目前儲存的輸入，執行前仍須檢查；未為本次研究任務說明執行作業](https://apify.com/chronometrica/linkedin-post-scraper/examples/linkedin-post-text-engagement-data) - [LinkedIn 貼文收集的公開討論：2026 年 10 月 20 日研究任務說明使用的已儲存來源，詢問如何為潛在客戶開發機器人收集貼文；已知網址工作流程是編輯調整，該討論未提及其中任何一家供應商，也未提供已驗證的效能基準；本文未聲稱進行新的即時查核](https://www.reddit.com/r/learnprogramming/comments/1fi1zf5/how_do_you_scrape_linkedin_posts_now_that_the)