
本指南協助你建立這張表,但不保證 Instagram 洞察報告、匯出檔案或第三方服務能還原缺少的歷史資料。Instagram 洞察報告是獲授權的帳號擁有者可查看的帳號統計資料。帳號擁有者的現有紀錄能否回答你的問題,取決於紀錄的指標、日期、身分與範圍。
「六個月內」是什麼意思?
有一則公開提問寫道:「我需要 6 個月內按讚、留言、觀看與分享次數的平均值。」這個說法提供了實用的起點,但沒有界定報告要涵蓋哪些貼文、哪些觀測日期,或哪一種平均值。這只是一筆提問紀錄,不能用來證明需求規模或產品使用情況。公開報表提問,於 2026 年 8 月 11 日擷取;僅一筆提問紀錄。
指標是你要衡量的數量,例如按讚次數或留言次數。搜尋紀錄前,先區分以下三種可能的需求:
- 每個月底觀測到的計數。
- 每個月新增的互動次數。
- 在某個六個月期間發布的貼文,目前的計數。
這些需求需要不同的證據。今天擷取的舊貼文計數可以支持第三種需求。貼文的發布日期不會讓今天的計數變成過去某個月底的觀測值。
計算平均值也需要界定納入的群組,並確認紀錄筆數。缺少觀測值可能改變這個群組。不要擅自用找到的少數紀錄算出平均值,取代原本六個月的需求。
公開計數與僅供帳號擁有者查看的統計資料,涵蓋範圍也不同。請分別檢查每項所需指標。找到可用的公開按讚次數,不代表同一日期也有可用的分享、觀看或留言次數。
1. 搜尋前先寫清楚需求
時間界點是所需期間開始或結束的確切時間。要判斷實際紀錄是否符合「一月底」,必須先定義具體時間與時區。
撰寫一份簡短的需求表,列出以下細節:
- 列出所需帳號。
- 界定報告納入哪些貼文。
- 分別列出每項指標的名稱。
- 列出六個所需月份的時間界點與年份。
- 註明時區。
- 註明需要的是時間界點計數、每月活動量,還是目前計數。
- 註明結果是否必須包含精確計數。
如果需求涉及個別貼文,請保留已知貼文清單。儲存每篇貼文的帳號識別資訊與貼文識別資訊。如果無法證明清單涵蓋所有所需貼文,請說明這項限制。
帳號層級的紀錄應維持帳號層級的範圍。不要把帳號總數當成個別貼文的觀測值。同樣地,幾篇已知貼文也不能證明資料涵蓋整個帳號。
歷史資料回填是指根據現有證據,填入過去報表的儲存格。回填時必須保留原始問題。如果之後提議縮短期間或減少貼文數,請說明這是調整後的交付內容。不要在填表時改變需求指定的單位。
2. 搜尋帳號擁有者的現有紀錄與先前報告
先找可能已包含所需歷史資料的紀錄。重新擷取公開計數,無法補出從未有人儲存的觀測值。
請依照以下順序搜尋:
- 檢查帳號擁有者的現有匯出檔案與已儲存報告。
- 檢查附有日期的螢幕截圖,以及可佐證其內容的相關資訊。
- 檢查先前經授權取得的報告與已儲存的公開觀測值。
- 保留原始檔案,並記錄每份檔案的來源。
- 根據需求表檢查每份候選紀錄。
觀測是指在已知時間取得一次數值。請分別檢查觀測時間與檔案建立時間。十月建立的檔案可能包含一月的報告。單靠檔案建立時間,無法證明畫面上的指標是在何時觀測的。
逐一檢查每份紀錄的指標標籤、帳號、貼文識別資訊、期間與觀測時間。記錄來源聲明的涵蓋範圍。不要因為報告標題寫了某個帳號,就假設報告包含該帳號的所有貼文。
也要區分累計計數與活動期間總數。累計計數是截至觀測時間累積的數量。活動期間總數則涵蓋指定期間內的活動。兩份都標示「按讚」的紀錄,仍可能代表不同的數量。
如果紀錄有數值,卻缺少需求所需的時間資訊,請將它保留為部分證據。不要丟棄其中有用的相關資訊,也不要把它視為有證據支持的月底觀測值。
3. 建立資料可用性表
為每個所需的帳號、指標與時間界點組合建立一列。如果需求涉及個別貼文,另外加入貼文識別資訊。單篇貼文、單項指標若有六個時間界點,即使只找到兩個觀測值,表格仍需要六列。
以下是建議用於報告的欄位,並非 Instagram Metrics Scraper 原生的輸出欄位。
| 儲存欄位 | 應記錄的內容 |
|---|---|
| `account_identity` | 需求指定的帳號,以及來源能佐證的帳號識別資訊 |
| `post_identity` | 需求以個別貼文為單位時,所需貼文的識別資訊 |
| `requested_boundary` | 需求指定的日期、時間與時區 |
| `source_record` | 原始檔案或報告的參照資訊,以及資料在該紀錄中的位置 |
| `source_observation_time` | 來源能證明的時間,或明確標示為未知 |
| `metric_label` | 來源中的指標名稱及其意義 |
| `metric_value` | 有證據支持的數值,或標示為缺值 |
| `precision` | 數值是精確值、約數、無法取得,還是尚待確認 |
| `identity_check` | 來源是否符合需求指定的帳號與貼文 |
| `usable_for_request` | 證據是否支持這個特定需求所需的觀測值 |
| `gap_reason` | 觀測值缺少或目前仍無法使用的原因 |
精確程度是指已知數值有多精確。以約數顯示的數值不是精確計數。如果原始顯示方式有助於說明限制,請一併保留。
不要用空白儲存格同時表示多種情況。請區分沒有紀錄、時間未知、指標錯誤、身分待確認,以及無法取得計數。這些狀態需要不同的後續處理。
零是一個觀測數值。缺值則表示你沒有取得所需的觀測值。只有當證據支持所需指標在指定時間為零,才能填入零。
將來源數值與是否採用該數值的判斷分開記錄。一份紀錄可能包含有效數值,卻未通過所需的時間檢查。該數值仍是來源證據,但不能填入需求指定的歷史計數儲存格。
4. 判斷哪些紀錄能支持需求
將證據分為三組:
- 可用的歷史證據:紀錄支持需求指定的身分、指標、時間與精確程度。
- 部分證據:紀錄包含有用資訊,但尚未通過某項必要檢查。
- 缺少證據:沒有可用紀錄能支持所需的觀測值。
逐列獨立檢查。一份合格的一月紀錄,不能證明另一個來源的三月紀錄也有效。貼文識別資訊正確,不能證明觀測時間正確。觀測時間已知,也不能解決指標標籤不同的問題。
如果需求是每月變化量,就需要期間兩端都有可相互比較的觀測值。另一種可能是採用帳號擁有者的期間總數,但其定義必須符合所需的活動期間。使用前先檢查定義。
不要在已知觀測值之間畫一直線,藉此估算缺少的社群計數。也不要從今天的累計計數往回推算。這兩種做法都無法產生缺少時間界點的證據。
計數也不一定代表人數。尤其是公開觀看次數,不等於不重複的觀看人數。報告中每個數值都應保留其單位。
如果後續需求涉及每月變化量,請參閱在每月觀看報告中區分 Instagram 新舊貼文的指南。該指南說明如何檢查已儲存的成對時間界點觀測值。請先完成這次資料可用性檢查,確認哪些觀測值確實存在。
5. 逐一處理六個所需時間界點
以下範例為原創虛構內容,並非平台測試、Actor 執行結果或客戶成果。
需求是取得一篇已知貼文 P1 從一月至六月的六個月底公開按讚次數觀測值。範例將其中兩份紀錄視為可用於所需時間界點的資料,但沒有提供時間戳記字串或精確程度標記。將表格套用至實際紀錄時,不要自行編造這些細節。
| 所需時間界點 | 現有證據 | 可用的歷史按讚次數 | 判斷 |
|---|---|---|---|
| 一月底 | 附有日期,且指標與識別碼相符的帳號擁有者紀錄 | 100 次按讚 | 可用的時間界點觀測值 |
| 二月底 | 沒有紀錄 | 缺值 | 保留缺漏 |
| 三月底 | 附有日期且符合需求的公開資料快照 | 180 次按讚 | 可用的時間界點觀測值 |
| 四月底 | 沒有紀錄 | 缺值 | 保留缺漏 |
| 五月底 | 螢幕截圖有計數,但觀測時間未獲證實 | 此時間界點缺值 | 保留為部分證據 |
| 六月底 | 沒有紀錄 | 缺值 | 保留缺漏 |
快照是儲存在某個觀測時間的觀測值。三月的快照之所以能支持三月的需求,只因範例明確說明它符合所需的時間界點與身分。
五月的螢幕截圖則不同。截圖包含計數,但範例沒有提供該數值,也沒有證明觀測時間。不要將編造的數值填入表格。請保留截圖的參照資訊,並註明時間仍待確認。
檢查所需時間界點的數量:
2 個可用的時間界點觀測值 + 1 份時間待確認的紀錄 + 3 份缺少的紀錄 = 6 個所需時間界點。
接著檢查缺乏證據支持的部分:
1 個時間待確認的時間界點 + 3 個沒有紀錄的時間界點 = 4 個缺乏證據支持的時間界點。
這裡的單位是時間界點觀測值與所需時間界點,不是人數、貼文數或每月增量。
假設十月的一次新觀測顯示,P1 有 300 次按讚。這個數值仍是十月的觀測值,無法填補四個缺乏證據支持的歷史時間界點中的任何一個,也無法確認五月截圖的日期。
證據支持的做法是交付一月的 100 次按讚與三月的 180 次按讚觀測值,並附上全部四列缺乏證據支持的時間界點。不要報告六個精確的月底計數,也不要聲稱有缺乏證據支持的每月增量。
這兩個有證據支持的觀測值,也無法證明六個月月底按讚次數的平均值。計算該結果,需要有證據支持需求指定的整組觀測值。只根據現有紀錄計算平均值,回答的是另一個問題,必須另外清楚標示。
6. 目前的公開資料擷取僅用於補充目前情況
檢查目前資料,有助於比對已知公開貼文與回傳的識別資訊。請將該觀測值保存在獨立的目前觀測表,不得用來填入歷史時間界點的儲存格。
Actor 是在託管環境中執行的資料擷取程式。Instagram Metrics Scraper 經檢查的公開規格,記載了直接內容輸入與公開指標欄位。這些文件支持它適用於目前資料擷取這個步驟。本指南未實際執行擷取,也未測試歷史資料還原。Instagram Metrics Scraper,於 2026 年 10 月 25 日檢查規格;僅有文件支持其適用於公開資料擷取,未做執行測試。
請以提供的小型輸入範例為起點:
{"maxItems":1,"mode":"contentUrls","startUrls":["https://www.instagram.com/reel/DIwcCZgxVZP/"]}JSON 是一種表示結構化資料的文字格式。在這份輸入中,`mode` 用來選擇輸入處理方式。`contentUrls` 這個值用來選擇直接輸入貼文或 Reel 網址的方式。Reel 是 Instagram 的一種影片格式。`startUrls` 欄位存放內容網址。`maxItems` 欄位設定指標資料列的上限。
如果決定檢查目前資料,請依照以下步驟操作:
- 將範例網址換成一個已知的公開貼文或 Reel 網址。
- 替換整個範例清單,不要將自己的網址加在範例網址旁邊。
- 這次只檢查一個項目,請將 `mode` 維持為 `contentUrls`,並將 `maxItems` 維持為 1。
- 將回傳的 `postId` 與 `postUrl` 和目標貼文比對。
- 檢查 `status`、`statusReason`,以及相關的 `postMetricStatus` 項目。
- 將 `scrapedAt` 與目前觀測值一併儲存。
- 將結果保存在歷史時間界點表之外。
`publishedAt` 欄位表示發布時間。`scrapedAt` 欄位表示擷取時間。較早的 `publishedAt` 值,無法讓新擷取的資料變成過去的觀測紀錄。
文件記載的輸出包含公開按讚次數、留言次數、觀看次數、識別資訊、擷取時間與狀態資訊。其資料結構沒有非公開觸及人數、收藏次數、分享次數,或歷史時間界點計數欄位。這個範圍無法證明其他經授權取得的帳號擁有者資料來源可能包含什麼。公開組建版本 1.0.35,於 2026 年 10 月 25 日檢查;證據僅來自靜態輸入與文件記載的輸出,未付費執行。
公開規格也支援從個人檔案探索內容,也就是根據輸入的個人檔案尋找近期公開內容。這不能證明取得了完整帳號歷史。本方法改用已知的內容網址。
Task 是已儲存的輸入預設設定。公開的 Instagram Brand Campaign Metrics Task 可作為起始頁面。所提供的檢查只確認該頁面存在,並未在登入驗證後檢查已儲存的設定,也未執行該預設設定。Instagram Brand Campaign Metrics,於 2026 年 10 月 25 日檢查;僅確認公開頁面存在,未驗證已儲存設定與執行結果。
7. 交付前檢查報告
交付有證據支持的歷史觀測值,以及列出所有缺少或待確認時間界點的清單。這份清單也是結果的一部分,能說明證據無法支持哪些內容。
最後執行以下檢查:
- 確認每個所需的帳號、貼文、指標與時間界點組合都有對應資料列。
- 確認每個可用數值都能追溯至原始來源紀錄。
- 確認觀測時間符合所需的時間界點與時區。
- 確認指標標籤描述的數量與需求一致。
- 確認精確結果不含尚待確認或以約數顯示的數值。
- 確認缺值仍標示為缺值,沒有變成零。
- 確認目前觀測值與歷史觀測值分開呈現。
- 確認可用、部分證據與缺值的資料列總數,等於需求指定的資料列數。
身分錯誤、觀測時間未知、指標不相容,或精確程度不足,都應視為未通過驗收檢查。請清楚保留原因。未通過檢查不代表來源沒有價值,而是該來源目前還無法支持需求指定的儲存格。
在交付說明中,明確列出涵蓋的帳號、貼文、指標與時間區間。列出尚待完成的檢查。不要將只涵蓋部分貼文的報告,描述成完整帳號歷史。
如果完整六個月仍缺乏證據支持,請提出範圍較小、但有證據支持的交付內容。在虛構範例中,就是兩個歷史觀測值與四個明確標示的缺漏。不要將這兩個觀測值稱為連續六個月的歷史資料。
記錄缺漏後,規劃日後的儲存作業。儲存 Instagram 指標快照並避免重複匯入的指南說明如何保存後續觀測值。往後儲存資料能保障未來報告所需的紀錄,但無法補回缺少的過去資料。
來源與延伸閱讀
作者 Chronometrica · 更新日期
返回頂端 ↑