
直接回覆是針對你那則特定留言的回應。更深層回覆則是回應其下的另一則回覆。閱讀對話時,兩者都可能有用,但它們屬於不同的結果。
本指南說明如何製作經過核對的直接回覆表格。擷取工具提供公開紀錄。你必須核對貼文、確認自己的留言,並判斷哪些紀錄應列入表格。
1. 確認 Spotlight 與你自己的留言
讀者的問題很實際:如何找出自己在 Snapchat Spotlight 留言後收到的回覆?提供的公開讀者提問,擷取於 2026 年 8 月 11 日;僅一則問題直接問到了這件事。這則提問無法證明有多少使用者遇到同樣的問題。
如果你能開啟已知的 Spotlight 並找到自己的留言,就從這裡開始。閱讀相關的公開對話。若想了解回覆內容,或決定是否回應,親自查看很有幫助。若只是閱讀已經找得到的對話,就不需要匯出資料。
若要製作經過核對的匯出結果,請在擷取前確認以下條件:
- 儲存公開 Spotlight 的 URL,也就是它的網址。
- 儲存你留言的確切 ID。
- 保留可證明該留言位於指定 Spotlight 的證據。
- 保留可證明該留言由你的帳號發布的證據。
如果已有經過核實的紀錄,請使用該紀錄。本指南並未確認可從通知取得未知留言 ID 的方法,也未提供 Snapchat 未公開說明之畫面的操作指示。
僅憑相似文字,無法確認那就是你的留言。單靠顯示名稱也不夠。如果儲存的證據無法確認目標留言的身分,請停止查找。增加資料列,無法解決目標尚未確認的問題。
公開留言紀錄與僅供帳號擁有者查看的紀錄也不同。文件記載的工具會擷取對外公開的留言與回覆。其規格不提供私訊或通知。不要將公開資料匯出結果視為帳號私人活動的副本。公開 Actor 規格,核對於 2026 年 10 月 25 日;僅限文件記載的欄位。
2. 視需要設定一次小規模公開資料擷取
Actor 是在託管環境中執行的資料擷取程式。Chronometrica Snapchat Comments Scraper 接受已知的公開 Spotlight 網址。它的 `includeReplies` 設定可要求擷取公開回覆,並將每則回覆列為個別計費的資料列。此設定預設為 `false`,使用本方法時,請設為 `true`。公開輸入規格,核對於 2026 年 10 月 25 日;未進行實際執行測試。
請使用提供的輸入格式:
{
"includeReplies": true,
"startUrls": [
"https://www.snapchat.com/@mrbeast/spotlight/W7_EDlXWTBiXAEEniNoMPwAAYbHZzZmtrYm1jAZhMOQmTAZhMOQfqAAAAAQ"
]
}將範例網址換成你已知的公開 Spotlight 網址。範例只示範有效的輸入格式,並不代表你的貼文,也不能證明你的留言出現在該處。本指南未實際執行資料擷取。
先從一則貼文開始。已核對的公開輸入結構定義中,沒有設定單則貼文資料列上限的輸入欄位。結構定義會規定可接受的欄位及其資料型別。資料列上限則會限制每則貼文最多擷取多少筆紀錄。不要加入結構定義未記載的輸入欄位。
打算執行前,先查看可用的費用控制設定。請將實際使用的完整輸入與匯出紀錄一併保留。這樣可以記錄你要求擷取的內容,但不代表你已取得所有可用回覆。
Task 是已儲存的輸入預設組合。公開的 Snapchat Spotlight Comments and Replies Task,核對於 2026 年 10 月 25 日;僅確認頁面存在確實存在。其儲存設定未透過已登入並通過身分驗證的帳號核對,也未實際執行。使用前請核對輸入內容。
3. 儲存核對每則回覆所需的欄位
資料列是匯出檔案中的一筆紀錄。分類前,請先儲存原始資料列。保留足夠資訊,以便將每一列對應到要求擷取的貼文,以及它確切回應的上層留言。
上層留言是某則回覆直接回應的特定留言。深度表示留言在對話中的層級。深度可提供上下文,但判斷一則回覆是否直接回應目標留言,必須依據上層留言 ID。
目前的輸出規格記載了以下欄位。規格列有這些欄位,不代表某次實際擷取一定能提供完整上下文。公開輸出規格,核對於 2026 年 10 月 25 日;僅限文件記載的輸出。
| 欄位 | 需保留及核對的內容 |
|---|---|
| `inputUrl` | 要求擷取時提供的網址。 |
| `postUrl` | 傳回的公開貼文網址。 |
| `snapId` | 傳回的 Spotlight ID。請核對是否為指定貼文。 |
| `commentId` | 用來識別每則不同留言的留言 ID。 |
| `parentCommentId` | 用來判斷是否為直接回覆的確切上層留言 ID。 |
| `depth` | 紀錄中的對話層級。請保留作為上下文資訊。 |
| `text` | 供人工閱讀的留言文字。 |
| `authorId` | 作者 ID,若有提供。若值缺漏,請保留缺漏狀態。 |
| `publishedAt` | 留言發布時間,若有提供。 |
| `observedAt` | 觀察到該紀錄的時間。 |
| `status` | 傳回的紀錄狀態。請保留原始值。 |
| `statusReason` | 傳回的狀態說明,若有提供。 |
| `replyCount` | 回覆數量。這個欄位不會提供回覆紀錄本身。 |
| `postCommentCount` | 貼文留言數量,若有提供。這個數值不能證明匯出內容完整。 |
發布時間與觀察時間回答的是不同問題。前者表示留言何時發布,後者表示何時看見該紀錄。不要用觀察時間填補缺漏的發布時間。
請區分缺漏值與零。缺少上層留言 ID,表示尚未確認上層留言關係,不表示該留言沒有上層留言。數量缺漏表示數量未知。紀錄中的零則是一個數值。
你可以自行新增目標 ID、判定結果、原因與來源參照等欄位。請標明這些是你新增的審核欄位,並非 Actor 原生輸出欄位。來源參照應能識別原始匯出資料列,並保留其公開貼文連結。不要自行編造直達留言的網址。
4. 為已知留言 ID 建立一份索引
索引是一張查找表。在此任務中,它將每個已知的 `commentId` 對應到已儲存的紀錄。請另用觀察紀錄表保留重複出現的情況。一次觀察,是指在匯入檔案中看見某筆紀錄一次。
請依序執行以下步驟:
- 核對傳回的貼文身分是否與指定 Spotlight 相符。
- 每個不同的留言 ID,在索引中只記錄一次。
- 在觀察紀錄表中保留每次匯入時看見該紀錄的情況。
- 將重複觀察對應到既有索引項目。
- 保留已儲存且經過核實的目標留言,以及確認其身分的證據。
- 若紀錄的必要身分或上層留言關係尚未獲得證實,請暫緩判定。
不要將重複觀察算成額外回覆。如果同一則回覆在檔案中出現兩次,它仍然只有一個不重複的留言 ID。
後續匯出檔案可能只涵蓋部分公開對話,因此未必包含你的目標留言。這種缺漏不能推翻先前儲存的身分確認結果。請保留先前核實的紀錄與證據。關鍵在於目標留言的身分是否仍可確認。
若想看更完整的範例,了解如何分開保留要求擷取的貼文、不重複資料列與匯入觀察紀錄,請參閱 TikTok 留言資料集指南。該指南的產品設定適用於 TikTok。不要將那些設定複製到這裡的 Snapchat 輸入中。
5. 依確切的上層留言身分判定直接回覆
請對每筆候選紀錄使用相同的判定方式。先核對 Spotlight,再核對上層留言 ID。最後,確認納入結果的留言 ID 沒有重複。
| 已核對紀錄中的證據 | 你的審核判定 |
|---|---|
| 已確認為指定 Spotlight,且上層留言 ID 等於你已核實的留言 ID | 列為直接回覆。 |
| 上層留言 ID 等於某則已接受回覆的 ID | 保留為更深層的上下文。 |
| 上層留言位於其他分支 | 與目標留言的回覆分開保留。 |
| 上層留言資料缺漏或尚未獲得證實 | 保留為尚待確認。 |
| Spotlight 身分不符 | 從本次目標查找中排除。 |
| 你的目標留言身分尚未確認 | 暫緩整個目標查找。 |
這些是讀者的審核判定,不是 Actor 的 `status` 欄位所記載的值。
不要只篩選深度為一的紀錄。你自己的留言可能已經是一則巢狀回覆,也就是位於其他回覆之下的回覆。在這種情況下,直接回覆你的留言可能具有更大的深度。確切的上層留言關係仍能正確識別它。
不要根據資料列順序、相似文字或鄰近的顯示名稱推測上層留言。試算表可能將無關紀錄排在一起。相鄰位置無法證明對話關係。
Facebook 未獲回覆問題指南說明,當問題位於討論串內時,為何確切的留言關係很重要。該指南的品牌回應審核流程適用於另一種任務。在這裡,你只需判斷哪些觀察到的紀錄直接回覆了你已核實的留言。
結構上的相符,也不能確認回覆的含義。決定如何回應前,請閱讀文字及相關的公開上下文。本方法識別的是紀錄之間的關係,不會自動解讀或發布回覆。
6. 演練一個原創虛構範例
原創虛構範例。本例使用虛構 ID,不包含實際擷取的 Snapchat 資料或私人帳號資料。它示範的是你的審核表格,不是經過驗證的實際執行輸出。
假設已知的 Spotlight 是 S1。你已確認的留言是 T2。它的上層留言是 ROOT,深度為一。ROOT 是本例中虛構的留言 ID。
以下所有資料列都屬於 S1。在這個虛構練習中,各列的貼文身分均已核對。
| 留言 ID | 上層留言 ID | 深度 | 審核判定 | 原因 |
|---|---|---|---|---|
| T2 | ROOT | 1 | 已核實的目標 | 儲存的證據確認這是你的留言。 |
| R1 | T2 | 2 | 直接回覆 | 其上層留言是目標 T2。 |
| R2 | T2 | 2 | 直接回覆 | 其上層留言是目標 T2。 |
| D1 | R1 | 3 | 更深層上下文 | 它回覆的是 R1。 |
| O1 | ROOT | 1 | 其他分支 | 它與 T2 有相同的上層留言,但並未回覆 T2。 |
| M1 | 缺漏 | 缺漏 | 尚待確認 | 其上層留言關係尚未獲得證實。 |
M1 的深度缺漏,表示這個虛構範例中的審核紀錄不完整。這並非宣稱目前的輸出結構定義接受深度為空值。該結構定義將 `depth` 定為整數。
R1 與 R2 通過核對,因為它們的上層留言都是 T2。深度為二,不影響它們屬於直接回覆。D1 位於 R1 之下,因此提供更深層的上下文。O1 則屬於另一個分支。
若只篩選深度為一的紀錄,就會漏掉這兩則直接回覆,還會納入並未回應 T2 的 O1。因此,是否接受為直接回覆,必須依據上層留言身分。
現在假設匯入檔案多包含一份 R1。請同時列出以下兩種總數:
7 筆匯入觀察紀錄 − 1 筆重複觀察紀錄 = 6 個不重複的留言 ID。
將這六個不重複的 ID 分類:
1 則目標留言 + 2 則直接回覆 + 1 則更深層回覆 + 1 列其他分支紀錄 + 1 列尚待確認紀錄 = 6 個不重複的留言 ID。
直接回覆結果是兩個不重複的留言 ID:R1 與 R2。這不代表有兩個人回覆。這個練習並未確認作者是否為不同的人。
交付 R1 與 R2 時,請附上其來源資料列參照及已知的 Spotlight。將 D1 保留為更深層的上下文。將 O1 分開保留。將 M1 保留為尚待確認。如果無法確認 T2 的身分,請暫緩整個查找。
7. 核對結果並說明限制
接受表格結果前,請完成以下核對:
- 確認目標 ID 仍與已儲存的身分證據相符。
- 確認每則已接受回覆都屬於指定 Spotlight。
- 確認每則已接受回覆的 `parentCommentId` 都等於目標 ID。
- 確認每個已接受的 `commentId` 在結果中只出現一次。
- 確認每則已接受回覆都有來源資料列參照。
- 再次匯入同一份已儲存的匯出檔案,確認沒有新增任何留言身分。
- 將更深層上下文、其他分支與尚待確認的資料列分開保留。
重複匯入是為了核對你處理同一份檔案的方式。這是建議的驗證步驟,本指南並未實際執行這項測試。它不能證明重新進行即時擷取會傳回相同紀錄。
如果沒有任何不重複的回覆通過核對,請回報「這份已核對檔案中,接受的直接回覆數為零」。不要回報沒有人回覆。公開可見不代表一定能取得完整的回覆集合。
如果缺少必要的上層留言值,請將該列保留為尚待確認。如果目標留言本身尚未確認,請回報查找結果尚待確認。這些狀態與觀察到的數量為零不同。
交付說明應列明已知的 Spotlight、已核實的目標 ID、各次觀察時間、匯入觀察紀錄總數,以及已接受且不重複的直接回覆數。請說明哪些紀錄尚待確認,以及公開可見範圍的限制。回覆數量欄位不能取代這份經過核對的實際回覆紀錄清單。
來源與延伸閱讀
作者 Chronometrica · 更新日期
返回頂端 ↑
