# 如何研究竞品调价前后的公开反应

要对比竞品调价前后的反馈，首先应通过带日期的官方来源核实这次变更。以生效日期为界，设置长度相同的观察时间窗口。在相同的公开社区中，使用相同的关键词搜索。只对比明确讨论此次事件的帖子。在报告中保留其他可能的解释和缺失信息。公开反应无法衡量客户流失，也就是客户停止使用某个产品的情况。它们也不能证明某项业务结果由这次调价造成。

先查看竞品的官方公告和你已保存的证据。确认事件后，再通过 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-Hans/articles/%E7%A0%94%E7%A9%B6reddit%E7%94%A8%E6%88%B7%E6%9B%B4%E6%8D%A2%E4%BA%A7%E5%93%81%E7%9A%84%E5%8E%9F%E5%9B%A0/)的指南讨论了这个问题。仅凭对价格的反应，无法确定是否发生了产品转换，也无法确定转换原因。

## 6. 处理重复记录和收集失败

将同一 `postId` 的多次观察记录关联起来。不要因为另一条查询也找到了同一帖子，就再次计数。保留其收集历史，以便说明它的来源。

不同帖子 ID 的帖子可能引用了同一段抱怨。保留这些来源，但要标注共有的引文。重复的文字不能证明存在多位客户各自的经历。也不要仅因用语相似就合并不同帖子。

对比之前，检查以下问题：

| 情况 | 所需处理 |
| --- | --- |
| 官方事件日期尚未确定 | 不要对时间前后作出确定性比较 |
| 发布日期缺失或不确定 | 不要将该帖子纳入按时间划分的组 |
| 事件相关性尚未确定 | 将帖子保留为待定，不计入相关帖子数量 |
| 无法获取文本 | 说明无法为其反应编码 |
| 收集失败或未返回可用记录 | 报告收集问题或空结果 |
| 结果数量上限可能限制覆盖范围 | 说明这只是有限收集，并非全部讨论 |
| 搜索范围发生变化 | 统一搜索范围，或披露范围差异 |

没有返回帖子，不代表公开反应为零。同样，没有观察到取消订阅的陈述，也不代表取消订阅的数量为零。证据缺失与观察值为零，回答的是不同的问题。

## 7. 对比所选帖子，检验其他解释

分别统计每个时间窗口内纳入的帖子。每次都应说明计数单位。六条帖子就是六条帖子，不代表六个人，也不代表六位受影响的客户。

报告任何占比时，都要说明分母，也就是作为总数的那组对象。统计某个主题时，只能使用符合该项对比条件的帖子。时间不确定、涉及无关事件或文本不可用的记录，不应计入相应总数，但仍须保留并明确列出。

你可以对比每个时段出现的主题和条件。将数量与支持它的段落放在一起。如果某个时段收集到的帖子更多，不要将数量上的直接差异当作客户情绪或讨论量的变化。

检查解读是否过度依赖某一次讨论。关于[检查单个 Reddit 讨论串是否主导结果](/zh-Hans/articles/%E6%A3%80%E6%9F%A5%E5%8D%95%E4%B8%AAreddit%E5%B8%96%E6%98%AF%E5%90%A6%E4%B8%BB%E5%AF%BC%E7%A0%94%E7%A9%B6%E7%BB%93%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)