流失召回实战：从七日预警到次留提升
一家社交产品发现流失用户持续增加。团队最初面对的并不是“该用XGBoost还是LightGBM”，而是三个更基础的问题：怎样才算流失，哪些人正在接近流失，以及产品究竟能改变什么。 最终，他们把项目拆成一条完整链路： 定义流失 → 建立预警模型 → 找到可干预线索 → 设计策略 → 随机实验 → 评估增量留存 这条链路的
流失用户挽回
10 篇已发布内容
换量召回：找回卸载用户与唤醒沉默用户
有些产品拥有相似的用户，却面对相反的流量困境：一方有大量近期卸载用户，缺少重新触达他们的入口；另一方拥有稳定流量，却没有足够预算采购新客。双方约定交换一定规模的曝光、点击或有效行为，这就是换量。 换量看起来像“不花钱买流量”，实际上并不免费。开屏、信息流、任务中心、弹窗和Push都占用稀缺的产品资源，也会带来用户打扰。
厂商Push召回：从离线送达到重新激活
当用户长期不再打开应用，自建Push通道常常率先失效：进程被系统清理、后台受限，消息即使发出，也未必能抵达通知栏。厂商Push依托手机系统中的常驻服务，在应用进程没有运行时仍有机会展示通知，因此成为Android端召回沉默用户的重要基础设施。 但这里有一个常见误区： 应用进程被杀，不等于应用已经卸载。 普通厂商Push
短信召回：从一条短链到完整回流链路
当用户已经卸载应用，Push、弹窗和站内信都失去了作用。短信不依赖安装状态，仍是少数能够触达流失用户的外部渠道之一。 但“短信送达”距离“用户回流”还很远。一条完整链路是： 合法人群圈选 → 短信送达 → 点击短链 → 打开App或落地页 → 未安装时承接下载 → 完成核心行为 → 持续留存 任何一环断裂，点击率再高也
预流失干预路径：在用户卸载之前解决真实问题
用户长按桌面图标、点击“卸载”，是离开产品前最明确的一次动作。于是很多团队希望抓住最后几秒：弹问卷、送权益、帮助释放空间，甚至直接阻止卸载。 但当用户已经决定删除应用时，挽回空间通常很小，普通应用对系统卸载流程的控制也十分有限。真正有效的卸载干预，不是与用户对抗，而是在系统允许的范围内提供一次解决问题的机会。 一、先理
找到流失特征并制定策略：从相关性到可干预性
流失模型告诉我们谁可能离开，流失特征则试图回答为什么。但模型中的“重要特征”并不天然等于流失原因，更不等于可以直接上线的策略。 从预测结果走到产品动作，需要完成三次筛选：先找出具有预测力的特征，再解释这些特征如何影响风险，最后只选择行为动线明确、能够被产品改变的部分进行干预。 一、先建立一张流失特征地图 特征通常可以分
怎么做流失预警：从时间窗口到模型上线
流失预警不是找出已经离开的人，而是利用用户过去一段时间的行为，预测他在未来一段时间内流失的概率。它真正要解决的问题是： 在用户尚可被干预时，把有限资源优先用在高风险、可挽回的人身上。 一、先把预测问题放到时间轴上 一个规范的流失预测至少包含三个时间窗口： 观察期 ：提取用户历史行为，例如过去30天的打开频率、核心功能使
召回效果评估：用RFM把回流率变成价值决策
一场召回活动带回了5%的用户，究竟算不算成功？答案取决于三件事：这些人是否因为干预才回来，回来的是不是有价值的用户，以及为此付出了多少成本。 因此，召回评估不能只盯着回流率。更完整的决策是：先用RFM识别值得投入的人群，再从增量回流、用户质量和成本三个维度比较策略，最后决定扩大、调整还是停止。 一、RFM解决的不是“谁
流失挽回：用户生命周期管理的最后一道防线
有一个广为流传的“扁鹊三兄弟”故事：医术最高明的长兄在疾病尚未显现时就将其消除，仲兄在病情轻微时治疗，扁鹊则在病情严重后下猛药，因此反而最有名。 不论故事的史实来源如何，它都揭示了用户流失管理的基本规律： 越早发现问题，干预成本越低；等用户彻底离开后再召回，往往已经进入代价最高、效果最不确定的阶段。 一、流失挽回处在生
如何定义流失用户：分位数法与拐点法
用户多久没来，才算真正流失？ 一天没有打开，可能只是忘了；一个月没有打开，也可能是产品本来就低频。流失不是一个天然存在的标签，而是业务根据用户行为规律划出的一条边界。边界定得太短，会把正常间歇误判为流失；定得太长，又会错过最佳干预时机。 一、先区分“卸载”和“不再活跃” 流失用户通常包含两类。 第一类是 明确卸载 。移