# 定期追蹤 Instagram 創作者指標：Chronometrica 與 WebDataLabs Instagram Posts and Reels 比較 如果你的應用程式需要先找出創作者近期的公開貼文，再重新檢查已儲存的內容網址，並清楚保留瀏覽次數與播放次數的缺失狀態，可選擇 Chronometrica。它的 Instagram Metrics Scraper 接受個人檔案與直接內容輸入，會回傳 `views`、`plays`、`playsInstagram`、`scrapedAt`，以及各項計數的可用狀態。這個 Actor 由 Chronometrica 發布。Actor 是在雲端執行的資料收集程式。上述資訊來自於 2026 年 10 月 20 日核對的公開規格；本文未報告新的比較測試。[Chronometrica Actor](https://apify.com/chronometrica/instagram-metrics-scraper) 如果重複掃描個人檔案就能滿足需求，可選擇 WebDataLabs Instagram Posts and Reels Scraper。它的文件說明，可透過個人檔案探索取得 Reel 瀏覽次數與媒體連結。文件也明確指出，直接貼文與 Reel 連結不會提供 Reel 瀏覽次數。[WebDataLabs Actor](https://apify.com/webdatalabs/instagram-posts-reels-scraper) 影響選擇的主要限制是：Chronometrica 也不保證能從已儲存的內容網址取得瀏覽次數。如果瀏覽次數是必要資料，而直接內容方式未能取得，請先測試個人檔案探索或其他來源，再決定是否採用這套流程。[Chronometrica Actor](https://apify.com/chronometrica/instagram-metrics-scraper) 對 Replit 應用程式而言，可先採用定時收集資料，再透過 API 更新應用程式的設計。API 讓程式能向另一個程式要求執行工作或提供資料。關鍵在於決定每次收集要檢查什麼：創作者近期的內容，還是一份已儲存的貼文清單。 ## 先釐清應用程式的定期更新需求 一則關於網紅追蹤應用程式的公開討論，詢問如何將定期資料收集接到 Replit，包括該使用 webhook 還是定時 API 輪詢。相關需求是更新他人網紅貼文的公開指標。這是有參考價值的整合問題，不是對供應商的背書，也不是經過驗證的產品測試。[讀者討論](https://www.reddit.com/r/replit/comments/1rdtpxl/building_an_influencer_tracking_app_with_crm_roi/) 本次比較涵蓋的量測項目是公開按讚數、留言數，以及可取得的瀏覽次數或播放次數。所提出的設計不涵蓋非公開的投資報酬率資料、轉換、觸及、收藏、分享或完整的創作者歷史紀錄。 讀者並未明確要求使用固定的內容網址清單。儲存這些網址，是本文為定期更新提出的設計。當創作者的個人檔案出現新貼文後，應用程式仍須持續檢查原有貼文時，這種設計便很合適。 選擇 Actor 前，先用 1 句話定義應用程式的工作。例如：「每次預定檢查都必須更新行銷活動中已儲存貼文的公開計數。」這項需求適合使用直接內容輸入。若需求是找出創作者的最新貼文，則適合從個人檔案探索內容。 這項區別比產品是否接受 Instagram 網址更重要。個人檔案網址與內容網址，要求資料收集程式執行的是不同工作。 ## 選擇探索內容或檢查已儲存的內容清單 個人檔案探索是指從創作者的個人檔案開始尋找內容。它適合需要新發布貼文的動態消息。每次探索都在回答這類問題：「現在能找到這位創作者的哪些近期貼文？」 直接內容檢查從現有的貼文或 Reel 網址開始。它適合每次檢查都必須維持相同貼文的行銷活動清單。每次執行都在問：「現在能取得這些已儲存貼文的哪些公開計數？」 隨著創作者發布更多內容，原有貼文可能不再出現在最新貼文範圍內。如果應用程式必須保留該貼文，儲存其網址就能為下次檢查提供明確目標。已儲存的網址用來識別內容，不代表每項指標都一定可用。 你可以在同一套規劃流程中使用這 2 種方式。先執行探索，找出新內容。再審核並儲存應用程式應追蹤的內容。後續檢查則使用這份已儲存清單。決定追蹤哪些內容時，應與判斷量測結果是否可用分開處理。 Chronometrica 同時支援個人檔案探索與直接內容輸入，因此適合上述規劃流程。但仍須檢查實際輸出，確認能取得所需計數。[Chronometrica Actor](https://apify.com/chronometrica/instagram-metrics-scraper) ## 比較資料收集規格 資料收集規格說明程式接受哪些輸入，以及文件記載的輸出。它能協助你選擇收集方式，但不能證明程式在你預計使用的來源上會有何表現。 | 決策項目 | Chronometrica Instagram Metrics Scraper | WebDataLabs Instagram Posts and Reels Scraper | | --- | --- | --- | | 所需輸入 | 用個人檔案探索內容；用內容網址進行後續檢查 | 使用個人檔案，依文件記載的方式取得 Reel 瀏覽次數 | | 所需輸出單位 | 在某次收集時間取得的 1 筆內容觀測紀錄 | 透過個人檔案探索取得的 Reel 觀測紀錄 | | 所需欄位 | 內容識別資訊、`scrapedAt`、所需計數，以及各項計數的可用狀態 | 所需的 Reel 瀏覽次數與媒體連結 | | 缺失資料處理規則 | 無法取得的計數維持缺失狀態 | 文件明確指出，無法從直接連結取得 Reel 瀏覽次數 | | 主要限制 | 直接內容輸入不保證能取得瀏覽次數 | 直接連結不提供 Reel 瀏覽次數 | | 改變選擇的條件 | 所選方式未能取得必要計數 | 重複掃描個人檔案即可滿足應用程式的需求 | 以上產品細節來自已核對的公開規格。這 2 項產品都支援排程與 API 使用方式。能否自動執行，並不足以決定本次比較的選擇。[Chronometrica 規格](https://apify.com/chronometrica/instagram-metrics-scraper)、[WebDataLabs 規格](https://apify.com/webdatalabs/instagram-posts-reels-scraper) 請仔細閱讀表格中的輸出單位。回傳的內容紀錄可能足以識別貼文並更新部分計數，但同一筆紀錄仍可能無法滿足瀏覽次數的需求。將觀測紀錄用於圖表前，先定義什麼樣的紀錄才有用。 ## 用簡單的定期流程將資料收集接到 Replit 針對這項需求，定時 API 輪詢是合理的初步設計。輪詢是指重複發送請求來檢查結果。以下步驟說明的是整合建議，並不表示本文曾測試與 Replit 的連線。 1. 依應用程式的報表需求設定資料收集排程。決定排程工作要找出新貼文、檢查已儲存貼文，或將這 2 項工作分開執行。 2. 將選定的輸入傳送給 Actor。保留請求收集的內容清單，讓應用程式能比較請求項目與回傳項目。 3. 等待資料收集完成後，再採用其輸出。發出開始收集的請求，不代表已完成量測。 4. 透過 API 讀取已完成的輸出。檢查內容識別資訊、收集時間、所需欄位，以及計數的可用狀態。 5. 儲存每筆通過驗收的觀測紀錄及其收集時間。使用這些已儲存的觀測紀錄更新應用程式。 6. 在儲存資料與應用程式中清楚保留計數缺失的狀態。顯示數值無法取得，不要顯示為 0。 webhook 是某個事件發生時，一項服務傳送給另一項服務的訊息。本次比較所提供的證據，並未確認 webhook 的設定方式。所提出的輪詢設計能回答整合問題，且不依賴未經核對的傳送功能。 分開記錄最近一次收集嘗試，以及最近一筆通過驗收的觀測紀錄。如果檢查失敗，或未回傳可用計數，應用程式可以保留先前的觀測紀錄及其原始時間。但不能將舊數值顯示為新量測結果。 也要決定應用程式是否需要歷史紀錄。覆寫上一筆紀錄，可以用來顯示最新計數。若要比較不同時間的計數，就必須保留較早的觀測紀錄。目前這次執行，無法補出過去未曾收集的觀測紀錄。 ## 設定重複執行排程前，先檢查具代表性的樣本 首次驗收應使用能代表應用程式實際工作的內容。請使用你打算追蹤的公開來源。如果應用程式追蹤已儲存的 Reel，就檢查那些直接網址。如果要找出近期貼文，就檢查個人檔案探索方式。 先檢查內容識別資訊。確認每個回傳項目都對應到預定貼文。儲存內容的標準網址，也就是在各次檢查中用來識別同一內容的一致網址。不要用貼文在個人檔案清單中的位置來識別貼文，因為位置可能改變。 接著檢查收集時間。Chronometrica 提供 `scrapedAt`。將這個值與觀測紀錄一起保留，讓之後閱讀資料的人知道收集發生的時間。發布時間與收集時間必須分開記錄。貼文可能很舊，但收集到的計數仍是當下的數值。[Chronometrica 輸出規格](https://apify.com/chronometrica/instagram-metrics-scraper) 然後檢查所需計數。Chronometrica 分別提供 `views`、`plays` 和 `playsInstagram` 欄位，並附上各項計數的可用狀態。儲存時必須保留這些不同的欄位名稱。在沒有明確報表規則的情況下，不要假設它們意義相同、將它們相加，或用其中一項取代另一項。[Chronometrica 輸出規格](https://apify.com/chronometrica/instagram-metrics-scraper) 針對每項計數定義成功條件。如果應用程式需要瀏覽次數，只有在所需的瀏覽數值可用時，才能接受該筆瀏覽觀測紀錄。一筆紀錄可能提供有用的按讚數與留言數，通過這些項目的要求，卻未能滿足瀏覽次數的要求。 缺失值需要單獨處理。0 表示計數為 0。缺失表示計數未知或無法取得。將缺失值改為 0，會改變證據，並可能扭曲總數、平均值與排名。 最後，檢查應用程式如何呈現不完整的結果。創作者頁面應清楚標示缺失的計數。如果部分已儲存貼文沒有有效的瀏覽觀測紀錄，摘要就不應讓人以為所有貼文都提供了有效紀錄。保留足夠資訊，以便說明顯示結果是根據哪些觀測紀錄。 收集觀測紀錄後，如需製作報表，請參閱[如何在 Instagram 每月瀏覽報表中區分新舊貼文](/zh-Hant/articles/%E6%AF%8F%E6%9C%88instagram%E8%A7%80%E7%9C%8B%E5%A0%B1%E5%91%8A-%E6%8C%89%E7%99%BC%E5%B8%83%E6%97%A5%E6%9C%9F%E5%88%86%E9%96%8B%E8%88%8A%E8%88%87%E6%96%B0%E8%B2%BC%E6%96%87/)。該指南說明如何計算與歸屬數值。本次比較則說明，定期檢查應使用哪些輸入。 ## 虛構範例：需要後續檢查的 10 篇貼文 以下範例為虛構內容，不是測試、客戶成果，也不是實測成本比較。 某個應用程式先探索到 10 篇創作者的公開貼文。負責人審核清單後，決定追蹤這 10 篇貼文。應用程式儲存其內容網址，以及首批通過驗收的觀測紀錄中的收集時間。 在下次排程檢查前，這些創作者又發布了新貼文。應用程式仍需要更新原本 10 篇貼文的資料。掃描最新貼文時，探索結果中的內容可能改變。已儲存的清單能明確保留原定追蹤範圍。 應用程式提交這 10 個已儲存網址，進行直接內容檢查。它使用與首批樣本相同的驗收規則，逐筆評估回傳紀錄。它不會將執行完成視為已收集到每項必要指標的證明。 假設後續某筆紀錄提供有用的按讚數與留言數，卻沒有可用的瀏覽次數。應用程式可以接受按讚數與留言數，但必須讓瀏覽次數維持缺失狀態。即使這筆紀錄對應用程式的其他部分有用，它也不是成功的瀏覽觀測紀錄。 如果每個追蹤項目都必須有瀏覽次數，下一步就是測試個人檔案探索能否提供缺失的計數。如果這種方式也無法滿足需求，應用程式就需要其他來源，或縮小報表承諾涵蓋的範圍。 這個範例說明 Chronometrica 為何適合已儲存清單的流程。它的直接輸入方式解決了要檢查哪些內容的問題。驗收則決定應用程式能使用哪些量測結果。這是 2 個不同的決策。 ## 以已儲存的 Task 作為初始預設 Task 是為 Actor 儲存的一組預設輸入。公開的 [Instagram Reels Performance Tracker Task](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-reels-performance-tracker) 可作為起點。 頁面檢查確認 Task 頁面可用，且標題符合預期。但這無法證明目前儲存的輸入內容，也無法證明範例 Reel 仍可存取。執行前，請套用下方符合目前結構定義的輸入： ```json { "mode": "contentUrls", "startUrls": [ "https://www.instagram.com/reel/DIwcCZgxVZP/" ] } ``` 以已儲存的 Task 作為初始預設 這份輸入已通過依所提供公開結構定義進行的靜態檢查。靜態檢查會檢查輸入格式，例如欄位名稱與允許的值，不會收集即時資料。本文未執行任何資料收集。 將範例網址換成你預計使用的公開內容網址。在這裡，`mode` 用來選擇直接內容檢查，`startUrls` 則提供內容清單。文件記載的模式選項為 `auto`、`contentUrls` 和 `profileUrls`。[Chronometrica 輸入結構定義](https://apify.com/chronometrica/instagram-metrics-scraper) 重複執行工作前，先用初步樣本檢查輸出。儲存通過驗收的內容識別資訊、收集時間、計數與可用狀態。下次預定檢查時，再提交已儲存的網址。更新應用程式前，先比較回傳內容與請求清單。 ## 根據所需的觀測紀錄作出最後選擇 選擇能產生應用程式所需觀測紀錄的收集方式。連線成功，只能證明程式可以交換請求與結果，不能證明所需的公開計數確實存在。 若要檢查已儲存的內容清單，本次比較建議先選擇 Chronometrica，因為已核對的規格支援直接輸入，並明確提供計數的可用狀態。但這項建議有前提：樣本必須滿足你的必要欄位要求。[Chronometrica Actor](https://apify.com/chronometrica/instagram-metrics-scraper) 如果必要的瀏覽次數缺失，請更換收集方式或測試其他來源。不要為了讓整合看起來已完成，就刪除這項驗收規則。同樣地，如果探索近期個人檔案內容已能回答應用程式的問題，就不必加入固定清單流程。 有用的決策必須具體：每次執行要重新檢查哪些內容、必須回傳什麼計數，以及該計數缺失時，應用程式應如何處理？ ## 從應用程式必須重新檢查的內容開始 開啟 [Instagram Reels Performance Tracker Task](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-reels-performance-tracker)，套用上方輸入，並將範例換成你預計使用的公開網址。設定定期排程前，先檢查回傳的內容識別資訊、`scrapedAt`、所需計數與可用狀態。 如果應用程式需要先探索內容，再於後續檢查已儲存的內容，可從 Chronometrica 的 [Instagram Metrics Scraper](https://apify.com/chronometrica/instagram-metrics-scraper) 開始。將可用計數視為證據，保留缺失值，並在必要計數缺失時更換收集方式。 ## 來源與延伸閱讀 - [Chronometrica Instagram Metrics Scraper：公開輸入與輸出規格已於 2026 年 10 月 20 日核對；支援個人檔案與直接內容輸入，但不保證能從直接網址取得瀏覽次數；未執行新的比較收集。](https://apify.com/chronometrica/instagram-metrics-scraper) - [WebDataLabs Instagram Posts and Reels Scraper：公開規格已於 2026 年 10 月 20 日核對；文件記載可透過個人檔案探索取得 Reel 瀏覽次數與媒體連結，但直接連結不提供 Reel 瀏覽次數；未執行新的比較收集。](https://apify.com/webdatalabs/instagram-posts-reels-scraper) - [Replit 網紅追蹤應用程式討論：關於定期公開指標的整合問題；背景資料於 2026 年 10 月 20 日提供，未報告另外進行的即時檢查；不是對供應商的背書，也不是經過驗證的產品測試。](https://www.reddit.com/r/replit/comments/1rdtpxl/building_an_influencer_tracking_app_with_crm_roi/) - [Instagram Reels Performance Tracker Task：初始預設頁面；2026 年 10 月 20 日提供的頁面檢查證據，確認頁面可用且標題符合預期，但未確認目前儲存的輸入或範例 Reel 是否可用；未執行資料收集。](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-reels-performance-tracker) - [如何在 Instagram 每月瀏覽報表中區分新舊貼文：收集觀測紀錄後的分析方法；指南範圍於 2026 年 10 月 20 日提供，未報告新的頁面檢查；用於已有資料快照後的報表數值計算與歸屬。](/zh-Hant/articles/%E6%AF%8F%E6%9C%88instagram%E8%A7%80%E7%9C%8B%E5%A0%B1%E5%91%8A-%E6%8C%89%E7%99%BC%E5%B8%83%E6%97%A5%E6%9C%9F%E5%88%86%E9%96%8B%E8%88%8A%E8%88%87%E6%96%B0%E8%B2%BC%E6%96%87/)