如何審查 Instagram 留言中的購買問題

1. 界定審查範圍

選擇品牌自己發布、已知且公開的產品貼文。開始前，記下貼文連結，並設定一段較短的審查期間。說明你只會審查留言一次，還是之後會再次查核。

第一層留言直接位於貼文下方。回覆則位於另一則留言下方。本方法使用公開的第一層留言。人員可以查看可見的回覆，以了解脈絡，但下方的蒐集輸入設定不會匯出這些回覆的文字。

撰寫簡短的範圍說明，包含以下項目：

1. 所選的公開產品貼文。
2. 選擇這些貼文的原因。
3. 審查期間。
4. 每篇貼文最多蒐集的留言數。
5. 負責查核產品事實的人員。
6. 處理個人訂單資料的一般客服流程。

本指南源於一個讀者問題，詢問如何「從 Instagram 私訊與留言中篩選潛在客戶」。在此，篩選是指確認一個問題還需要哪些資訊，才能給出有用的回覆。DM 指的是私訊，不在本蒐集方法的範圍內。所提供的問題來自一則與供應商有關聯的公開討論。這只顯示有人問過這項工作，不代表存在市場需求、產品使用情況或付費意願。讀者問題，發布於 2026 年 7 月 2 日；單一與供應商有關聯的觀察紀錄。

不要根據按讚、帳號名稱或個人檔案資料，猜測誰會購買。請依據問題的文字與產品脈絡做出判斷。

2. 只在需要時蒐集少量樣本

Actor 是在託管環境中執行、用來蒐集資料的程式。Instagram Comments Scraper 的文件說明，其適用用途是儲存已知公開貼文或 Reels 的公開第一層留言。它不會傳回私訊、回覆文字、購買意圖或銷售資料。這些限制來自所提供的 0.1.21 建置版本公開介面規格查核。本指南未進行付費執行。公開預設建置版本，查核於 2026 年 10 月 25 日；僅檢查介面規格。

可從這份精簡輸入設定開始：

{
  "collectAllAvailable": false,
  "commentSortMode": "default",
  "maxCommentsPerPost": 10,
  "postUrls": ["https://www.instagram.com/reel/DIwcCZgxVZP/"]
}

請將範例 Reel 網址換成品牌自己發布、已知且公開的產品貼文。範例網址不能作為你產品的證據。這份輸入設定已通過公開輸入規則的檢查，但未為本文實際執行。

`postUrls` 存放貼文連結。`maxCommentsPerPost` 將每篇貼文的蒐集上限設為 10 則不重複的第一層留言。10 是上限，不是保證會取得的筆數。

將 `commentSortMode` 設為 `default`，會保留來源的預設順序。這不保證取得最新留言，也不保證是隨機樣本。文件中列出的其他選項，會依日期排列已蒐集的樣本。

將 `collectAllAvailable` 設為 false，會保留數量上限。設為 true 則會移除該上限，費用也可能大幅增加。當公開資料流結束、時間用完或來源發生錯誤時，執行仍可能停止。移除上限不代表已完整蒐集。

Actor 也接受選填的日期欄位 `commentsFrom` 和 `commentsUntil`。本範例未使用這些欄位。如果你加入日期，請將設定與審查備註一併保存。

Task 是為 Actor 儲存的一組輸入預設值。公開的 Instagram Customer Feedback Comment Dataset Task，查核於 2026 年 10 月 25 日；僅確認頁面存在 可作為起點。目前只確認了它的公開頁面存在，未透過已驗證身分的帳號讀取其儲存的輸入設定，也未執行。使用前，請檢查設定並替換範例值。

3. 將來源欄位與審查決定分開

加入標籤前，先保存原始匯出檔。欄位是每筆儲存資料中，一個有名稱的值。每筆資料代表一則蒐集到的第一層留言。

保留以下文件列出的來源欄位：

這些都是 Actor 欄位。問題標籤與核准狀態則是另外建立的人工欄位。公開輸出規格列出了上述來源欄位。公開預設建置版本，查核於 2026 年 10 月 25 日；未進行實際執行測試。

使用試算表時，請將識別碼保留為文字。識別碼用來辨識紀錄，不是用於計算的數字。檔案處理方式請參閱 Instagram 留言匯出指南。本次審查應專注於問題，以及回答所需的事實。

依據 `commentId` 移除重複匯入的資料。即使文字相同，只要兩則留言的識別碼不同，就應各自保留。缺少識別碼時，請將該筆資料保留為未解決。不要因兩筆資料的識別碼都是空白，或文字相同，就將它們合併。

保留缺失值。null 表示無法取得該值。零則是已觀察到的數值。`repliesCount` 為 null，不代表沒有回覆。回覆數為零，也不會提供回覆文字。這兩種值都無法告訴你，怎樣的產品回覆才有用。

4. 先閱讀貼文，再標記問題

開啟原始產品貼文。閱讀貼文說明，並查看其中展示的產品。接著，依問題需要，查核目前的產品頁面、價格條件、庫存資訊或配送條款。

簡短的問題可能有多種意思。「多少錢？」可能是在問同一篇貼文中的單品、組合或某個款式。「這個適合嗎？」需要先確定產品與用途。「有寄到這裡嗎？」則沒有指出目的地。

針對每則留言，記錄查核內容與時間。盡可能附上來源連結。如果貼文展示多項產品，請寫明問題看來是在問哪項產品，以及判斷原因。如果無法判斷，就將產品選擇保留為未解決。

有助於理解時，請人工閱讀可見的留言串脈絡。留言可能提到先前的回覆，但匯出資料中沒有該回覆。不要自行編造脈絡。如果無法取得貼文或相關回覆，請記錄缺口，並指派人員查核。

擬定答案時，請使用目前的產品條件。留言日期與蒐集時間的用途不同。前者顯示問題何時出現，後者顯示工具何時儲存該問題。兩個日期都無法證明目前的價格或庫存與先前的優惠相同。

5. 標記需求，列出下一項待查事實

使用少量標籤。標籤用來描述對方想知道的資訊，不是評估對方的價值，也不是預測購買行為。

這些是建議由分析人員使用的標籤。分析人員就是審查每筆資料的人。Actor 不會提供這些標籤。

一則留言可能需要多個標籤。「藍色那款多少錢？可以寄到這裡嗎？」需要同時查核價格與配送。請保留為一筆留言資料，並記錄兩個標籤。不要將它算成兩位買家。

將下一項待查事實寫成具體任務。「查核藍色款式的價格」能讓負責人清楚知道要做什麼。「後續跟進」則無法做到這點。

不要將配送目的地、訂單編號或其他個人資料放入共用的公開問題表。如果工作需要這些資料，請使用品牌一般且經核准的客服流程。公開問題表可以記錄需要私下查核，但不必複製個人資料。

既有訂單的投訴也需要謹慎處理。留言只是陳述訂單問題，無法獨立驗證該訂單或對方的買家身分。

6. 建立人工回覆審查表

在未更動的來源欄位旁加入審查欄位。記錄足夠的細節，讓其他人能理解這項決定。

可使用「待補脈絡」、「待查產品事實」、「待核准」、「已核准」及「已記錄行動」等狀態。也應允許「無須回覆產品問題」的狀態。這些都是人工設定的狀態，不是 Actor 輸出欄位。

即使還不知道對方是否會購買，明確的問題也可能值得回覆。請依答案是否正確、有用，決定是否核准。

為每則留言留下可追查的決定。贈獎活動審查指南 將相同的紀錄原則用於另一種目的。此處的決定關乎下一步回覆行動。請讓未解決的問題保持可見，不要勉強核准。

7. 完整範例：六則留言，未確認買家總數

原創虛構範例：本範例中的所有留言、識別碼、脈絡與審查決定，都是為教學而編寫。它們不是 Actor 的結果，也不是真實品牌的紀錄。

在這個虛構案例中，一篇產品貼文展示了標準款與藍色款式。貼文未標示價格。審查人員已查看這篇虛構貼文，但尚未查核目前價格，也未確認留言者的配送目的地。

擬議行動與已完成行動仍須分開記錄：

本範例未聲稱已發布任何回覆。擬議行動不等於核准，核准也不能證明有人已發布回覆。

以下計算的單位是留言資料筆數：

• 產品問題資料 = 2 筆價格問題 + 1 筆配送問題 = 3 筆。
• 既有訂單客服資料 = 1 筆。
• 無須採取行動的稱讚資料 = 1 筆。
• 未解決資料 = 1 筆。
• 總計 = 3 + 1 + 1 + 1 = 6 筆留言資料。

產品問題占比的算法，是將 3 筆產品問題資料除以 6 筆已審查留言資料，等於這份虛構樣本留言資料的 50%。這不是買家比例，也不是購買率。

目前沒有確立已確認的買家數。不要寫成零位買家，因為買家身分尚未驗證。也不要寫成三位買家，因為只是有三筆資料在詢問產品問題。這個範例也沒有確立六則留言由多少人撰寫。

C3 仍需查核目的地。「有寄到這裡嗎？」這句話不能證明符合配送資格。

8. 核准行動前，先檢查資訊缺口

檢查每筆資料是否有以下問題狀態：

1. 缺少來源識別資料：沒有可用留言識別碼的資料，應保留為未解決。不要根據重複文字猜測它是哪則留言。
2. 無法取得脈絡：記錄缺少的貼文、不明確的款式或無法取得的回覆。指派人員查核或提出釐清問題。
3. 缺少產品事實：在負責人查核目前的資料來源前，暫緩提出價格、庫存、配送或適用性說法。
4. 需要個人客服資料：共用表格只記錄已核准的客服行動。個人資料應留在一般客服流程中處理。
5. 已達蒐集上限或涵蓋範圍不明：只描述已儲存的樣本。不要聲稱樣本包含所有產品問題。
6. 未儲存任何資料：不要據此認定貼文沒有問題。先人工查看來源，再判斷空白結果代表什麼。
7. 行動狀態不明：將行動保留為未確認。草稿或核准紀錄不能證明回覆已發布。

發布前，負責人應再次開啟留言。確認產品脈絡、目前的答案來源，以及擬議回覆是否仍然適用。這是在查核行動，並不表示匯出資料包含所有回覆。

後續購買與客服處理結果，應另存於僅限負責人存取的紀錄中，並各自附上證據。單憑公開的價格問題，無法將銷售歸因於該留言。不要加入營收評分，讓不完整的紀錄看起來已有定論。