Chronometrica 與 ScraperLink 比較：為何 1 頁 Google 結果看起來會重複

先確定你要計算的單位

資料集項目是 1 個已儲存的物件。它不一定代表 1 項搜尋結果。頁面物件可以在清單內包含多項結果。儲存在另一個物件內的清單，稱為巢狀陣列。

計算結果數量前，先確認每個儲存項目代表什麼。2 個物件可能以 2 種方式呈現相同的觀測紀錄。如果匯入程序同時展開這 2 種呈現方式，總數就可能超過你原本打算使用的觀測紀錄數量。

ScraperLink 的公開問題紀錄記載了讀者對結果重複的疑慮。這是已關閉的歷史問題。它能說明讀者為何提出這個問題，但不能證明目前存在程式錯誤或服務中斷。結果重複的歷史問題紀錄

本文使用的公開產品介面規格已於 2026 年 10 月 20 日核對。我們未在相同條件下執行資料擷取，也未檢查即時結果。本比較說明的是文件記載的輸入與輸出格式。

以下 3 種計數回答不同的問題：

• 資料集項目數：儲存了多少個物件？
• 結果觀測紀錄數：所選搜尋包含多少筆結果項目？
• 不重複的目標網頁數：這些項目中出現了多少個不同的目標網頁？

查看總數前，先選定計數方式。即使已儲存物件的數量算得正確，也仍可能無法正確回答搜尋結果有多少項。

直接修正目前的請求

請在提供的範例中使用以下 ScraperLink 輸入：

{
  "keyword": "Nike",
  "limit": "10",
  "page": 1,
  "include_merged": false
}

目前的公開輸入規格支援這些設定。請保留此處所示的 `limit` 字串格式。這個範例請求 1 個有範圍限制的頁面，並停用合併輸出。ScraperLink 預設建置版本與輸入結構描述

將 `Nike` 換成你要使用的查詢字詞。將輸出傳送至其他程式前，先檢查輸出。

找出所選頁面項目中的巢狀結果清單。計算清單內的項目數。接著檢查匯入程序讀取哪個物件，以及展開哪個清單。匯入程序應只使用預定的呈現方式 1 次。

不要將清單長度乘以已儲存物件的數量。先確認這些物件包含的是不同的觀測紀錄，還是相同觀測紀錄的不同呈現方式。

首次請求請保持小規模。目的是檢查輸出格式與計數規則。如果頁面項目已能用於下一步，你就已解決眼前的需求。只有在你確定另有目前流程無法滿足的需求後，才考慮更換工具。

比較下一步需要的輸出

驗收規則是輸出在使用前必須符合的條件。請用下表訂出這項規則。輸入設定列列出這些範例使用的設定；這不表示每個欄位都是必填欄位。

產品欄的內容依據目前文件記載的介面規格。ScraperLink Actor、Chronometrica Actor、Chronometrica 輸入結構描述

展開是指將巢狀清單中的每個項目轉成獨立的資料列。展開時，請保留每個項目所屬的搜尋情境。

如果展開步驟運作正常，可以繼續保留在流程中。選擇取決於接收資料的系統。如果它接受頁面物件，更換輸出格式可能沒有實際幫助。如果它需要個別的觀測紀錄，請決定要保留展開步驟，還是直接接收這種資料列格式。

虛構範例：2 個物件不能證明有 20 項結果

這是虛構範例。它不是產品測試、實測結果或客戶案例。

1 名分析人員請求 1 個頁面。在這個虛構範例中，原始頁面包含 10 筆巢狀結果觀測紀錄。可選用的合併物件重複包含相同的 10 筆觀測紀錄。

分析人員看到 2 個已儲存的物件。匯入程序將這 2 個物件都展開：

10 observations from the raw page
+ 10 repeated observations from the merged object
= 20 imported sightings

計算本身正確：10 + 10 = 20。但解讀錯了。這 1 個頁面應計算為 10 筆觀測紀錄。由於匯入程序使用了 2 種呈現方式，試算表中的每筆觀測紀錄都有 2 份。

分析人員停用合併輸出。接著只讀取原始頁面的結果清單 1 次，並檢查清單長度。在這個虛構範例中，這樣就能避免重複展開。

這個範例不能證明 Actor 擷取了同一頁面 2 次，或收費 2 次。單憑已儲存物件的數量，無法證明其中任何一種情況。

之後，當另一個 API 要求每個提交項目各代表 1 筆觀測紀錄時，分析人員需要再作選擇。該分析人員可以保留展開步驟，也可以選擇文件記載的輸出已符合該要求的 Actor。

Chronometrica 符合後續的資料列需求。虛構的總數不能證明它在資料擷取效能上有優勢。

何時適合使用 Chronometrica

Chronometrica 文件記載，每個資料集資料列代表 1 筆搜尋結果觀測紀錄，並包含搜尋引擎、查詢字詞、排名與情境。文件也記載了 `maxResultsPerExecutedQuery`，可為每個實際執行的搜尋引擎與查詢字詞組合設定結果資料列上限。Chronometrica Actor

請以提供的輸入範例作為起點：

{
  "queries": [
    "Nike"
  ],
  "engines": [
    "google"
  ],
  "maxResultsPerExecutedQuery": 10,
  "country": "US",
  "language": "en"
}

我們已依照目前的公開結構描述，核對鍵名、必填欄位、允許值、清單長度限制與數值範圍。這個範例尚未執行。Chronometrica 預設建置版本與輸入結構描述

這個上限只代表最多可回傳的數量。它不能證明請求一定會剛好回傳 10 筆觀測紀錄。報告數量前，請先檢查實際輸出。

這種格式適合每列儲存 1 筆觀測紀錄的試算表。它也適合要求每個提交項目各包含 1 筆觀測紀錄的 API。儲存單位與下一步需要的單位一致。

這種一致性讓你不必先展開巢狀結果清單。你仍需選擇系統使用的欄位、保留未知值，並檢查輸出。你也可能需要另外建立不重複的目標網頁清單。

如果這項已核對的格式符合需求，可選擇 Chronometrica。現有證據不能證明它在速度、可靠性、準確度或成本上有優勢。更換前，請先從目前的文件確認其他必要功能。

更換工具前，完成 5 項檢查

1. 查看目前的合併輸出設定。確認流程需要哪種輸出呈現方式。請將眼前的計數問題與之後的資料列格式選擇分開處理。
2. **使用 `include_merged:false` 請求 1 個有範圍限制的頁面。**記下完整的輸入。這樣就能將輸出對應至你請求的查詢字詞與頁面。
3. 計算巢狀結果項目的數量。檢查所選原始頁面的結果清單。確認匯入程序只讀取該清單 1 次。比較清單項目數與展開後建立的資料列數。
4. 定義下一步需要的單位。用 1 句話寫明，例如：「每個匯入的資料列，必須代表 1 組確切查詢字詞下的 1 項結果。」將這句話作為驗收規則。
5. 建立不重複的目標網頁清單前，先保留搜尋情境。保留搜尋引擎、確切查詢字詞、排名與可取得的時間資訊。凡是由你自己的流程記錄的時間，都應標示為自行記錄的時間。

這些檢查會幫助你作出 2 項決定。先判斷你能否正確計算目前輸出的數量。再判斷它的儲存單位是否適合下一個系統。

對手動處理的試算表來說，展開步驟可能容易檢查。對重複執行的匯入程序來說，直接使用結果資料列可能更符合接收系統的需求。認定能節省時間前，請先檢查流程實際需要哪些工作。

如果之後要比較成本，請另外定義計費單位。已儲存的物件、結果觀測紀錄與計費搜尋是不同的概念。合併輸出的總數不能證明計費搜尋次數，也不能證明價格優勢。

使用總數前，先檢查匯入程序

驗收規則必須具體到可以檢查。當總數不同時，「輸出看起來正確」幫助不大。實用的規則會指出來源清單、計數單位，以及每個匯入資料列必須保留的情境。

先查看所選輸出展開前的內容。計算其中預定使用的觀測紀錄數。接著檢查從該輸出建立的資料列。如果總數不同，請在刪除資料列前，先檢查匯入程序讀取了哪些物件與清單。

刪除重複網址的規則可能掩蓋計數錯誤的原因。它也可能刪除來自不同查詢字詞的有效觀測紀錄。請先修正輸出呈現方式的選擇。只有在需要另外計算不重複的目標網頁數時，才建立該清單。

請用清楚的文字記錄檢查結果。說明你計算的是頁面物件、觀測紀錄，還是目標網頁。這樣，即使他人未檢查過原始輸出，也能理解並使用這個總數。

區分觀測紀錄與不重複的目標網頁

同一個目標網頁可能出現在不同查詢字詞的結果中。即使這些結果指向同一個頁面，每次出現仍可能是不同的觀測紀錄。

不重複的目標網頁清單回答哪些頁面曾出現。觀測紀錄則記下每個頁面每次出現時所對應的查詢字詞與排名。如果 2 種答案都需要，請保留這 2 種輸出。

請從觀測紀錄建立目標網頁清單。保留這些紀錄，才能從目標網頁追溯至其搜尋情境。不要只因為某筆觀測紀錄的網址也出現在另一個查詢字詞下，就刪除該紀錄。

當 2 人報告的總數不同時，這項區分也有幫助。其中 1 人可能計算觀測紀錄，另 1 人則計算目標網頁。在認定總數互相矛盾前，請先說明計數單位。

如果之後需要合併不同執行批次的匯出資料，請參閱如何合併 Bing 搜尋匯出資料，同時保留查詢字詞與排名證據。該指南討論跨執行批次的合併。本比較則從更早的步驟開始，探討如何選擇輸出呈現方式與儲存單位。

匯入時保留未知值

缺少值不代表 0。缺失的排名不應變成排名 0。未知的數量不應變成已確認為 0 的數量。

請將未知值留空，或使用接收系統支援的缺失值格式。記錄這項選擇，避免後續計算將缺失資料視為實測結果。

時間也應遵守相同規則。不要編造來源時間戳記。如果你只知道自己的流程何時收到資料，請儲存該時間，並加上清楚的標示。

無論使用哪種輸出格式，都要檢查是否符合這些規則。獨立的資料列可能較容易讓接收系統接受，但仍需正確解讀。資料列數正確，不能證明每個欄位都有值，也不能證明每個值的意義都符合報告的假設。