# 如何为客户研究选择 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。

正文语境缺失的帖子保持未审阅状态。较低的来源排名表示搜索顺序，而不是帖子质量。帖子 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-Hans/articles/%E5%B0%91%E5%99%AA%E5%A3%B0%E7%9A%84reddit%E5%85%B3%E9%94%AE%E8%AF%8D%E8%BF%BD%E8%B8%AA/)。使上限、排序、时间窗口和观察时间保持可比较。保存所请求的 subreddit 和匹配到的 subreddit，以便审阅任何超出范围的结果。
5. 检查返回的帖子，识别所描述的情境，例如新手、有经验的用户、管理员，或供应商提出的声称。保留不确定性，不要根据用户名猜测身份。阅读足够的语境，以判断问题是亲身经历还是传闻。
6. 按视角比较覆盖情况，看哪些决策条件出现了、哪些缺失。计数显示的是你观察到的样本，但不能告诉你某个问题在整个市场中有多常见。空结果可能意味着查询可见度低，而不是客户没有这种需求。
7. 选择一个小而多样的来源框，并记录缺失的声音。只有当另一个来源带来新视角时才加入它。避免无止境的采集。
8. 交付来源选择表、查询上限清单，以及未获回答的视角列表。下游的编码分类和产品选择是另行进行的工作。

## 虚构的演算示例

所有社区名称、帖子和客户情境均为虚构。设想一个研究问题：小型团队如何选择备份工作流程。使用分开的运行，并以较小的上限、排序和时间参数测试四个候选来源：

- BeginnerFiles：审阅了三篇帖子；两篇显示亲身经历的设置困惑，一篇无关。来源角色是新手设置；纳入此来源以覆盖上手问题。
- AdminPractice：三篇帖子；两篇涉及恢复和测试讨论，一篇是供应商公告。来源角色是有经验的运维；纳入此来源以覆盖故障和恢复条件。
- ToolQSupport：三篇帖子；两篇描述具体工具错误，一篇正文缺失。来源角色是当前产品的故障排查；窄范围纳入此来源，并保留一行未审阅记录。
- FounderChat：三篇帖子；一篇显示预算约束，两篇是推广性声称。来源角色是预算语境；将其作为补充来源保留，而不是技术可靠性的主要来源。

这些采集共得到十二篇已采集帖子。其中包括七行亲身经历且相关的情境记录（BeginnerFiles 两行、AdminPractice 两行、ToolQSupport 两行、FounderChat 一行）、四行被排除的记录（一、一、零、二），以及一行未审阅记录。

七篇相关帖子并不等于七位各自只计一次的不同客户，因为可能存在重复作者或交叉发布。不能从这些每处仅三行的小样本推出相对总体规模。

已完成的来源框选择 BeginnerFiles、AdminPractice 和 ToolQSupport 作为主要的互补来源，并将 FounderChat 作为可选的预算语境。缺失的声音包括不公开发帖的团队，以及在未求助的情况下已成功恢复的所有者。如果你更改 FounderChat 的查询，请将其标为单独的补充样本，而不是把它的比率与原先固定查询的比较合并。

| 社区 | 用途 | 纳入理由 | 排除理由 | 查询范围 | 未知项 |
| --- | --- | --- | --- | --- | --- |
| BeginnerFiles | 新手设置 | 捕捉上手问题 | 无关帖子 | 固定查询，上限 3，一年时间窗口 | 真实新手数量 |
| AdminPractice | 运维 | 覆盖恢复条件 | 供应商公告 | 固定查询，上限 3，一年时间窗口 | 故障频率 |
| ToolQSupport | 故障排查 | 跟踪工具错误 | 无（正文缺失的帖子未审阅） | 固定查询，上限 3，一年时间窗口 | 未审阅错误率 |
| FounderChat | 预算语境 | 查看成本约束 | 推广性声称 | 固定查询，上限 3，一年时间窗口 | 购买者预算总额 |

## 下一步行动

打开“在选定 Subreddit 中搜索帖子”，地址为 [https://apify.com/chronometrica/reddit-search-scraper/examples/search-posts-in-subreddits](https://apify.com/chronometrica/reddit-search-scraper/examples/search-posts-in-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/)