# 研究競爭對手調價前後的公開反應

若要比較競爭對手調價前後的回饋，先透過附有日期的官方來源確認調價內容。以生效日為界，設定長度相同的觀察時段。使用相同的搜尋詞，搜尋相同的公開社群。只比較明確討論該事件的貼文。在報告中保留其他可能的解釋，並列出缺少的資訊。公開反應無法衡量客戶流失，也就是客戶停止使用產品。公開反應也無法證明調價造成了某項業務成果。

先查看競爭對手的官方公告，以及你自行保存的證據。確認事件後，再用 Reddit 搜尋尋找相關討論。最後應產出一份附有日期的調價與反應簡報，並附上來源連結、納入規則及明確的限制。

## 1. 透過官方來源確認調價事件

一位研究者在公開提問中描述，自己會手動查看定價頁面、擷取畫面，並試著回想上週有哪些變動。這顯示了一項實際需要：保存附有日期的證據，而不是依賴記憶。這則公開提問提供了背景資訊，並不能衡量市場對此方法的需求。請參閱這則[公開研究提問，發布於 2026 年 8 月 1 日；擷取於 2026 年 10 月 25 日；僅為一則公開描述研究困難的個案](https://www.reddit.com/r/growmybusiness/comments/1vcb4eo/how_do_you_actually_keep_track_of_what/)。

尋找競爭對手的官方公告、調價通知，或其他附有日期的聲明。保存來源網址，以及說明變更內容的原文段落。記錄你查看來源的時間。

分別記錄以下日期與時間：

- 公告日：公司宣布將進行變更的日期。
- 生效日：公告所述變更開始生效的日期。
- 觀察時間：你保存或查核來源的時間。

記錄通知適用的方案、地區、計費週期及客戶群。來源未說明的項目，應保留為未知。新訂閱適用某項變更，並不能證明現有訂閱也適用相同變更。

如果通知列出多個生效日，請選擇其中一個明確列出的群體進行比較。否則，應將各群體分開處理。單一的前後分界無法準確描述多個不同的開始日期。

僅憑目前的定價頁面，可能無法確認先前的價格或調價日期。如果你沒有保存舊版頁面，請勿編造其內容。記錄這項證據缺口。本指南未提供任何競爭對手的官方調價公告。因此，將此方法用於真實事件之前，你必須先提供該來源。

## 2. 蒐集貼文前，先定義比較方式

建立調價事件貼文群組表。此處的群組，是指符合你所訂時間及事件規則的一組貼文，並非一群已驗證身分的客戶。

寫下一個研究問題。例如：「這項方案變更生效前後，所選公開貼文中出現哪些反應？」將這個問題與銷售、客戶留存或市占率等問題分開處理。

盡可能使用長度相同的觀察時段。寫明每個時段的確切起點與終點。使用同一個時區，並說明如何處理只有日期、沒有時間的資料。分界必須足夠明確，避免同一篇貼文同時落入兩個時段。

清楚標示公告時間。生效日前的時段，可能已包含對公告的反應，不一定是人們尚未得知變更的時期。貼文在生效日之後發布，也不能證明作者看過公告或支付了新價格。

保存以下研究層級欄位：

| 欄位 | 應保留的內容 |
| --- | --- |
| 事件 | 競爭對手、產品、方案及公告所述變更 |
| 官方證據 | 來源網址、已保存的原文段落及觀察時間 |
| 事件日期 | 公告日、生效日及不確定之處 |
| 影響範圍 | 公告所述的客戶群、地區及計費條件 |
| 觀察時段 | 確切分界、時區及日期處理規則 |
| 搜尋範圍 | 查詢文字及選定的社群 |
| 蒐集設定 | 排序方式、時間設定、結果數上限及蒐集時間 |
| 納入規則 | 將貼文與本事件連結所需的文字證據 |
| 排除規則 | 較早的事件、無關產品或相關性尚未釐清的貼文 |
| 已知限制 | 缺少日期、無法取得文字、搜尋限制及其他事件 |

蒐集期間，請維持這份表格的規則不變。如果更改規則，請記錄原因，並依修訂後的規則重新審查兩個時段。

## 3. 使用 Actor 尋找候選貼文

Actor 是在代管環境中執行的資料蒐集程式。[Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper) 提供候選公開貼文，供人工審查。它不會確認官方調價事件，也不會替你完成這項比較。

所提供的證據記錄了 2026 年 10 月 25 日對公開預設建置版本 2.0.6 的查核。其宣告的輸入結構支援下方的少量輸入設定。靜態檢查確認，該輸入符合此結構。本簡報並未實際執行資料蒐集。此檢查無法證明服務即時可用、結果品質良好，或涵蓋範圍完整。請參閱[預設建置版本證據，查核日期為 2026 年 10 月 25 日；僅涵蓋宣告欄位及靜態驗證](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)。

```json
{"maxResults":3,"query":"software price increase","sort":"relevance","time":"all"}
```

3. 使用 Actor 尋找候選貼文

可將此設定作為建議的起始輸入：

1. 將 `query` 改為競爭對手名稱，以及可辨識該調價事件的搜尋詞。在表格中完整保留每個查詢的原文。
2. 第一次蒐集查核時，將 `maxResults` 維持為 3。這是要求的結果數上限，不保證能取得三篇可用貼文。
3. 擴大搜尋之前，先檢查傳回的紀錄。少量查核有助於評估紀錄，但不足以提供支持結論的證據。
4. 可供比較的搜尋應使用一致的 `sort` 與 `time` 設定。記錄所有變更。

範例將 `sort` 設為 `relevance`，將 `time` 設為 `all`。它並未指定事件的兩個觀察時段。審查時，請根據貼文發布日期將其分配至各時段。按相關性排序的結果集，並不是兩個時段的均衡樣本。

Task 是為 Actor 儲存的一組預設輸入設定。[Reddit Brand Mention Snapshot Task，查核日期為 2026 年 10 月 25 日；僅確認頁面存在，未驗證已儲存的設定](https://apify.com/chronometrica/reddit-search-scraper/examples/reddit-brand-mention-snapshot)，可作為起點之一。公開頁面列有 Task ID `cKrwlcryUm7yGmgkG`。其目前儲存的輸入及執行時的行為均未經驗證。請勿將上方建議的 JSON 描述為該 Task 已儲存的輸入。

為兩個時段記錄相同的預定社群範圍。檢查傳回貼文所屬的社群。如果之後增加查詢，請將這些查詢用於兩個時段，並保留其設定。

## 4. 分別保存來源欄位與審查欄位

找到一篇貼文，代表取得一筆來源紀錄。它不代表一位已驗證身分的買家、一筆受影響的訂閱，或一段包含所有回覆的完整討論。

保留此方法使用的下列宣告來源欄位：

| 來源欄位 | 研究用途 |
| --- | --- |
| `postId`, `canonicalPostUrl` | 識別貼文，並保留其公開來源網址 |
| `title`, `body` | 檢查可取得的文字及上下文 |
| `createdAt` | 資料可用時，評估發布時間 |
| `observedAt` | 保留觀察到該筆紀錄的時間 |
| `inputQuery` | 追溯找到該筆紀錄的搜尋查詢 |
| `requestedSubreddit`, `matchedSubreddit` | 檢查要求搜尋的社群及實際符合的社群資訊 |
| `status`, `unavailableFields` | 保留資料可用狀況及來源限制 |

這些是宣告的欄位，不保證每筆紀錄都包含所有有用的值。請檢查實際值。日期為空白或 null，表示日期未知，不表示日期較早。缺少文字，也不表示作者沒有反應。

將發布時間與觀察時間分開記錄。生效日後首次蒐集到的貼文，可能早在生效日前就已發布。如果缺少發布日期，請勿根據 `observedAt` 將貼文分配至某個時段。

在來源欄位旁新增自己的審查欄位：

| 讀者自行建立的欄位 | 用途 |
| --- | --- |
| 事件參照 | 將這次審查連結至官方變更紀錄 |
| 時段判定 | 生效前、生效後、時段之外或不確定 |
| 時間證據 | 日期依據及任何不確定之處 |
| 事件相關性 | 相關、無關或尚未釐清 |
| 支持判定的原文段落 | 支持相關性判定的確切原文 |
| 明確表述的反應 | 貼文實際如何描述該事件 |
| 產品背景 | 文中明述的方案、使用情境、計費條件，或未知 |
| 知悉情況與影響 | 作者是否表示已知悉變更或自身受到影響 |
| 重複情況註記 | 重複紀錄、引文或相關來源 |
| 其他解釋 | 可能影響解讀的事件或條件 |
| 審查紀錄 | 審查者、審查日期及規則版本 |
| 最終處理結果 | 納入、排除並註明原因，或待審 |

Actor 不會提供這些研究判斷。你必須閱讀證據後自行填寫。

公開貼文與官方公開通知，不同於僅限擁有者存取的紀錄。訂閱紀錄、帳戶通知及取消訂閱紀錄，都需要經授權才能存取。這套公開搜尋流程不會提供這些資料。任何經授權取得的非公開紀錄，都應與公開來源表格及其所支持的主張分開處理。

## 5. 為反應編碼前，先檢查事件相關性

僅憑發布時間還不夠。變更後發布的貼文，可能討論較早的漲價、其他方案，或只是對費用的一般抱怨。

使用已寫明的納入規則。必須有足夠的上下文，才能將文字與有紀錄可查的事件連結起來。僅有產品名稱加上「很貴」，可能仍無法確認兩者的關聯。如果保存的文字缺少足夠上下文，請開啟公開來源查看。如果仍無法判定，請將該列保留為待審。

針對每篇納入的貼文，記錄其中明確表述的反應，不要加強其語意。「我打算取消訂閱」表達的是意圖，不能證明已完成取消。「這會讓我們團隊花更多錢」是一項公開陳述，不是經過查核的帳單證據。對價格的提問，可以只記為提問。

編碼是依書面規則指派給文字的簡短標籤。彙整反應之前，先定義各項反應編碼。在每個編碼旁保留支持它的原文段落。如果文字不足以支持明確標籤，請允許標記為不明。

保留文中明述的條件。對年繳方式的抱怨，不同於對月費價格的抱怨。現有訂閱者適用的條件，也可能與新訂閱者不同。請勿自行補上未說明的方案或客戶身分。

如果貼文討論其他產品，請保留這項背景資訊，但不要將這項事件研究變成轉換產品比率的分析。另一篇關於[研究明確表述的產品選擇與轉換條件](/zh-Hant/articles/reddit-%E7%94%A8%E6%88%B6%E8%BD%89%E7%94%A8%E7%94%A2%E5%93%81%E5%8E%9F%E5%9B%A0/)的指南涵蓋了這個問題。僅憑對價格的反應，無法確認是否轉換產品，也無法確認其原因。

## 6. 處理重複紀錄與蒐集失敗

將同一個 `postId` 的多次觀察紀錄相互連結。不要因為另一個查詢也找到同一篇貼文，就重複計數。保留蒐集歷程，以便說明貼文的取得來源。

不同貼文 ID 的貼文，可能引用同一段抱怨。請保留這些來源，但要標記共同引用的文字。相同文字重複出現，不能證明有多位客戶各自經歷過相同情況。也不要只因措辭相似，就合併不同貼文。

比較之前，先檢查以下問題狀況：

| 狀況 | 必要處理方式 |
| --- | --- |
| 官方事件日期尚未釐清 | 不要做出明確的時段比較判斷 |
| 發布日期缺漏或不確定 | 不要將該貼文納入按時段劃分的群組 |
| 事件相關性尚未釐清 | 將該貼文保留為待審，不計入相關貼文數 |
| 無法取得文字 | 說明無法為該反應編碼 |
| 蒐集失敗，或未傳回可用紀錄 | 說明蒐集問題或結果為空 |
| 結果數上限可能限制涵蓋範圍 | 說明這是有限範圍的蒐集，不代表所有討論 |
| 搜尋範圍已變更 | 統一範圍，或揭露範圍差異 |

沒有傳回貼文，不能證明公開反應為零。同樣地，沒有觀察到取消訂閱的陳述，也不能證明取消訂閱的次數為零。缺少證據與觀察值為零，回答的是不同問題。

## 7. 比較所選貼文，並檢驗其他解釋

分別計算每個時段納入的貼文數。每次都要標明單位。六篇貼文就是六篇貼文，不代表六個人或六位受影響的客戶。

呈現任何比例時，都要說明分母，也就是用來計算總數的群組。計算某個主題的貼文數時，只應使用符合該項比較資格的貼文。時間不確定、涉及無關事件，或無法取得文字的紀錄，應列在適用總數之外，並清楚呈現。

你可以比較各時段出現的主題與條件。將計數放在支持它的原文段落旁。如果某個時段蒐集到較多貼文，不要直接將數量差異視為客戶情緒或討論量的變化。

檢查解讀是否過度依賴單一討論。關於[檢查單一 Reddit 討論串是否主導結果](/zh-Hant/articles/%E5%96%AE%E4%B8%80%E8%A8%8E%E8%AB%96%E4%B8%B2%E6%98%AF%E5%90%A6%E4%B8%BB%E5%B0%8E%E7%A0%94%E7%A9%B6%E7%B5%90%E6%9E%9C/)的指南，說明了這項另需處理的計數單位問題。需要時可參考該指南，但不要將這項貼文比較轉換成客戶人數估計。

記錄其他可能的解釋。檢查來源是否提到調價前後的其他產品變更、服務中斷、促銷、帳務更正或其他事件。這些是審查時要問的問題，不表示這些事件確實發生過。

另外保留兩項未知資訊：每位作者是否看過公告，以及新價格是否適用於該作者。長度相同的觀察時段無法消除這些未知資訊。前後出現的模式，可以支持對所選討論的描述，但不能證明因果關係。

## 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 篇生效後貼文。

討論較早事件的貼文，即使發布日期落在生效後時段，仍應排除。兩篇日期不確定的貼文，也仍不納入按時段劃分的群組。不要根據蒐集日期分配它們的時段。

比較六篇合格貼文中明確表述的反應與條件。本例沒有提供反應文字，因此無法支持任何主題計數或情緒變化的判斷。它只用來示範如何計算納入的貼文數。

這項虛構比較的分母，是六篇日期明確且與事件相關的貼文。被排除的三篇，仍應清楚列在處理紀錄中。六篇合格貼文不代表六位受影響的客戶，也無法據此估計客戶流失。

## 準備下一次證據查核

最後，撰寫一份簡報，說明官方公布的調價事件、兩個觀察時段、搜尋範圍、納入的貼文數、觀察到的主題，以及尚未釐清的問題。將每項解讀連結至支持它的來源段落。說明生效日前的比較時段是否已在公告發布之後。

根據尚缺的證據，決定下一步。如果事件的適用範圍不明，取得更清楚的官方通知。如果缺少背景資訊，查看原始討論。如果某個時段的可用證據太少，蒐集更多可供比較的候選貼文。若要回答業務成果相關問題，則需要適當且經授權取得的紀錄，以及另一套研究方法。

先建立官方調價事件紀錄，再使用 [Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper)，以建議的少量輸入設定尋找候選公開貼文。在擴大蒐集範圍或提出結論之前，先檢查貼文的發布時間及其與事件的相關性。

## 來源與延伸閱讀

- [公開的競爭對手研究提問 — 發布於 2026 年 8 月 1 日；擷取於 2026 年 10 月 25 日；僅供背景參考，不代表市場需求](https://www.reddit.com/r/growmybusiness/comments/1vcb4eo/how_do_you_actually_keep_track_of_what/)
- [Reddit Search Scraper 預設建置版本 2.0.6 — 查核日期為 2026 年 10 月 25 日；僅涵蓋宣告的輸入與輸出欄位及靜態驗證，未實際執行](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)
- [Reddit Brand Mention Snapshot Task — 查核日期為 2026 年 10 月 25 日；頁面列有確切 Task ID，已儲存的設定及執行時的行為未經驗證](https://apify.com/chronometrica/reddit-search-scraper/examples/reddit-brand-mention-snapshot)