
先查看竞品的官方公告和你已保存的证据。确认事件后,再通过 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 · 更新日期
返回顶部 ↑

