Chronometrica 與 Apidojo Tweet Scraper：X 關鍵字與日期研究比較

依樣本驗收需求選擇

一則公開買家需求要求依關鍵字收集特定期間的 X 資料。這支持按日期範圍收集資料的需求，但不能證明買家需要完整的歷史封存，或所有符合條件貼文的精確總數。本文比較這兩項具名產品，是我們的編輯選擇。該需求並非經驗證的產品基準測試。公開買家需求

選擇 Actor 前，先寫下簡短的驗收說明。例如：「每個關鍵字最多需要 10 則附有日期的貼文，並保留足夠的搜尋背景資料，以便檢查各個樣本。」這能提供實際的決策依據。你可以檢查輸入是否表達了需求，以及輸出是否保留了證據。

本表彙整已查核的公開文件。文件未記載某項功能，不代表該功能不存在。兩者都支援關鍵字與日期篩選。Chronometrica 文件 · Apidojo 文件

Apidojo 文件記載的大規模收集政策不包含單則推文擷取。這項限制不影響此處針對多筆結果搜尋的選擇。Apidojo 文件

Chronometrica 的主要限制是儲存列數上限。如果你需要所有符合條件的貼文，而其中任何查詢需要儲存超過 1,000 列，Chronometrica 就無法滿足這項需求。即使需求低於上限，仍需要涵蓋範圍的證據。允許的輸入規模，不能證明來源會傳回所有符合條件的貼文。Chronometrica 文件

為何 Chronometrica 適合有上限的關鍵字樣本

Chronometrica 會為已儲存的資料列保留搜尋背景資料。`inputQuery` 記錄提供的查詢。`executedQuery` 記錄產生的查詢原文。`searchMode` 記錄所選模式。`resultPosition` 記錄該列在該次查詢中觀察到的位置。這些欄位能讓你把已儲存的貼文連結到產生該貼文結果的搜尋。Chronometrica 文件

比較關鍵字時，這種連結很重要。兩個查詢可以使用相同的日期範圍與列數上限，卻傳回不同數量的合格資料列。請分別保留這些結果。否則，合併匯出的資料可能讓你無法看出哪個查詢達到上限，哪個查詢傳回較少的資料列。

Chronometrica 也在文件中說明了逐一查詢的 `OUTPUT` 統計，也就是每個查詢所報告的結果。請搭配已儲存的資料列閱讀。資料列檔案顯示你收集了什麼。查詢結果則協助你評估這次收集是否符合需求。Chronometrica 文件

只能在這個背景下使用 `resultPosition`。它是單次查詢的觀察值，並非固定排名、品質分數，也不能證明貼文代表該主題。保留它是為了檢視樣本順序。不要用它衡量貼文的重要性。Chronometrica 文件

當研究者需要有限數量的貼文來閱讀、標記或比較時，這些功能很適合。這些紀錄有助於研究者說明觀察到的內容。研究者仍須判斷，這些觀察是否足以支持預定的分析。

收集前先明確界定日期範圍

Chronometrica 接受選填的 `startTime` 與 `endTime` 輸入，以涵蓋起訖兩日的日曆日期表示。文件記載的處理流程會加入可見的日期篩選條件，並再次檢查傳回貼文的日期。同一個使用原生日期輸入的請求，不要再加入 `since:` 或 `until:` 運算子。Chronometrica 文件

涵蓋起訖兩日，表示請求包含指定的起始與結束日曆日期。但你仍須界定研究使用的時區。單靠日曆日期，無法說明哪些時段屬於當地報告日。

執行搜尋前，先記錄預定使用的時區。需要時，將預定的起訖時間界線轉換為世界協調時間（UTC）。UTC 是比較時間戳記時常用的時間基準。請針對研究中的日期檢查轉換結果。檢視傳回的貼文時，使用這些已檢查的時間戳記。

請一併保留請求的兩個部分：原始的日曆日期需求（包含起始日與結束日），以及判斷資料列是否合格所用的精確時間戳記範圍。這樣其他讀者就能理解輸入內容，以及你如何判斷貼文是否屬於研究範圍。

初步檢查時，選擇一種日期控制方式。如果原生日期輸入能表達需求，就使用它。如果改用進階查詢運算子，請先檢視產生的查詢，再接受結果。未檢查兩種方式如何影響該查詢前，不要將它們合併使用。

如需更完整的日期檢查方法，請參閱如何依關鍵字與日期搜尋 X 貼文。本比較處理的是產品選擇：哪個 Actor 的篩選條件與輸出紀錄符合你的資料收集需求。

準備可逐一檢查的小規模輸入

Chronometrica 文件記載可輸入 1–20 個查詢，提供 `latest`、`top`、`photos` 及 `videos` 模式，且每個查詢的儲存列數上限可設為 1–1,000 列。請先設定較小的上限，以便檢查每一列已儲存資料。Chronometrica 文件

以下輸入要求針對 1 個關鍵字，儲存最多 10 列 2026 年 1 月的資料。它使用原生日期輸入與 `latest` 模式。

{
  "queries": [
    "artificial intelligence"
  ],
  "searchMode": "latest",
  "maxItemsPerQuery": 10,
  "startTime": "2026-01-01",
  "endTime": "2026-01-31"
}

這組輸入已在本機通過快取公開 JSON Schema 的檢查。JSON Schema 定義允許的輸入欄位與值。所有提供的欄位名稱都存在於該結構描述中。這確認了輸入結構，但不能證明即時來源可用，也不保證會傳回 10 列。Chronometrica 公開輸入結構描述

公開的 X Twitter Search API Dataset Task 提供初始預設值。Task 是為 Actor 儲存的輸入預設設定。查核時，該頁面傳回 HTTP 200，表示頁面回應成功。這項檢查並未確認目前儲存的輸入內容。

每次執行前，請開啟 Task 輸入並套用預定設定。將範例關鍵字與日期替換成研究所需的值。首次檢查時，維持較小的上限。上方範例是輸入範例，並非收集結果。

執行 5 步驗收檢查

使用以下步驟，判斷所選 Actor 是否產生可用的樣本。

1. 寫下資料收集需求。列出每個查詢的關鍵字、日曆日期、預定時區及可接受的樣本數量。說明你需要的是範例、有上限的比較樣本，還是所有符合條件的貼文。請在查看結果前完成。定義資料列的合格條件，包括必要的作者、媒體或其他篩選條件。
2. 選擇控制項並設定較小的上限。選擇文件所記載的篩選條件能滿足需求的 Actor。選用原生日期輸入或進階查詢運算子。檢查 Chronometrica 時，可從上方的小規模輸入開始。接受任何日期控制方式的組合前，先檢查產生的查詢。
3. 檢視實際查詢與貼文日期。閱讀 `executedQuery`，並與 `inputQuery` 比較。確認產生的查詢表達了預定的關鍵字與日期範圍。檢視每一列合格資料的 `createdAt`，也就是貼文建立時間戳記。將它與已檢查的時間戳記範圍比較，包括起訖兩個日曆日期界線。Chronometrica 文件
4. 閱讀每個查詢的結果。比較已儲存列數、要求的上限及報告的結果。查詢達到上限時，標記為已達上限。有證據支持時，將結果標記為部分結果。明確保留尚未釐清原因的數量不足情況。未知值仍應保留為未知，不要將缺漏資料改成 0。
5. 分別驗收並匯出各查詢樣本。保留 `resultPosition`，並記錄觀察時間，也就是收集樣本的時間。這與貼文建立時間不同。保留原始日期需求，以及查詢達到上限或僅有部分結果的註記。只有在能說明要求了什麼、觀察到什麼，以及適用哪些限制時，才開始分析。

某個查詢儲存的資料列較少，不代表整個 X 上符合條件的貼文必然較少。請將查詢結果視為該次收集的證據。如果無法表達某項必要的篩選條件，請先解決產品選擇問題，再收集更大的樣本。

驗收檢查也能提供明確的停止規則。當必要的控制項運作正常，而且已儲存的紀錄能支持預定用途時，就可以繼續。如果其中任一項檢查失敗，單純增加收集量無法解決問題。

虛構的雙關鍵字決策範例

這是虛構範例。它不是 Actor 測試、即時資料集、買家引言，也不是實測成本結果。

一名研究者想針對 2 個關鍵字分別查詢 1 月的貼文，關鍵字為「artificial intelligence」與「machine learning」。目的是收集範例供人工檢閱。研究者接受每個查詢最多儲存 10 列，並在收集前記錄預定時區。

未考慮其他限制前，要求的樣本數上限為：

`2 queries × 10 rows per query = at most 20 saved rows`

在這個虛構結果中，第 1 個查詢傳回 10 列符合日期條件的合格資料。第 2 個查詢在公開來源沒有更多結果前，傳回 6 列符合日期條件的合格資料。研究者保留：

`10 + 6 = 16 observed rows`

研究者也保留 2 個查詢的結果。第 1 個查詢達到上限。第 2 個查詢在未達上限時停止。合併資料列時，不得抹除這項差異。

對這項需求而言，Chronometrica 是合適的選擇。研究者接受有上限的樣本，並需要原始查詢、產生的查詢、資料列位置及各查詢的獨立結果。這些紀錄讓研究者能依照已聲明的需求檢視收集結果。Chronometrica 文件

研究者可以描述觀察到的 16 列資料內容，但不能據此斷定第 1 個主題在整個 X 上出現得更頻繁。列數上限與不同的查詢結果，無法確立母體頻率，也就是每個主題在全部貼文中出現的頻率。

如果需求改成取得 1 月所有符合條件的貼文，研究者必須另行評估這項新需求。小規模樣本成功，不代表能完整收集。如果取得所有結果的需求超過 Chronometrica 的每查詢上限，這個 Actor 就無法滿足需求。

將查詢紀錄與貼文觀察紀錄分開保存

使用一份查詢管理表記錄請求及其結果。這是你的研究紀錄，並非對 Actor 匯出格式的說明。每個查詢都應保留原始關鍵字文字、涵蓋起訖兩日的日期需求、預定時區、所選模式、要求的上限、已儲存列數及報告的結果。

另外保存貼文觀察紀錄，並以 `postId` 與 `executedQuery` 作為鍵值。鍵值是用來識別一筆紀錄的一組值。保留每則貼文與產生該貼文結果的查詢之間的連結。

保留文件記載的搜尋背景欄位 `inputQuery`、`executedQuery`、`searchMode` 及 `resultPosition`。保留 `createdAt` 以檢查日期。在研究紀錄中加入觀察時間。Chronometrica 文件

同一則貼文可能出現在多個查詢樣本中。發生這種情況時，請保留這些查詢連結。它們能說明貼文為何進入各個樣本。如果之後要計算不重複貼文數，請另行說明計算方式，並與已儲存的查詢觀察紀錄數量區分。

這種結構有助於避免常見錯誤：將所有匯出資料列呈現為一個未附限制說明的總數。合併檔案可能包含已達上限的樣本、部分樣本及重複貼文。查詢紀錄讓你能在作出結論前，先說明這些差異。

之後若要分析一起出現的詞語，請參閱 X 貼文關鍵字共現分析。先確定哪些觀察紀錄可用，再將分析方法套用到已明確說明的樣本。