定期追蹤 Instagram 創作者指標：Chronometrica 與 WebDataLabs Instagram Posts and Reels 比較

先釐清應用程式的定期更新需求

一則關於網紅追蹤應用程式的公開討論，詢問如何將定期資料收集接到 Replit，包括該使用 webhook 還是定時 API 輪詢。相關需求是更新他人網紅貼文的公開指標。這是有參考價值的整合問題，不是對供應商的背書，也不是經過驗證的產品測試。讀者討論

本次比較涵蓋的量測項目是公開按讚數、留言數，以及可取得的瀏覽次數或播放次數。所提出的設計不涵蓋非公開的投資報酬率資料、轉換、觸及、收藏、分享或完整的創作者歷史紀錄。

讀者並未明確要求使用固定的內容網址清單。儲存這些網址，是本文為定期更新提出的設計。當創作者的個人檔案出現新貼文後，應用程式仍須持續檢查原有貼文時，這種設計便很合適。

選擇 Actor 前，先用 1 句話定義應用程式的工作。例如：「每次預定檢查都必須更新行銷活動中已儲存貼文的公開計數。」這項需求適合使用直接內容輸入。若需求是找出創作者的最新貼文，則適合從個人檔案探索內容。

這項區別比產品是否接受 Instagram 網址更重要。個人檔案網址與內容網址，要求資料收集程式執行的是不同工作。

選擇探索內容或檢查已儲存的內容清單

個人檔案探索是指從創作者的個人檔案開始尋找內容。它適合需要新發布貼文的動態消息。每次探索都在回答這類問題：「現在能找到這位創作者的哪些近期貼文？」

直接內容檢查從現有的貼文或 Reel 網址開始。它適合每次檢查都必須維持相同貼文的行銷活動清單。每次執行都在問：「現在能取得這些已儲存貼文的哪些公開計數？」

隨著創作者發布更多內容，原有貼文可能不再出現在最新貼文範圍內。如果應用程式必須保留該貼文，儲存其網址就能為下次檢查提供明確目標。已儲存的網址用來識別內容，不代表每項指標都一定可用。

你可以在同一套規劃流程中使用這 2 種方式。先執行探索，找出新內容。再審核並儲存應用程式應追蹤的內容。後續檢查則使用這份已儲存清單。決定追蹤哪些內容時，應與判斷量測結果是否可用分開處理。

Chronometrica 同時支援個人檔案探索與直接內容輸入，因此適合上述規劃流程。但仍須檢查實際輸出，確認能取得所需計數。Chronometrica Actor

比較資料收集規格

資料收集規格說明程式接受哪些輸入，以及文件記載的輸出。它能協助你選擇收集方式，但不能證明程式在你預計使用的來源上會有何表現。

以上產品細節來自已核對的公開規格。這 2 項產品都支援排程與 API 使用方式。能否自動執行，並不足以決定本次比較的選擇。Chronometrica 規格、WebDataLabs 規格

請仔細閱讀表格中的輸出單位。回傳的內容紀錄可能足以識別貼文並更新部分計數，但同一筆紀錄仍可能無法滿足瀏覽次數的需求。將觀測紀錄用於圖表前，先定義什麼樣的紀錄才有用。

用簡單的定期流程將資料收集接到 Replit

針對這項需求，定時 API 輪詢是合理的初步設計。輪詢是指重複發送請求來檢查結果。以下步驟說明的是整合建議，並不表示本文曾測試與 Replit 的連線。

1. 依應用程式的報表需求設定資料收集排程。決定排程工作要找出新貼文、檢查已儲存貼文，或將這 2 項工作分開執行。
2. 將選定的輸入傳送給 Actor。保留請求收集的內容清單，讓應用程式能比較請求項目與回傳項目。
3. 等待資料收集完成後，再採用其輸出。發出開始收集的請求，不代表已完成量測。
4. 透過 API 讀取已完成的輸出。檢查內容識別資訊、收集時間、所需欄位，以及計數的可用狀態。
5. 儲存每筆通過驗收的觀測紀錄及其收集時間。使用這些已儲存的觀測紀錄更新應用程式。
6. 在儲存資料與應用程式中清楚保留計數缺失的狀態。顯示數值無法取得，不要顯示為 0。

webhook 是某個事件發生時，一項服務傳送給另一項服務的訊息。本次比較所提供的證據，並未確認 webhook 的設定方式。所提出的輪詢設計能回答整合問題，且不依賴未經核對的傳送功能。

分開記錄最近一次收集嘗試，以及最近一筆通過驗收的觀測紀錄。如果檢查失敗，或未回傳可用計數，應用程式可以保留先前的觀測紀錄及其原始時間。但不能將舊數值顯示為新量測結果。

也要決定應用程式是否需要歷史紀錄。覆寫上一筆紀錄，可以用來顯示最新計數。若要比較不同時間的計數，就必須保留較早的觀測紀錄。目前這次執行，無法補出過去未曾收集的觀測紀錄。

設定重複執行排程前，先檢查具代表性的樣本

首次驗收應使用能代表應用程式實際工作的內容。請使用你打算追蹤的公開來源。如果應用程式追蹤已儲存的 Reel，就檢查那些直接網址。如果要找出近期貼文，就檢查個人檔案探索方式。

先檢查內容識別資訊。確認每個回傳項目都對應到預定貼文。儲存內容的標準網址，也就是在各次檢查中用來識別同一內容的一致網址。不要用貼文在個人檔案清單中的位置來識別貼文，因為位置可能改變。

接著檢查收集時間。Chronometrica 提供 `scrapedAt`。將這個值與觀測紀錄一起保留，讓之後閱讀資料的人知道收集發生的時間。發布時間與收集時間必須分開記錄。貼文可能很舊，但收集到的計數仍是當下的數值。Chronometrica 輸出規格

然後檢查所需計數。Chronometrica 分別提供 `views`、`plays` 和 `playsInstagram` 欄位，並附上各項計數的可用狀態。儲存時必須保留這些不同的欄位名稱。在沒有明確報表規則的情況下，不要假設它們意義相同、將它們相加，或用其中一項取代另一項。Chronometrica 輸出規格

針對每項計數定義成功條件。如果應用程式需要瀏覽次數，只有在所需的瀏覽數值可用時，才能接受該筆瀏覽觀測紀錄。一筆紀錄可能提供有用的按讚數與留言數，通過這些項目的要求，卻未能滿足瀏覽次數的要求。

缺失值需要單獨處理。0 表示計數為 0。缺失表示計數未知或無法取得。將缺失值改為 0，會改變證據，並可能扭曲總數、平均值與排名。

最後，檢查應用程式如何呈現不完整的結果。創作者頁面應清楚標示缺失的計數。如果部分已儲存貼文沒有有效的瀏覽觀測紀錄，摘要就不應讓人以為所有貼文都提供了有效紀錄。保留足夠資訊，以便說明顯示結果是根據哪些觀測紀錄。

收集觀測紀錄後，如需製作報表，請參閱如何在 Instagram 每月瀏覽報表中區分新舊貼文。該指南說明如何計算與歸屬數值。本次比較則說明，定期檢查應使用哪些輸入。

虛構範例：需要後續檢查的 10 篇貼文

以下範例為虛構內容，不是測試、客戶成果，也不是實測成本比較。

某個應用程式先探索到 10 篇創作者的公開貼文。負責人審核清單後，決定追蹤這 10 篇貼文。應用程式儲存其內容網址，以及首批通過驗收的觀測紀錄中的收集時間。

在下次排程檢查前，這些創作者又發布了新貼文。應用程式仍需要更新原本 10 篇貼文的資料。掃描最新貼文時，探索結果中的內容可能改變。已儲存的清單能明確保留原定追蹤範圍。

應用程式提交這 10 個已儲存網址，進行直接內容檢查。它使用與首批樣本相同的驗收規則，逐筆評估回傳紀錄。它不會將執行完成視為已收集到每項必要指標的證明。

假設後續某筆紀錄提供有用的按讚數與留言數，卻沒有可用的瀏覽次數。應用程式可以接受按讚數與留言數，但必須讓瀏覽次數維持缺失狀態。即使這筆紀錄對應用程式的其他部分有用，它也不是成功的瀏覽觀測紀錄。

如果每個追蹤項目都必須有瀏覽次數，下一步就是測試個人檔案探索能否提供缺失的計數。如果這種方式也無法滿足需求，應用程式就需要其他來源，或縮小報表承諾涵蓋的範圍。

這個範例說明 Chronometrica 為何適合已儲存清單的流程。它的直接輸入方式解決了要檢查哪些內容的問題。驗收則決定應用程式能使用哪些量測結果。這是 2 個不同的決策。

以已儲存的 Task 作為初始預設

Task 是為 Actor 儲存的一組預設輸入。公開的 Instagram Reels Performance Tracker Task 可作為起點。

頁面檢查確認 Task 頁面可用，且標題符合預期。但這無法證明目前儲存的輸入內容，也無法證明範例 Reel 仍可存取。執行前，請套用下方符合目前結構定義的輸入：

{
  "mode": "contentUrls",
  "startUrls": [
    "https://www.instagram.com/reel/DIwcCZgxVZP/"
  ]
}

這份輸入已通過依所提供公開結構定義進行的靜態檢查。靜態檢查會檢查輸入格式，例如欄位名稱與允許的值，不會收集即時資料。本文未執行任何資料收集。

將範例網址換成你預計使用的公開內容網址。在這裡，`mode` 用來選擇直接內容檢查，`startUrls` 則提供內容清單。文件記載的模式選項為 `auto`、`contentUrls` 和 `profileUrls`。Chronometrica 輸入結構定義

重複執行工作前，先用初步樣本檢查輸出。儲存通過驗收的內容識別資訊、收集時間、計數與可用狀態。下次預定檢查時，再提交已儲存的網址。更新應用程式前，先比較回傳內容與請求清單。

根據所需的觀測紀錄作出最後選擇

選擇能產生應用程式所需觀測紀錄的收集方式。連線成功，只能證明程式可以交換請求與結果，不能證明所需的公開計數確實存在。

若要檢查已儲存的內容清單，本次比較建議先選擇 Chronometrica，因為已核對的規格支援直接輸入，並明確提供計數的可用狀態。但這項建議有前提：樣本必須滿足你的必要欄位要求。Chronometrica Actor

如果必要的瀏覽次數缺失，請更換收集方式或測試其他來源。不要為了讓整合看起來已完成，就刪除這項驗收規則。同樣地，如果探索近期個人檔案內容已能回答應用程式的問題，就不必加入固定清單流程。

有用的決策必須具體：每次執行要重新檢查哪些內容、必須回傳什麼計數，以及該計數缺失時，應用程式應如何處理？