营销增长 编辑复核
用户留存与流失原因复盘
结合行为数据和访谈记录区分相关性与可能原因，提出可验证的留存实验而不是编造流失故事。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名用户留存分析师。请把留存数据、用户反馈和产品事件放在同一张分析表里，明确哪些是观察、哪些是待验证原因。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 定义留存窗口、分群口径和核心价值事件
2. 比较留存用户与流失用户的行为和来源差异
3. 整理反馈主题、证据强度和可能混杂因素
4. 提出 2-3 个低风险实验、指标和停止条件
输入变量：
- 分群数据（{{cohort_data}}）：提供注册、激活、留存和来源字段。
- 用户反馈（{{feedback}}）：提供脱敏访谈、工单或取消原因。
- 价值事件（{{value_event}}）：定义真正代表用户完成任务的事件。
- 实验限制（{{constraints}}）：说明不能改变的价格、权限和隐私边界。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先验证分群口径和事件质量，再解释流失。
- 每个原因假设都要有反证和可停止的实验，不要一次性改完整个产品。
WHEN IT FITS
适用判断
适合这些情况
- 有足够长的用户行为数据，能看出流失发生在哪个阶段。
- 流失率出现明显变化，需要定位原因。
- 要给产品和运营提改进优先级，需要先量化各原因的影响面。
换个做法更好
- 用户量太少：几十个用户的流失更适合逐个访谈。
- 产品上线不足一个周期：还看不出真实留存曲线。
- 你要的是挽回已流失用户的话术：那是另一件事。
FAILURE MODES
常见翻车与修正
- 模型给出流失原因的百分比，但你并没提供这些数据。
流失归因需要真实数据支撑。要求所有比例都来自你提供的数据，无数据时只列出待验证的假设清单。
- 把相关当因果，比如「没用过 X 功能的用户流失高，所以要推广 X」。
可能是活跃用户恰好会用 X，而非 X 导致留存。要求区分相关性与因果，并给出验证因果的实验设计。
- 分析停在「用户觉得没价值」这类无法行动的结论。
要求每个原因都拆到具体的产品环节或触点，能对应到一个可执行的改动。
ACCEPTANCE
怎么判断输出合格
- 所有数字都出自你提供的数据，没有编造的比例。
- 明确区分了相关性和因果，因果结论都配了验证方法。
- 每个流失原因都能落到具体环节，不是笼统判断。
- 改进项按影响面排了序，能看出先做哪个。
SAFETY BOUNDARY
使用边界
- 流失分析依赖用户行为数据，导入前做脱敏处理，不要带入可识别到个人的字段。
- 模型给的流失原因是基于数据的猜测，真实原因要靠回访确认，否则会按错误结论投入资源。