用户多久没来，才算真正流失？
一天没有打开，可能只是忘了；一个月没有打开，也可能是产品本来就低频。流失不是一个天然存在的标签，而是业务根据用户行为规律划出的一条边界。边界定得太短，会把正常间歇误判为流失；定得太长，又会错过最佳干预时机。
一、先区分“卸载”和“不再活跃”
流失用户通常包含两类。
第一类是明确卸载。移动应用一般无法可靠地监听自己被卸载，实践中常通过厂商推送令牌失效、应用商店统计、合作渠道回传等信号间接判断。但这些信号可能延迟，也可能把换机、清除数据或权限变化误认为卸载，因此更适合作为辅助证据，而不是唯一口径。
第二类是长期不活跃。产品能准确记录用户最后一次活跃，却不知道他是卸载了，还是暂时没有需求。因此，业务通常把“距上次活跃已经超过某个天数”定义为行为型流失，这个天数就是流失周期。
计算流失周期前，需要先得到用户的回流间隔：
其中，t_i和t_{i+1}是同一用户相邻两次活跃的日期。例如某位用户在6月2日、6月9日和6月12日活跃，对应的回流间隔是7天和3天。汇总大量用户的间隔，才能看见产品真实的使用节奏。
需要注意，回流间隔不同于留存率。第n日留存率描述的是某批基准用户在第n日返回的比例：
前者研究“用户通常隔多久再来”，后者研究“某批用户在指定日期还剩多少”。
二、分位数法：覆盖绝大多数正常回流
分位数法的核心问题是：正常会回来的用户中，有多少会在n天内回来？
具体做法是统计相邻两次活跃的间隔，按天数从小到大排列，计算累计分布：
若选择90%分位数，则流失周期为：
例如第16天累计回流占比为89.73%，第17天达到90.5%，就可以暂定17天为流失周期。它的业务含义是：历史上约九成可观察到的正常回流间隔不超过17天，超过这条线后，用户继续自然回来的可能性已经比较低。
这种方法直观、稳定，也便于向业务解释，适合建立统一的用户标签与报表口径。但90%并不是行业定律。提高分位数会减少误判，却让识别更晚；降低分位数可以更早干预，却会触达更多本来就会自然回来的用户。最终阈值应结合触达成本、打扰风险和挽回价值确定。
三、拐点法：寻找回流概率明显衰减的位置
拐点法关注的不是累计覆盖率，而是：等待时间增加到哪一天后，继续等待带来的新增回流已经明显减少？
可以选取一批曾经活跃的用户，观察他们在连续未活跃n天之后再次回来的概率。例如定义：
将R(n)随沉默天数的变化画成曲线。早期曲线下降很快，说明多等一天，用户的自然回流概率就会明显降低；到某个位置后曲线趋于平缓，新增等待时间不再带来显著信息，这个位置可以作为候选流失周期。例如曲线在第7天附近由陡转缓，便可把7天作为预警或流失边界。
实际分析不宜只凭肉眼找点。可以使用分段回归、变化率差分或肘部检测算法识别拐点，并通过多期数据验证其稳定性。若曲线没有清晰拐点，就不应勉强使用这种方法。
与分位数法相比，拐点法更贴近“何时开始变得危险”，适合确定干预窗口；分位数法更适合回答“多久可以把用户正式归为流失”。两者得到不同天数并不矛盾：例如第7天进入高风险期，第17天才认定正式流失，团队可以在7—17天之间开展渐进式干预。
四、不要为所有用户设同一条线
统一周期方便管理，却可能掩盖差异。工作日使用的办公产品、周末集中的电影票业务、按月缴费的生活服务，其回流节奏天然不同；新用户、付费用户与轻度用户也不应共用一条阈值。
更稳妥的做法是按用户阶段、活跃频率、核心场景和价值分层，分别估计流失周期。数据计算时还要统一活跃事件口径，排除机器人、误触和后台唤醒，并处理观察窗口末端尚未回流的用户；否则只统计“已经回来的人”，会低估长周期回流。
流失定义最终要服务于行动。一个可用的阈值，应同时满足三点：能够较早识别风险、不会制造过多误报，并且用它圈出的人群确实可以被干预。上线后应通过对照实验比较自然回流率、增量召回率、触达成本和长期留存，定期重估阈值。
因此，流失周期不是一次计算后永久不变的常数。分位数法给出一条可解释的统计边界，拐点法找到行为变化最明显的时刻，而真正有效的流失定义，是统计规律、业务成本和干预能力共同决定的结果。