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

如果你需要為每個關鍵字查詢擷取有上限的樣本，而且儲存的查詢詳情符合研究需求，可選擇 Chronometrica X Search Scraper。已查核的優點包括涵蓋起訖兩日的日曆日期輸入、產生的查詢原文、資料列位置，以及各查詢的獨立結果。如果你需要更豐富的作者、位置、媒體、最低互動量、語言或查詢精靈篩選條件，則選擇 Apidojo Tweet Scraper V2。[Chronometrica 文件](https://apify.com/chronometrica/x-search-scraper) · [Apidojo 文件](https://apify.com/apidojo/tweet-scraper)

選擇工具時，先確定必須收集哪些資料。收集少量貼文供檢閱，與要求收集所有符合條件的貼文，需要不同的控制方式。兩種需求可以使用相同的關鍵字與日期，但證明成功所需的證據不同。

本比較由 Chronometrica 發布。內容採用於 2026 年 10 月 20 日查核的公開產品證據。本文未執行資料收集。建議僅針對文件記載的輸入與輸出，不主張任何速度、成本、涵蓋範圍、準確度或可靠性優勢。

Actor 是在託管環境中執行的資料收集程式。在這次比較中，實用的問題是：哪個 Actor 能提供所需的篩選條件與紀錄，讓你判斷指定日期範圍內的關鍵字樣本是否合格。

## 依樣本驗收需求選擇

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

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

| 決策要點 | Chronometrica X Search Scraper | Apidojo Tweet Scraper V2 |
| --- | --- | --- |
| 關鍵字與日期搜尋 | 原生的日曆日期輸入，涵蓋起訖兩日 | 關鍵字搜尋及起訖時間控制 |
| 經查核的適用需求 | 需要明確查詢紀錄與資料列位置的有上限樣本 | 需要更多明確篩選條件的搜尋 |
| 相關控制項 | 1–20 個查詢；每個查詢可儲存 1–1,000 列 | 進階語法；作者、媒體、位置、互動量、語言及查詢精靈篩選條件 |
| 選擇原則 | 樣本上限與查詢紀錄符合研究需求時選用 | 需要用這些篩選條件界定樣本時選用 |

本表彙整已查核的公開文件。文件未記載某項功能，不代表該功能不存在。兩者都支援關鍵字與日期篩選。[Chronometrica 文件](https://apify.com/chronometrica/x-search-scraper) · [Apidojo 文件](https://apify.com/apidojo/tweet-scraper)

Apidojo 文件記載的大規模收集政策不包含單則推文擷取。這項限制不影響此處針對多筆結果搜尋的選擇。[Apidojo 文件](https://apify.com/apidojo/tweet-scraper)

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

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

Chronometrica 會為已儲存的資料列保留搜尋背景資料。`inputQuery` 記錄提供的查詢。`executedQuery` 記錄產生的查詢原文。`searchMode` 記錄所選模式。`resultPosition` 記錄該列在該次查詢中觀察到的位置。這些欄位能讓你把已儲存的貼文連結到產生該貼文結果的搜尋。[Chronometrica 文件](https://apify.com/chronometrica/x-search-scraper)

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

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

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

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

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

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

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

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

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

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

如需更完整的日期檢查方法，請參閱[如何依關鍵字與日期搜尋 X 貼文](/zh-Hant/articles/%E6%8C%89%E9%97%9C%E9%8D%B5%E5%AD%97%E5%8F%8A%E6%97%A5%E6%9C%9F%E6%90%9C%E5%B0%8B-x-%E5%B8%96%E6%96%87/)。本比較處理的是產品選擇：哪個 Actor 的篩選條件與輸出紀錄符合你的資料收集需求。

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

Chronometrica 文件記載可輸入 1–20 個查詢，提供 `latest`、`top`、`photos` 及 `videos` 模式，且每個查詢的儲存列數上限可設為 1–1,000 列。請先設定較小的上限，以便檢查每一列已儲存資料。[Chronometrica 文件](https://apify.com/chronometrica/x-search-scraper)

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

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

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

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

公開的 [X Twitter Search API Dataset Task](https://apify.com/chronometrica/x-search-scraper/examples/x-twitter-search-api-dataset) 提供初始預設值。Task 是為 Actor 儲存的輸入預設設定。查核時，該頁面傳回 HTTP 200，表示頁面回應成功。這項檢查並未確認目前儲存的輸入內容。

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

## 執行 5 步驗收檢查

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

1. 寫下資料收集需求。列出每個查詢的關鍵字、日曆日期、預定時區及可接受的樣本數量。說明你需要的是範例、有上限的比較樣本，還是所有符合條件的貼文。請在查看結果前完成。定義資料列的合格條件，包括必要的作者、媒體或其他篩選條件。
2. 選擇控制項並設定較小的上限。選擇文件所記載的篩選條件能滿足需求的 Actor。選用原生日期輸入或進階查詢運算子。檢查 Chronometrica 時，可從上方的小規模輸入開始。接受任何日期控制方式的組合前，先檢查產生的查詢。
3. 檢視實際查詢與貼文日期。閱讀 `executedQuery`，並與 `inputQuery` 比較。確認產生的查詢表達了預定的關鍵字與日期範圍。檢視每一列合格資料的 `createdAt`，也就是貼文建立時間戳記。將它與已檢查的時間戳記範圍比較，包括起訖兩個日曆日期界線。[Chronometrica 文件](https://apify.com/chronometrica/x-search-scraper)
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 文件](https://apify.com/chronometrica/x-search-scraper)

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

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

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

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

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

保留文件記載的搜尋背景欄位 `inputQuery`、`executedQuery`、`searchMode` 及 `resultPosition`。保留 `createdAt` 以檢查日期。在研究紀錄中加入觀察時間。[Chronometrica 文件](https://apify.com/chronometrica/x-search-scraper)

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

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

之後若要分析一起出現的詞語，請參閱 [X 貼文關鍵字共現分析](/zh-Hant/articles/%E6%89%80%E6%8F%90%E4%BE%9B%E7%9A%84-x-%E5%B8%96%E6%96%87%E6%A8%A3%E6%9C%AC-%E9%97%9C%E9%8D%B5%E8%A9%9E%E5%85%B1%E7%8F%BE%E5%88%86%E6%9E%90/)。先確定哪些觀察紀錄可用，再將分析方法套用到已明確說明的樣本。

## 選擇 Chronometrica，取得可供檢閱的樣本

當 Chronometrica 的每查詢樣本上限與明確查詢紀錄符合研究需求時，就選擇它。它明確適合已查核的需求：從指定日期範圍取得有限的關鍵字樣本，並保留足夠的背景資料，以檢視每個查詢的結果。

從 [Chronometrica X Search Scraper](https://apify.com/chronometrica/x-search-scraper) 開始。擴大收集前，先套用上方的輸入與驗收檢查。決策時，務必考量必要篩選條件何時會使你改選其他工具，以及儲存列數上限。最終研究主張的範圍，不得超出觀察紀錄能支持的範圍。

## 來源與延伸閱讀

- [Chronometrica X Search Scraper：公開文件與輸入結構描述；證據於 2026 年 10 月 20 日查核，快取建置版本為 0.1.30；支持本文所述的輸入限制、涵蓋起訖兩日的日期控制、搜尋背景欄位及逐一查詢的 OUTPUT 統計；範例已通過輸入結構檢查，本文未執行資料收集](https://apify.com/chronometrica/x-search-scraper)
- [Apidojo Tweet Scraper V2：公開文件與輸入結構描述；證據於 2026 年 10 月 20 日查核，快取建置版本為 0.0.1557；支持本文所述的搜尋控制項與單則推文政策；這是文件證據，並非相同條件下的效能比較測試](https://apify.com/apidojo/tweet-scraper)
- [Chronometrica X Twitter Search API Dataset Task：公開預設設定頁面於 2026 年 10 月 20 日查核；傳回 HTTP 200；頁面可用不代表已確認目前儲存的輸入，也不能證明資料收集成功；執行前請檢視並套用預定設定](https://apify.com/chronometrica/x-search-scraper/examples/x-twitter-search-api-dataset)
- [依關鍵字與期間收集資料的公開需求：納入於 2026 年 10 月 20 日查核的證據；支持買家對限定日期範圍收集資料的需求；具名產品比較是編輯選擇，該需求不能證明完整歷史涵蓋範圍、產品效能、成本或資料收集成功](https://www.reddit.com/r/webscraping/comments/19bekjv/is_there_a_current_solution_to_scrap_tweets)