Conversation Tracking Guide
如何追踪围绕产品的 Twitter 讨论，而不是被信息流带着跑
Twitter 上围绕产品的讨论，可能来自 mentions、功能对比、发布线程、客户回复，也可能来自更外围的话题讨论。一条好的流程，不只是让团队知道产品被提到了，而是帮助团队理解大家到底在谈什么，以及这些讨论如何变化。
1. 先定义你到底要追哪类产品讨论
“追踪大家在聊我们的产品”通常太宽。更好的起点，是限定为发布讨论、onboarding 抱怨、类目对比，或者某个 power-user workflow。
这种限定能让检索保持足够聚焦，也更容易保留讨论的形状。
- 先选一个讨论主题或产品问题。
- 同时覆盖问题语言、类目语言和产品别名。
- 先想清楚最终是为了支持客服、产品、增长还是研究。
2. 不只保存帖子，还要保存围绕它的讨论
很多产品讨论并不是在主帖本身完成的，而是展开在回复、引用和后续跟进里。只看一条孤立帖子，常常会错过最有价值的上下文。
所以讨论追踪通常需要“发现”加“深入检查”两层。
- 把回复、引用和重要后续讨论一起保留下来。
- 确认参与讨论的账号类型。
- 优先保存能体现异议、use case 或需求的讨论片段。
3. 把讨论归成重复主题
当同样的问题、反应或比较在不同线程里反复出现时，团队就可以开始把它们当成模式，而不是单独事件。
这会让输出更适合研究、支持和内容规划。
- 用 feature request、对比、好评、困惑和 workflow story 这类主题分桶。
- 观察哪些主题在增长，哪些在减弱。
- 每个主题保留代表性例子。
4. 把讨论整理成稳定的内部摘要
当讨论追踪能变成周报、发布复盘或研究 note 时，它就开始变得有操作性。关键在于团队能否长期用同一结构回看。
这样才能在时间上真正比较变化，而不是每次重新浏览。
- 用固定 brief 结构代替一次性 notes。
- 把原始例子和解释分开。
- 重点标出与上次相比有什么变化。
团队在追踪产品讨论时最常问的问题
当团队想更清楚地理解产品在公开场域里如何被讨论时，这些问题通常都会出现。
为什么只看直接 mentions 不够？
因为很多相关讨论会通过对比、use case、回复上下文来展开，并不总是重复产品全名。
回复和 quote post 也要纳入流程吗？
要。它们经常才是真正的讨论主体，里面会出现反对点、认可和追问。
什么样的讨论报告才对团队有用？
有清楚主题边界、按主题归类、有代表性示例，并且能和上一次复盘做比较的报告。
怎么测试这条流程？
选一个产品主题追踪一段时间，再看这份讨论摘要是否比原始搜索和截图更容易被团队复用。
和产品讨论追踪经常一起看的页面
如果围绕产品的讨论本质上是一个长期 topic tracking 问题，从这里继续。
如果讨论是从直接品牌提及出发的，从这里继续。
如果这条讨论流程起点是品牌 mentions 和回复，从这里继续。
如果范围已经扩展到围绕产品的更大市场讨论，从这里继续。
用团队能持续比较的方式追踪产品讨论
如果 Twitter 上围绕产品的讨论已经影响你的判断，下一步通常就是把这些信号变成固定追踪和总结流程。