Chronometrica 與 Tweet Scraper V2：哪個適合查詢 1 篇已知的 X 貼文？

收費問題告訴我們什麼

Store 中一則已結案的過往問題記錄顯示，有位買家只有 1 個已知貼文網址，卻對標示為每 1,000 筆結果 $0.40 的收費提出疑問。這個金額屬於那則過往問題。它無法證明今日的價格，無法說明整筆帳單，也無法證明使用另一款產品會花多少錢。這則問題也不能證明目前有服務故障。過往買家提問

再次執行前，真正有用的問題是：所選產品是否支援你要提交的確切工作？

提供 1 個網址，代表你要進行查詢。你已經知道需要哪篇貼文。你想觀測它在指定時間的文字和公開計數。你不需要收集工具找出一組符合條件的貼文。

探索貼文是另一種工作。你提供主題、個人檔案或清單，是因為你需要找出貼文。這種工作可能需要不同的輸入、限制和計費單位。適合探索貼文的產品，不一定適合單一已知網址。

Actor 是在 Apify 上託管執行的資料收集程式。執行前，請分別檢查 3 件事：它支援的用途、輸入欄位，以及現行收費條款。有效的輸入欄位只能回答其中 1 個問題。

本文無法根據已保存的提問計算當時的帳單。但本文可以協助你選擇支援所需用途的收集工具，並在使用結果前完成檢查。

先比較支援的工作

使用這張表選擇做法。付款前，再檢查目前的產品頁面。

資料來源：Chronometrica、V2、Unlimited。

不要只根據 `startUrls` 這個欄位名稱做選擇。JSON 輸入結構定義會規定允許的欄位名稱、類型和值。它不能取代產品的支援用途規則。陣列可以容納網址，並不代表產品支援所有類型的網址。

這張表比較的是文件記載的適用程度。它沒有對速度、準確度、可靠性、涵蓋範圍或實際觀測成本進行排名。本文所提供的證據不足以支持這些排名。

Chronometrica 能為這項需求提供什麼

Chronometrica 接受包含 1 至 1,000 個公開 X 或 Twitter 貼文網址的 `startUrls` 清單。其文件記載的輸出會為每個嘗試處理的輸入保留 1 筆快照，包含可取得的文字、可取得的公開計數、結果狀態和觀測時間。缺失的計數會維持缺失。輸入與輸出規格

輸入嘗試快照，是嘗試觀測指定貼文的記錄。不能將它理解為保證每次嘗試都會傳回完整文字和計數。

這項區別讓輸出適合用來檢查已知貼文。你需要知道收集工具觀測到什麼，也需要知道這次觀測是否足以支援你的預定用途。計數若沒有附上可用狀態，可能會讓人誤以為資料已經確定。

例如，報告可能需要貼文文字和 1 項公開計數。如果文字可取得，但計數缺失，文字可能仍能滿足其用途。報告中的數值部分則仍不完整。分別判斷這 2 件事，可以避免將部分結果寫成看似完整的報告。

文件列明的清單上限也很重要。如果你需要在單次執行中提供超過 1,000 個網址，這個 Actor 就不符合需求。不要將文件記載的上限描述成無限量收集。較大的專案需要另外規劃，包括檢查重複網址，並確保觀測時間一致。輸入上限

此處選擇 Chronometrica 的理由很明確：支援的輸入符合已知網址的需求，而文件記載的資料列保留了判斷這次嘗試所需的狀態。

以 1 篇貼文為例的虛構決策

以下範例為虛構情境。它不是客戶成果、Actor 測試、即時資料集或成本實測。

分析師 Maya 有 1 個行銷活動貼文網址。她需要公開文字和可取得的計數，用於今天準備的報告。她不需要搜尋其他活動貼文。

她在選擇收集工具前寫下需求：「嘗試擷取這 1 篇公開貼文。保留結果狀態、可取得的欄位、來源網址和觀測時間。」

Chronometrica 文件記載的快照輸出符合這項需求。Maya 也將 Unlimited 留在候選清單中，因為這是開發者支援的單篇貼文處理方式。Chronometrica、Unlimited

她的驗收檢查分成 2 部分。第 1 部分：這次執行是否記錄了目標貼文？第 2 部分：報告所需的欄位是否可取得？同一筆資料可能通過第 1 項檢查，卻未通過第 2 項。如果必要計數無法取得，Maya 會在報告中將它保留為 null，並標示該部分未完成。

到了下週，她的需求改變了。她必須依關鍵字找出 200 篇貼文。由於新工作是探索貼文，她重新評估 V2。先前針對單篇貼文的選擇，不能直接決定這次該選什麼。V2 支援的用途

這些數字能說明的事情有限：1 個已知網址代表 1 次查詢請求；需要找出 200 篇貼文則是另一種工作。這 2 個數字都無法預測費用、傳回的資料列數、速度或是否成功。

大量執行前，先做小規模驗收

驗收檢查的目的是確認輸出是否能支援你的特定報告。它不需要大型測試資料集。先準備目標公開網址，以及一份簡短的必要欄位清單。

1. 用清楚的文字寫下需求

記錄確切的貼文網址。列出每個必要的公開欄位。將必備欄位與有幫助但非必要的欄位分開。

例如，你的報告可能必須有文字和觀測時間，但將部分公開計數視為選填。另一份報告可能必須有某項特定計數。即使使用相同網址，這些報告的驗收條件也不同。

也要說明你需要目前的觀測結果，還是過去的數值。目前的查詢無法還原貼文上個月的計數。如果需求涉及過去的數值，請在選擇收集工具前說明。

2. 檢查支援用途與現行計費單位

閱讀目前的產品規則。接著，檢查預定執行工作的現行價格。確認什麼情況會產生費用，以及列明的計費單位如何套用至你的輸入。

不要將過往問題中的金額用於這次計算。不要假設 1 個網址一定代表 1 筆付費結果，也不要以為熟悉的欄位名稱就能定義計費單位。如果現行條款無法回答你的問題，請先釐清，再執行。

價格與適用性需要分別檢查。產品即使價格明確，也可能不符合你的輸入需求。產品即使支援你的用途，仍須檢查成本是否符合預算。

3. 檢查 Task 儲存的輸入

Task 是儲存在 Apify 上的預設輸入設定。Chronometrica 提供公開的 X 貼文分析快照 Task。

開啟 Task，檢查實際輸入。公開 Task 頁面只是起點。有這個頁面，不代表其中儲存的網址就是你的目標。

以下最精簡的輸入符合已核對的公開結構定義：

{
  "startUrls": [
    "https://x.com/OpenAI/status/2077446718728425686"
  ]
}

將範例網址換成你的目標公開貼文。這個範例展示輸入格式。它不是收集結果，也不能證明範例貼文目前仍可存取。結構定義允許 `startUrls` 陣列至少包含 1 個項目，最多包含 1,000 個項目。公開輸入結構定義

提供的輸入已通過已保存公開結構定義的檢查。這項檢查確認欄位及清單格式符合規定。它不能確認實際的即時收集嘗試會成功。

4. 使用數值前，先檢查擷取嘗試

完成一次預定的小規模執行後，檢查 `status`、`statusReason` 和 `postMetricStatus`。將這些狀態與傳回的文字和計數一併閱讀。核對解析後的貼文識別資訊，確認它就是你原本要收集的貼文。文件記載的輸出

不要因為有 1 筆資料列，就認為所有必要欄位都已收集。依照第 1 步寫下的驗收條件，逐一檢查每個必要欄位。

報告中無法取得的數值應保留為 null。不要將它們改成 0。0 是一個數值。null 表示你沒有可用的數值。將 null 改成 0，可能會改變總計、比較結果和結論。

5. 保留來源與觀測時間

為嘗試處理的輸入儲存 1 筆記錄。將來源網址、解析後的貼文識別資訊、嘗試狀態、指標可用情況和觀測時間保存在一起。

若文件有列明 Actor 傳回的欄位名稱，請使用這些名稱。如果報告系統需要其他欄名，請保留清楚的對照。不要自創 API 欄位名稱，再將它說成 Actor 規格的一部分。

若要衡量後續變化，請再收集 1 份經過檢查的快照。只有在 2 次觀測都包含可用數值時，才能比較同一篇貼文的相同欄位。

將快照視為一次觀測，而非歷史記錄

目前的公開計數只能回答特定時間點的問題：這次嘗試觀測貼文時，可取得的數值是多少？它無法說明這個計數如何演變。

2 份經過檢查的快照可以用來計算變化。如果兩者都包含必要計數，就用較晚的數值減去較早的數值。將 2 次觀測時間保留在結果旁。這個差值描述的是這 2 次觀測之間的變化。

只要任一數值缺失，變化就無法確定。不要用 0 填補缺值，也不要在未說明規則的情況下沿用先前數值，或將差值描述成實測成長。缺少觀測資料，會改變你能得出的結論。

貼文文字也可能缺失或不完整。在引用、分類或用它辨識活動用語前，請先檢查。收集工具的輸出是報告的輸入資料，因此報告仍需要驗收檢查。

這篇比較文章不保證能提供封存資料、還原舊指標，或取得歷史關鍵字頻率。這些需求需要不同的證據。公開與私人報告落差指南 提供相關的報告背景。若要分析一組指定貼文文字，請參閱另一篇關鍵字共現指南。這個方法回答哪些詞語會一起出現；它不會替已知網址選擇收集工具。