
先查看競爭對手的官方公告,以及你自行保存的證據。確認事件後,再用 Reddit 搜尋尋找相關討論。最後應產出一份附有日期的調價與反應簡報,並附上來源連結、納入規則及明確的限制。
1. 透過官方來源確認調價事件
一位研究者在公開提問中描述,自己會手動查看定價頁面、擷取畫面,並試著回想上週有哪些變動。這顯示了一項實際需要:保存附有日期的證據,而不是依賴記憶。這則公開提問提供了背景資訊,並不能衡量市場對此方法的需求。請參閱這則公開研究提問,發布於 2026 年 8 月 1 日;擷取於 2026 年 10 月 25 日;僅為一則公開描述研究困難的個案。
尋找競爭對手的官方公告、調價通知,或其他附有日期的聲明。保存來源網址,以及說明變更內容的原文段落。記錄你查看來源的時間。
分別記錄以下日期與時間:
- 公告日:公司宣布將進行變更的日期。
- 生效日:公告所述變更開始生效的日期。
- 觀察時間:你保存或查核來源的時間。
記錄通知適用的方案、地區、計費週期及客戶群。來源未說明的項目,應保留為未知。新訂閱適用某項變更,並不能證明現有訂閱也適用相同變更。
如果通知列出多個生效日,請選擇其中一個明確列出的群體進行比較。否則,應將各群體分開處理。單一的前後分界無法準確描述多個不同的開始日期。
僅憑目前的定價頁面,可能無法確認先前的價格或調價日期。如果你沒有保存舊版頁面,請勿編造其內容。記錄這項證據缺口。本指南未提供任何競爭對手的官方調價公告。因此,將此方法用於真實事件之前,你必須先提供該來源。
2. 蒐集貼文前,先定義比較方式
建立調價事件貼文群組表。此處的群組,是指符合你所訂時間及事件規則的一組貼文,並非一群已驗證身分的客戶。
寫下一個研究問題。例如:「這項方案變更生效前後,所選公開貼文中出現哪些反應?」將這個問題與銷售、客戶留存或市占率等問題分開處理。
盡可能使用長度相同的觀察時段。寫明每個時段的確切起點與終點。使用同一個時區,並說明如何處理只有日期、沒有時間的資料。分界必須足夠明確,避免同一篇貼文同時落入兩個時段。
清楚標示公告時間。生效日前的時段,可能已包含對公告的反應,不一定是人們尚未得知變更的時期。貼文在生效日之後發布,也不能證明作者看過公告或支付了新價格。
保存以下研究層級欄位:
| 欄位 | 應保留的內容 |
|---|---|
| 事件 | 競爭對手、產品、方案及公告所述變更 |
| 官方證據 | 來源網址、已保存的原文段落及觀察時間 |
| 事件日期 | 公告日、生效日及不確定之處 |
| 影響範圍 | 公告所述的客戶群、地區及計費條件 |
| 觀察時段 | 確切分界、時區及日期處理規則 |
| 搜尋範圍 | 查詢文字及選定的社群 |
| 蒐集設定 | 排序方式、時間設定、結果數上限及蒐集時間 |
| 納入規則 | 將貼文與本事件連結所需的文字證據 |
| 排除規則 | 較早的事件、無關產品或相關性尚未釐清的貼文 |
| 已知限制 | 缺少日期、無法取得文字、搜尋限制及其他事件 |
蒐集期間,請維持這份表格的規則不變。如果更改規則,請記錄原因,並依修訂後的規則重新審查兩個時段。
3. 使用 Actor 尋找候選貼文
Actor 是在代管環境中執行的資料蒐集程式。Reddit Search Scraper Actor 提供候選公開貼文,供人工審查。它不會確認官方調價事件,也不會替你完成這項比較。
所提供的證據記錄了 2026 年 10 月 25 日對公開預設建置版本 2.0.6 的查核。其宣告的輸入結構支援下方的少量輸入設定。靜態檢查確認,該輸入符合此結構。本簡報並未實際執行資料蒐集。此檢查無法證明服務即時可用、結果品質良好,或涵蓋範圍完整。請參閱預設建置版本證據,查核日期為 2026 年 10 月 25 日;僅涵蓋宣告欄位及靜態驗證。
{"maxResults":3,"query":"software price increase","sort":"relevance","time":"all"}可將此設定作為建議的起始輸入:
- 將 `query` 改為競爭對手名稱,以及可辨識該調價事件的搜尋詞。在表格中完整保留每個查詢的原文。
- 第一次蒐集查核時,將 `maxResults` 維持為 3。這是要求的結果數上限,不保證能取得三篇可用貼文。
- 擴大搜尋之前,先檢查傳回的紀錄。少量查核有助於評估紀錄,但不足以提供支持結論的證據。
- 可供比較的搜尋應使用一致的 `sort` 與 `time` 設定。記錄所有變更。
範例將 `sort` 設為 `relevance`,將 `time` 設為 `all`。它並未指定事件的兩個觀察時段。審查時,請根據貼文發布日期將其分配至各時段。按相關性排序的結果集,並不是兩個時段的均衡樣本。
Task 是為 Actor 儲存的一組預設輸入設定。Reddit Brand Mention Snapshot Task,查核日期為 2026 年 10 月 25 日;僅確認頁面存在,未驗證已儲存的設定,可作為起點之一。公開頁面列有 Task ID `cKrwlcryUm7yGmgkG`。其目前儲存的輸入及執行時的行為均未經驗證。請勿將上方建議的 JSON 描述為該 Task 已儲存的輸入。
為兩個時段記錄相同的預定社群範圍。檢查傳回貼文所屬的社群。如果之後增加查詢,請將這些查詢用於兩個時段,並保留其設定。
4. 分別保存來源欄位與審查欄位
找到一篇貼文,代表取得一筆來源紀錄。它不代表一位已驗證身分的買家、一筆受影響的訂閱,或一段包含所有回覆的完整討論。
保留此方法使用的下列宣告來源欄位:
| 來源欄位 | 研究用途 |
|---|---|
| `postId`, `canonicalPostUrl` | 識別貼文,並保留其公開來源網址 |
| `title`, `body` | 檢查可取得的文字及上下文 |
| `createdAt` | 資料可用時,評估發布時間 |
| `observedAt` | 保留觀察到該筆紀錄的時間 |
| `inputQuery` | 追溯找到該筆紀錄的搜尋查詢 |
| `requestedSubreddit`, `matchedSubreddit` | 檢查要求搜尋的社群及實際符合的社群資訊 |
| `status`, `unavailableFields` | 保留資料可用狀況及來源限制 |
這些是宣告的欄位,不保證每筆紀錄都包含所有有用的值。請檢查實際值。日期為空白或 null,表示日期未知,不表示日期較早。缺少文字,也不表示作者沒有反應。
將發布時間與觀察時間分開記錄。生效日後首次蒐集到的貼文,可能早在生效日前就已發布。如果缺少發布日期,請勿根據 `observedAt` 將貼文分配至某個時段。
在來源欄位旁新增自己的審查欄位:
| 讀者自行建立的欄位 | 用途 |
|---|---|
| 事件參照 | 將這次審查連結至官方變更紀錄 |
| 時段判定 | 生效前、生效後、時段之外或不確定 |
| 時間證據 | 日期依據及任何不確定之處 |
| 事件相關性 | 相關、無關或尚未釐清 |
| 支持判定的原文段落 | 支持相關性判定的確切原文 |
| 明確表述的反應 | 貼文實際如何描述該事件 |
| 產品背景 | 文中明述的方案、使用情境、計費條件,或未知 |
| 知悉情況與影響 | 作者是否表示已知悉變更或自身受到影響 |
| 重複情況註記 | 重複紀錄、引文或相關來源 |
| 其他解釋 | 可能影響解讀的事件或條件 |
| 審查紀錄 | 審查者、審查日期及規則版本 |
| 最終處理結果 | 納入、排除並註明原因,或待審 |
Actor 不會提供這些研究判斷。你必須閱讀證據後自行填寫。
公開貼文與官方公開通知,不同於僅限擁有者存取的紀錄。訂閱紀錄、帳戶通知及取消訂閱紀錄,都需要經授權才能存取。這套公開搜尋流程不會提供這些資料。任何經授權取得的非公開紀錄,都應與公開來源表格及其所支持的主張分開處理。
5. 為反應編碼前,先檢查事件相關性
僅憑發布時間還不夠。變更後發布的貼文,可能討論較早的漲價、其他方案,或只是對費用的一般抱怨。
使用已寫明的納入規則。必須有足夠的上下文,才能將文字與有紀錄可查的事件連結起來。僅有產品名稱加上「很貴」,可能仍無法確認兩者的關聯。如果保存的文字缺少足夠上下文,請開啟公開來源查看。如果仍無法判定,請將該列保留為待審。
針對每篇納入的貼文,記錄其中明確表述的反應,不要加強其語意。「我打算取消訂閱」表達的是意圖,不能證明已完成取消。「這會讓我們團隊花更多錢」是一項公開陳述,不是經過查核的帳單證據。對價格的提問,可以只記為提問。
編碼是依書面規則指派給文字的簡短標籤。彙整反應之前,先定義各項反應編碼。在每個編碼旁保留支持它的原文段落。如果文字不足以支持明確標籤,請允許標記為不明。
保留文中明述的條件。對年繳方式的抱怨,不同於對月費價格的抱怨。現有訂閱者適用的條件,也可能與新訂閱者不同。請勿自行補上未說明的方案或客戶身分。
如果貼文討論其他產品,請保留這項背景資訊,但不要將這項事件研究變成轉換產品比率的分析。另一篇關於研究明確表述的產品選擇與轉換條件的指南涵蓋了這個問題。僅憑對價格的反應,無法確認是否轉換產品,也無法確認其原因。
6. 處理重複紀錄與蒐集失敗
將同一個 `postId` 的多次觀察紀錄相互連結。不要因為另一個查詢也找到同一篇貼文,就重複計數。保留蒐集歷程,以便說明貼文的取得來源。
不同貼文 ID 的貼文,可能引用同一段抱怨。請保留這些來源,但要標記共同引用的文字。相同文字重複出現,不能證明有多位客戶各自經歷過相同情況。也不要只因措辭相似,就合併不同貼文。
比較之前,先檢查以下問題狀況:
| 狀況 | 必要處理方式 |
|---|---|
| 官方事件日期尚未釐清 | 不要做出明確的時段比較判斷 |
| 發布日期缺漏或不確定 | 不要將該貼文納入按時段劃分的群組 |
| 事件相關性尚未釐清 | 將該貼文保留為待審,不計入相關貼文數 |
| 無法取得文字 | 說明無法為該反應編碼 |
| 蒐集失敗,或未傳回可用紀錄 | 說明蒐集問題或結果為空 |
| 結果數上限可能限制涵蓋範圍 | 說明這是有限範圍的蒐集,不代表所有討論 |
| 搜尋範圍已變更 | 統一範圍,或揭露範圍差異 |
沒有傳回貼文,不能證明公開反應為零。同樣地,沒有觀察到取消訂閱的陳述,也不能證明取消訂閱的次數為零。缺少證據與觀察值為零,回答的是不同問題。
7. 比較所選貼文,並檢驗其他解釋
分別計算每個時段納入的貼文數。每次都要標明單位。六篇貼文就是六篇貼文,不代表六個人或六位受影響的客戶。
呈現任何比例時,都要說明分母,也就是用來計算總數的群組。計算某個主題的貼文數時,只應使用符合該項比較資格的貼文。時間不確定、涉及無關事件,或無法取得文字的紀錄,應列在適用總數之外,並清楚呈現。
你可以比較各時段出現的主題與條件。將計數放在支持它的原文段落旁。如果某個時段蒐集到較多貼文,不要直接將數量差異視為客戶情緒或討論量的變化。
檢查解讀是否過度依賴單一討論。關於檢查單一 Reddit 討論串是否主導結果的指南,說明了這項另需處理的計數單位問題。需要時可參考該指南,但不要將這項貼文比較轉換成客戶人數估計。
記錄其他可能的解釋。檢查來源是否提到調價前後的其他產品變更、服務中斷、促銷、帳務更正或其他事件。這些是審查時要問的問題,不表示這些事件確實發生過。
另外保留兩項未知資訊:每位作者是否看過公告,以及新價格是否適用於該作者。長度相同的觀察時段無法消除這些未知資訊。前後出現的模式,可以支持對所選討論的描述,但不能證明因果關係。
8. 透過原創虛構範例演練
本例所有內容均為原創虛構情節。它不是 Actor 的執行結果、客戶成果,也不是對真實公司觀察所得的發現。
一則虛構官方公告的日期為 10 月 3 日。調價於 10 月 10 日生效。研究者使用相同的查詢與社群範圍,比較 10 月 3 日至 9 日,以及 10 月 10 日至 16 日。每個觀察時段皆為七天。
兩個時段都在公告發布之後。「之前」是指 10 月 10 日生效日之前,不是指人們得知變更之前。
研究者有九篇候選貼文:
| 候選貼文群組 | 貼文數 | 處理方式 |
|---|---|---|
| 生效日之前 | 3 | 全部符合事件相關性規則 |
| 生效日當天或之後 | 4 | 三篇符合規則;一篇討論較早的變更 |
| 發布日期不確定 | 2 | 不納入時段比較 |
| 候選貼文總數 | 9 | 保留每篇貼文的處理結果 |
以下計算以貼文為單位:
- 3 篇生效前貼文 + 4 篇生效後貼文 + 2 篇日期不確定的貼文 = 9 篇候選貼文。
- 9 篇候選貼文 − 2 篇日期不確定的貼文 = 7 篇日期明確的貼文。
- 7 篇日期明確的貼文 − 1 篇討論較早事件的貼文 = 6 篇可供比較且與本事件相關的貼文。
- 最終比較包含 3 篇生效前貼文與 3 篇生效後貼文。
討論較早事件的貼文,即使發布日期落在生效後時段,仍應排除。兩篇日期不確定的貼文,也仍不納入按時段劃分的群組。不要根據蒐集日期分配它們的時段。
比較六篇合格貼文中明確表述的反應與條件。本例沒有提供反應文字,因此無法支持任何主題計數或情緒變化的判斷。它只用來示範如何計算納入的貼文數。
這項虛構比較的分母,是六篇日期明確且與事件相關的貼文。被排除的三篇,仍應清楚列在處理紀錄中。六篇合格貼文不代表六位受影響的客戶,也無法據此估計客戶流失。
來源與延伸閱讀
作者 Chronometrica · 更新日期
返回頂端 ↑

