如何匯出 Instagram 每月貼文報告，只保留所需數值

1. 確定月份與數值的觀測時間

選取貼文前，先寫下發布月份、年份和時區。發布時間是貼文發布的時間。觀測時間是你蒐集其數值的時間。

以當月開始的第一個時間點為起點，以下個月開始的第一個時間點為終點。納入起點，但不納入終點。這項規則可避免下個月開始時發布的貼文，同時出現在兩份報告中。

選擇試算表必須回答的問題：

1. 指定月份發布的貼文，目前的公開數值是多少？
2. 指定月份期間發生了多少互動？

本方法回答第一個問題。九月發布的貼文，其數值可以在十月 25 日蒐集。九月的發布日期用來決定是否選取該貼文。十月的觀測時間則說明這些數值是在何時取得。

如果需求是了解九月期間的互動，請在蒐集目前數值前，先調整所需證據。目前數值無法證明九月 30 日當時的數值。不要將十月的觀測資料改稱為九月底的數值。

也要明確界定帳號和來源清單。如果報告只涵蓋部分貼文，必須註明。合適的報告標題是「已知九月貼文的目前觀測資料」。請在自己的報告中補上年份和實際觀測日期。

2. 建立經過核對的貼文清單

貼文清單是你打算納入的貼文列表。先使用擁有者已核對的發布紀錄表，或現有的匯出資料。發布紀錄表會記錄發布了哪些貼文，以及發布時間。

檢查該來源是否涵蓋指定的帳號和月份。記下其涵蓋範圍。涵蓋範圍是指，來源能為要求納入的貼文清單提供多少證據。不要因為匯出檔的資料列很多，就假設其中包含所有貼文。

如果沒有擁有者提供的清單，請手動整理一份已知公開貼文網址的部分清單。註明這份清單的涵蓋範圍有限。不要憑這些證據承諾涵蓋帳號當月的所有貼文。

針對每則候選貼文，儲存要求處理的網址及發布證據。如果有穩定不變的貼文 ID，請一併使用。貼文 ID 用來識別單一內容項目。URL 則是該項目的網址。

請清楚保留以下判定：

不要將發現貼文的日期當成發布日期。日期不明，也不能證明貼文是在指定月份之外發布。

每個內容項目各占一列。如果兩個網址對應到同一個已核對的貼文 ID，請在來源紀錄中保留要求處理的網址，報告中則只計入該貼文一次。僅憑貼文說明文字相同，無法證明兩列資料屬於同一則貼文。

Instagram 貼文清單核對指南 說明了相關的日期與涵蓋範圍限制。製作本報告時，請使用已核對的貼文識別資料和日期。你不需要使用該指南中的格式或發布頻率分析。

3. 檢查一個已知的公開網址

Actor 是在代管環境中執行、用來蒐集資料的程式。Instagram Metrics Scraper 的文件說明了如何直接從已知的公開內容網址蒐集資料。經核對的公開輸入格式接受將 `mode` 設為 `contentUrls`、在 `startUrls` 中提供清單，以及選擇性地透過 `maxItems` 設定資料列總數上限。

上限是最多可傳回的數量，不是保證傳回的結果數。文件記載的輸入也支援從個人檔案探索內容。本方法使用你已核對的內容清單，不依靠個人檔案探索來建立完整的每月歷史紀錄。請參閱公開建置版本規格；於 2026 年 10 月 25 日核對，僅涵蓋文件記載的輸入與輸出。

第一次檢查時，請使用以下提供的小型輸入：

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

執行前：

1. 將範例網址替換成清單中一則已知的公開貼文或 Reel 網址。Reel 是 Instagram 的影片貼文。
2. 將 `mode` 維持為 `contentUrls`。
3. 這次只檢查一個項目，請將 `maxItems` 維持為 `1`。
4. 將傳回的識別資料、日期、數值和狀態，與要求處理的貼文逐一比對。

提供的輸入符合文件記載的格式。本指南未實際執行程式。範例網址不能作為你的每月報告證據。

若已核對的貼文清單較長，請將範例清單替換成要處理的網址。設定足以容納這些項目的上限。接著，將每則要求處理的貼文與傳回資料逐一比對。提高上限並不能保證每則貼文都有可用數值。

公開的 Instagram Brand Campaign Metrics Task；於 2026 年 10 月 25 日核對，僅確認頁面存在，可作為起始頁面。Task 是已儲存的輸入預設設定。其儲存設定未透過已驗證身分的帳號核對，也未實際執行。使用前，請自行檢查輸入。

4. 保留可說明各項數值的欄位

保留數值欄位，以及解讀這些數值所需的證據。文件記載的輸出包含以下欄位。規格中列出這些欄位，不代表每列傳回資料都會有所有值。

精確程度是指數值有多精確。文件記載的 `postMetricStatus` 可區分精確值、經取整的數值、無法取得精確程度，以及精確程度不明。它也會記錄該指標已有數值、無法取得，或未嘗試取得。

請分別閱讀讚數和留言數的紀錄。同一資料列可能有一項數值可用，另一項卻缺漏。因此，有傳回資料列，不足以證明兩項數值都可用。

缺少的數值請留白。只有來源確實提供零時，才填入零。空白儲存格表示你沒有該數值。零則表示觀測到的數值為零。

經取整的數值，仍須標明經過取整。不要將這類數值加總後，當成精確總數呈現。如果只需要精確值的總數，請選用有明確記錄為精確值的資料列，並說明這項規則。

自行新增報告欄位，記錄是否納入發布月份的判定、發布證據及涵蓋範圍說明。這些是你執行的檢查。不要將它們描述為 Actor 產生的分析。

公開讚數和留言數是次數，不是不重複人數。本方法不提供非公開的觸及人數、收藏次數、分享次數，也不提供付費與自然互動的區分。自然互動是指未歸因於付費廣告的互動。如果需求涉及只有擁有者能取得的紀錄，請要求提供適當的擁有者資料來源，不要用公開數值填入這些欄位。

5. 將每則要求處理的貼文與輸出逐一比對

核對是指將要求處理的清單與傳回的資料列逐一比對。請從貼文清單開始核對，讓缺少的結果仍清楚可見。

針對每則要求處理的貼文：

1. 尋找相符的 `inputUrl`、已核對的 `postId`，或傳回的 `postUrl`。
2. 如果有傳回資料列，請閱讀 `status` 和 `statusReason`。
3. 依據已核對的證據，確認是否納入該發布月份。
4. 分別檢查讚數和留言數，包括各自的指標狀態。
5. 保留實際的 `scrapedAt` 值。
6. 即使沒有傳回可用數值，也要在報告中保留一列。

如果某則貼文沒有傳回資料列，請保留清單中原先要求處理的識別資料。不要捏造 Actor 狀態或蒐集時間戳記。請在自己的報告備註中記錄未傳回結果。

上限過小，可能使部分要求處理的項目未獲處理。即使上限足夠，也不能證明所有數值都能取得。請閱讀傳回的證據，不要將輸出資料列數視為成功的證明。

處理矛盾時，請保留來源資料列。交付的檔案中，每則貼文應各有一列數值資料，並附上足以說明各項判定的證據。

6. 匯出並檢查試算表

將選定欄位匯出為 CSV，或使用平台的試算表匯出功能。CSV 是逗號分隔值格式，以文字檔的列與欄儲存資料。

以文字格式匯入貼文 ID。ID 用來識別貼文，不是用於計算的數量。保留時間戳記的時區。設定日期儲存格格式時，不要移除時區。

計算前，請檢查匯入的檔案：

1. 檢查第一列和最後一列的資料是否對齊欄位。
2. 將每筆要求處理的識別資料與交付的資料列逐一比對。
3. 確認無法取得數值的貼文仍保留在檔案中。
4. 檢查空白的數值儲存格是否仍為空白，未變成零。
5. 檢查 ID 是否仍為文字，時間戳記是否仍可讀取。
6. 確認匯出後仍保留指標品質資訊。

如果 `postMetricStatus` 放在單一試算表儲存格中不易閱讀，請分別建立讚數品質和留言數品質欄位。將有記錄的狀態及精確程度複製到這些欄位。保留來源值，讓其他讀者可以核對你的摘要。

明確定義哪些資料列可納入各項計算。這些就是符合條件的資料列。分母是計算平均值時用來除總數的數字。平均值是總數除以符合條件的資料列數。

請分別列出讚數可用的貼文數，以及留言數可用的貼文數。如果兩者不同，各自的平均值就必須使用不同的分母。如果沒有任何資料列符合條件，請將結果標為無法取得，不要填零。

7. 計算範例：原創虛構案例

本例為原創虛構案例。P1、P2 和 P3 是為讀者示範而虛構的紀錄，並非 Actor 的輸出。

這份虛構清單包含三則已核對的九月貼文。數值的觀測日期為十月 25 日。本例未提供各則貼文的發布時間戳記、觀測的具體時刻、時區或指標精確程度紀錄。本例用來說明如何處理缺漏資料列及進行計算，並非已完整驗收、可供正式使用的檔案。

交付的 CSV 檔中，三列都要保留。P3 的空白儲存格表示無法取得數值，不代表讚數或留言數為零。

這些虛構的可用資料列，計算方式如下：

1. 可用讚數的涵蓋範圍：要求處理的 3 則貼文中，有 2 則的讚數可用。
2. 觀測讚數總計：100 個讚 + 200 個讚 = 300 個讚，來自 2 則數值可用的貼文。
3. 平均觀測讚數：300 個讚 / 2 則數值可用的貼文 = 每則數值可用的貼文平均 150 個讚。
4. 可用留言數的涵蓋範圍：要求處理的 3 則貼文中，有 2 則的留言數可用。
5. 觀測留言數總計：10 則留言 + 20 則留言 = 30 則留言，來自 2 則數值可用的貼文。
6. 平均觀測留言數：30 則留言 / 2 則數值可用的貼文 = 每則數值可用的貼文平均 15 則留言。

合適的報告備註是：「在 10 月 25 日觀測時，兩列可用資料共有 300 個讚和 30 則留言。三則貼文的清單中，有一列無法取得數值。」

不要將 300 描述為九月的全部讚數。這個數字未包含 P3 的未知數值。它也代表在十月觀測到的九月貼文數值。不要稱它為九月底的總數。

不要將 300 除以 3，作為三則貼文的平均值。這種算法會將缺少的數值當成零。有證據支持的平均值，只使用兩列可用資料。

8. 驗收報告並註明限制

每則納入的貼文，都必須有已核對的識別資料、是否納入發布月份的判定、傳回數值的已知觀測時間，以及明確的數值狀態，檔案才可通過驗收。尚未判定的候選貼文，須保留為清楚可見的項目，直到能核對其月份歸屬。

報告備註必須寫明來源清單及其涵蓋範圍，也必須註明數值觀測時間、各項指標的可用資料列數，以及計算總數或平均值所用的規則。不要將部分已知貼文清單描述為完整的帳號歷史紀錄。

如果需求改為計算月初與月底之間的互動增量，就要使用不同的證據。月初與月底觀測紀錄保存指南 說明了這項不同的需求。發布月份的標籤，不能讓目前數值變成歷史數值。

這是根據已核對的公開文件提出的工作流程。提供的證據不包含付費執行結果，也沒有實測的可靠性結果。證據支持的是文件所述的資料蒐集用途符合需求，並不支持 Actor 會替你完成或驗證報告的說法。