# 如何為客戶研究選擇 subreddit

為客戶研究選擇 subreddit，先要在不同候選社群分別測試同一個問題查詢，以建立配對的來源框。Actor 是託管的資料收集程式。Task 是已儲存的輸入預設。抽樣框是你將從中收集資料的已界定來源集合。Reddit 社群或 subreddit 是公開討論空間。其成員並非全體客戶的代表性樣本。

## 收集設定

開始設定時，先連結 [Actor](https://apify.com/chronometrica/reddit-search-scraper) 與 [Task](https://apify.com/chronometrica/reddit-search-scraper/examples/search-posts-in-subreddits)。目前預設使用查詢「customer feedback」、subreddit「SaaS」、「Entrepreneur」與「smallbusiness」、maxResults 150、sort「relevance」，以及 time「year」。這些通用預設並未被證明為最佳社群。請以有理據的候選來源取代它們。

用相同的查詢、排序、時間，以及每次執行上限 3 則貼文，比較分開的執行。一次混合執行會在所有來源之間共用 maxResults，使一個大型來源可以提早用盡上限。保留關鍵輸出欄位：inputQuery、requestedSubreddit、matchedSubreddit、postId、canonicalPostUrl、title、body、createdAt、rank、status、unavailableFields 與 observedAt。

正文情境缺失的貼文維持未審閱。較低的來源 rank 表示搜尋次序，而不是貼文質素。Post ID 代表已發現的貼文，而不是個別客戶。

輸出中每個 searchResults 項目包含 query、subreddit、status、reason、candidatesFound、rowsSaved、duplicatesSkipped、endReason、source 與 sourceUrl。執行摘要包括 status、statusReason、isComplete、query、searchesPlanned、searchesSucceeded、candidatesFound、usefulRows、rowsSaved、duplicatesSkipped、stopReason 與 observedAt。使用與你的審計相關的收集診斷，並略過內部成本欄位。

在最近一次對照執行中，searchResults[0] 記錄了 subreddit=learnpython、status=ok、rowsSaved=3、endReason=max_results_reached 與 source=reddit_rss。全域狀態 isComplete=true 確認的是已完成的處理結果，而不是整個社群母體的覆蓋。請注意，列層級的 requestedSubreddit 與 matchedSubreddit 欄位，可以不同於摘要的 subreddit 欄位。

## 逐步建立來源框

1. 寫明客戶情境、決策與所需資訊。把使用者社群、專業從業者社群、產品支援社群，以及一般創辦人討論分開，作為不同的來源角色。
2. 從實際主題討論中找出候選公開社群。閱讀其用途、規則與近期相關討論串。不要只憑社群名稱推斷買家身份。
3. 為每個社群寫下納入原因或排除原因。選擇來源是為了取得不同觀點，而不只是因為成員人數多。尊重來源的情境，不要把研究當作推廣的許可。
4. 在每個已選社群分別執行[同一個小型查詢](/zh-Hant/articles/%E4%BB%A5%E8%BC%83%E5%B0%91%E9%9B%9C%E8%A8%8A%E8%BF%BD%E8%B9%A4-reddit-%E9%97%9C%E9%8D%B5%E5%AD%97/)。使上限、排序、時間窗與觀察時間可以互相比較。儲存所要求的 subreddit 與所配對的 subreddit，以審閱任何超出範圍的結果。
5. 檢視返回的貼文，辨認所描述的情境，例如新手、有經驗的使用者、管理員，或供應商的宣稱。保留不確定性，不要從使用者名稱猜測身份。閱讀足夠的情境，以知道該問題是親身經歷還是傳聞。
6. 按觀點比較覆蓋範圍，以看出哪些決策條件出現、哪些缺失。計數顯示的是你觀察到的樣本，但不能告訴你一個問題在整個市場有多常見。空白結果可以表示查詢能見度低，而不是客戶沒有此需求。
7. 選擇一個小型而多樣的框，並記錄缺失的聲音。只有在另一個來源帶來新觀點時，才加入該來源。避免無止境地收集。
8. 交付來源選擇表、查詢上限清單，以及未回答觀點清單。下游的研究編碼與產品選擇是分開的工作。

## 虛構的逐步示例

所有社群名稱、貼文與客戶情境都是虛構的。想像一個研究問題：小型團隊如何選擇備份工作流程。用分開的執行，以及較小的上限、排序與時間參數，測試四個候選來源：

- BeginnerFiles：3 則已審閱貼文；其中 2 則顯示親身的設定困惑，1 則無關。來源角色是新手設定；納入此來源，以涵蓋上手問題。
- AdminPractice：3 則貼文；其中 2 則涵蓋復原與測試討論，1 則是供應商公告。來源角色是有經驗的營運；納入此來源，以涵蓋故障與復原條件。
- ToolQSupport：3 則貼文；其中 2 則描述特定工具錯誤，1 則正文缺失。來源角色是目前產品的故障排除；只在有限範圍內納入此來源，並保留 1 列未審閱。
- FounderChat：3 則貼文；其中 1 則顯示預算限制，2 則是推廣宣稱。來源角色是預算情境；把此來源保留為補充來源，而不是技術可靠性的主要來源。

這些收集共得到 12 則已收集貼文。其中包括 7 列親身且相關的情境（BeginnerFiles 2 列、AdminPractice 2 列、ToolQSupport 2 列，以及 FounderChat 1 列）、4 列已排除（1、1、0 與 2），以及 1 列未審閱。

7 則相關貼文並不等於 7 名不重複客戶，因為可能有重複的作者，或同一則貼文被轉貼到其他社群。這些小型的 3 列樣本，不能得出相對母體規模。

已完成的框把 BeginnerFiles、AdminPractice 與 ToolQSupport 選為主要的互補來源，並把 FounderChat 作為可選的預算情境。缺失的聲音包括不公開發文的團隊，以及已成功復原但沒有求助的擁有者。如果你更改 FounderChat 的查詢，請把它標為分開的補充樣本，而不要把其比率與原本固定查詢的比較合併。

| 社群 | 用途 | 納入原因 | 排除原因 | 查詢範圍 | 未知項 |
| --- | --- | --- | --- | --- | --- |
| BeginnerFiles | 新手設定 | 捕捉上手問題 | 無關貼文 | 固定查詢、上限 3、一年時間窗 | 真正的新手人數 |
| AdminPractice | 營運 | 涵蓋復原條件 | 供應商公告 | 固定查詢、上限 3、一年時間窗 | 故障頻率 |
| ToolQSupport | 故障排除 | 追蹤工具錯誤 | 無（正文缺失的貼文未審閱） | 固定查詢、上限 3、一年時間窗 | 未審閱的錯誤率 |
| FounderChat | 預算情境 | 查看成本限制 | 推廣宣稱 | 固定查詢、上限 3、一年時間窗 | 買家預算總額 |

## 下一步行動

在 [https://apify.com/chronometrica/reddit-search-scraper/examples/search-posts-in-subreddits](https://apify.com/chronometrica/reddit-search-scraper/examples/search-posts-in-subreddits) 開啟 Search Posts in Selected Subreddits，以你有理據的來源框取代通用社群，使用主要的 [https://apify.com/chronometrica/reddit-search-scraper](https://apify.com/chronometrica/reddit-search-scraper)，為每個來源使用一個小型且可比較的查詢，並把你的來源選擇原因與匯出一併保留。

## 來源與延伸閱讀

- [Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper)
- [關於客戶研究策略的討論](https://www.reddit.com/r/ProductMarketing/comments/1liklfb/best_tactics_for_customer_research/)
- [Reddit 上的客戶研究討論](https://www.reddit.com/r/SaaS/comments/1tb26ri/customer_research_on_reddit/)