用户流失预测这个题目这几年在通信行业的数据圈子里几乎成了标配项目。原因很简单存量用户经营已经成为运营商的核心命题拉新成本持续走高而老用户一旦流失重新获取的成本往往是维护成本的5到8倍。与其事后花大力气把用户“请回来”不如在用户还没走之前就识别出风险提前干预。电信用户流失分析与预测做的就是这个“事前干预”的活。这篇内容我会按一个完整项目的落地流程来聊从业务口径的定义、数据处理与特征工程到模型训练、样本不均衡处理再到最后的运营策略落地把整个链条里最关键的环节和最容易踩的坑都过一遍。适合刚接触用户流失建模的数据分析师、机器学习工程师以及想了解流失模型怎么落到业务运营里的产品运营同学参考。1. 业务理解流失分析到底在解决什么问题1.1 什么是用户流失业务口径如何定义很多人拿到数据就开始跑模型但首先得把“流失”这个词定义清楚。在电信业务里流失并不只是“用户销户”这么简单。不同业务视角下的流失定义差异很大这会直接影响样本的标注方式和模型的预测目标。常见的流失口径有三种硬流失用户主动销户、转网到其他运营商或者欠费停机超过一定天数后被强制销户。这类流失是最直接的数据标签也最明确。软流失用户还在网但使用行为明显下降。比如原来每个月通话500分钟最近三个月降到50分钟原来每月流量消耗10GB现在只有几百MB。这类用户往往是“沉默用户”离真正流失只差一步。沉默离网用户在网但不活跃既不消费也不使用服务实际上已经“形同虚设”。大多数建模项目会把“硬流失”作为核心标签因为数据干净、业务目标明确。如果资源允许也可以把“软流失”里那些高风险用户纳入标签但需要业务方定义清楚“沉默多久算风险”。我建议项目初期先把硬流失做扎实再考虑扩展口径否则标签定义不统一后面整个模型都会跟着乱。1.2 为什么用数据建模而不是用规则在模型出现之前运营商也不是完全没有流失预警手段很多团队用的是一套经验规则比如“月费超过200元且连续两个月通话时长下降30%以上的用户判定为高危流失”。规则简单直接但问题也很明显规则覆盖的维度有限。人工经验一般只能想到费用、通话时长、流量这些显性指标但流失其实是多维因素叠加的结果比如合同即将到期、竞争对手促销、客服投诉次数上升、支付方式变化这些信号靠人工规则很难全部覆盖。规则是静态的。“连续两个月下降30%”这个阈值不同用户群体其实不一样。高价值集团客户和低端大众市场的用户行为模式完全不同用同一套规则去卡所有用户自然会漏掉很多风险。规则无法输出概率。做运营动作时需要的是一个0到1之间的流失风险分用来排序、分层、决定投入多少挽留资源。规则只能给出“是/否”颗粒度太粗。而机器学习模型天然适合这类问题输入大量用户行为特征输出一个流失概率把所有微弱信号综合起来做判断。模型的效果不一定每次都比精心调教的规则强很多但它更稳定、更容易迭代也更容易随着数据的更新自动适应变化。2. 数据准备与特征工程2.1 原始数据长什么样建模的第一步是理解数据。以某运营商一个常规的流失分析场景为例数据集通常包含以下几类信息字段分类典型字段说明用户基本信息性别、年龄、是否老年人、是否已婚、是否有家属反映用户自然属性服务订阅信息电话服务、多条线路、网络服务、网络电视、网络电影用户开通了哪些产品附加服务信息在线安全、设备保护、技术支持是否订购增值服务合同与账单信息合同类型月付/一年/两年、纸质账单是否使用、支付方式、月费、总费用反映用户合约状态与消费水平在网时长已入网月数反映用户生命周期阶段目标变量是否流失用户是否在观察期内流失这类数据的特征是“表格型数据”每条记录是一个用户每一列是一个特征目标变量是二分类标签。表格型数据的建模首选就是逻辑回归和树模型不涉及复杂的文本或图像处理入门门槛不算高。2.2 特征工程从“会用字段”到“构造字段”原始字段虽然能用但如果只把原始字段直接塞给模型效果会比较平庸。流失预测项目里特征工程的核心在于把“静态的用户画像”和“动态的行为变化”结合起来。我常用的特征构造思路有这么几个业务量聚合特征把用户订购的服务种类做一个汇总比如“服务订阅总数”这是一个很有用的特征。订阅服务越多的用户对运营商的依赖度越高流失概率通常越低。费用衍生特征月费本身是静态的但可以构造“总费用除以在网时长”得到月均费用消除在网时长不同带来的费用累积偏差。再比如“当前套餐费用与历史平均费用的差异”能捕捉用户降档的信号。交互特征有些特征单独看并不强但组合起来信息量很大。比如“合同类型 在网时长”长期合同即将到期的用户流失风险会明显上升再比如“服务数 客户年龄”年轻用户对增值服务不敏感服务数量多对流失的抑制作用就没有中年用户那么明显。行为趋势特征如果有历史行为数据可以构造“最近三个月通话时长环比变化率”“流量使用近半年斜率”这类趋势特征它们往往比绝对值特征更有预测力。需要说明的是特征并不是越多越好。实际项目里我倾向于先构造一批有业务解释性的特征让模型去筛选而不是一次性生成几百个无意义的数值组合那样只会增加过拟合风险和调试成本。2.3 数据清洗与目标变量处理原始数据基本不可能直接用常见的问题有这么几类缺失值性别、年龄这类字段可能会有少量缺失。对于类别特征可以单独分成一个“缺失”类别对于数值特征可以用中位数填充。重点不在于用什么方法而在于缺失本身就可能是信息。比如支付信息缺失的用户往往是账户状态异常的用户。异常值有些用户总费用为负数或者月费高得离谱这类记录需要排查是数据问题还是真实情况。我的习惯是把分布明显不合理的样本过滤掉避免干扰模型训练。目标变量泄漏这是最严重的问题。建模时只能用“观察期”之前的数据做特征用“观察期”之后的流失状态做标签。如果比如用“用户是否已经销户”这种事后信息去预测流失模型在训练集上会表现极好但上线后完全没有预测能力。目标变量处理还有一个常见细节就是标签的时间对齐。假设我以2024年1月到3月为观察期那么特征只能使用截至2024年1月1日的数据标签则标记用户在2024年1月到3月期间是否流失。不能混着用。3. 探索性分析流失用户和留存用户差在哪里3.1 用分布和可视化找差异建模之前先花时间做探索性数据分析EDA非常值得。它可以帮你建立对数据的直觉也能发现一些建模时可以利用的关键差异。拿合同类型来说这是电信流失预测中几乎最重要的一个特征。月付合同的用户流失率显著高于签订了一年或两年合同的用户。原因不难理解月付用户没有合约约束随时可以转网成本极低而长期合同用户即使想走也得先考虑违约金的损失。这个特征在后续模型中一定会被反复用上。支付方式也很有意思。使用自动银行转账的用户流失率明显低于使用纸质账单支付的用户。自动扣款意味着用户对服务有稳定的使用预期同时也降低了因“忘记缴费”而被动停机离网的概率。这类用户本身就更“稳”。再看在网时长。用户在网时间越长流失率越低这是典型的生命周期规律。新入网用户在头三个月内是流失高危期因为还没形成使用习惯对服务质量的感知也不稳定一旦过了这个阶段流失风险会逐渐下降。3.2 关键特征与流失的关系做得再细一些可以把特征和流失的关系量化出来。比如把连续型特征分箱计算每个箱体内的流失率看是否存在单调或U型关系月费与流失率并不是月费越高流失率一定越高。很多时候高月费用户反而流失率偏低因为这类用户通常是全家用户绑定了电话、网络、网络电视多个产品迁移成本很高。流失率最高的往往是中等偏上费用的用户他们有一定消费能力但签的可能是月付合同转网意愿更强。服务订阅数量与流失率这个关系相对清晰订阅服务数越少流失风险越高。只开了一个电话服务的用户说走就走开了电话加网络加电视的用户要考虑的迁移成本就大多了。客服投诉次数如果数据里有投诉工单信息投诉次数是一个强信号。但要注意并不是有投诉就一定会流失反而是一次投诉被妥善解决后的用户忠诚度可能更高。这里需要关注的是持续投诉、且未得到解决的用户。EDA还有一个实际作用就是为后面的特征筛选提供方向。如果你发现“性别”在流失率上没有显著差异那这个特征大概率在模型里也不会起太大作用可以先放一放。把精力集中在合同类型、费用、服务订阅数、在网时长这些高信息密度的特征上。4. 模型训练从基线模型到集成模型4.1 划分数据集与评估指标选择建模最怕的是“用后视镜开车”。很多新手一上来就把所有数据丢进去训练然后在同一批数据上评估效果得到一个虚高的指标上线之后彻底翻车。正确的做法是把数据集按时间顺序划分用前段数据训练后段数据验证模拟真实场景下“用历史预测未来”的状态。如果数据没有时间维度再考虑随机划分但要保证训练集和测试集的用户没有重叠。评估指标的选择也要结合业务背景。电信用户流失是一个典型的类别不平衡问题流失用户通常只占总体的20%到30%左右这时只用准确率是没意义的——就算把所有人都预测为“不流失”准确率也有70%以上但这个模型对业务完全没有价值。我通常同时看几个指标AUC衡量模型区分正负样本的能力对不平衡问题相对稳健适合作为模型调优的主要指标。召回率在流失预测里召回率意味着“真正会流失的用户里模型抓到了多少”。业务侧会非常关注这个指标因为漏掉一个高风险用户就少了一次挽留机会。精确率预测会流失的用户里有多少真的流失了。精确率太低意味着大量挽留动作落在不会流失的用户身上造成资源浪费。PR曲线在不平衡场景下比ROC曲线更能反映模型的真实表现尤其是当业务只关心“流失”这一类时。4.2 基线模型逻辑回归项目实践中我习惯先跑一个逻辑回归原因很实际它是一个校准良好的概率模型训练快结果可直接解释还能作为后续复杂模型的对照基准。如果逻辑回归已经能达到不错的AUC那说明特征工程已经成型了后面换树模型应该能进一步提升但提升幅度有限。逻辑回归建模时要注意几点一是对数值特征做标准化让系数之间有可比性二是关注多重共线性比如总费用和在网时长高度相关同时放进模型可能导致系数不稳定三是对类别特征做编码时要防止基数过高导致维度爆炸。逻辑回归的另一个优势是直接输出概率。比如模型输出某用户流失概率是0.86业务侧可以直接理解这个分数的含义不需要黑盒解释。4.3 提升模型基于树模型的集成基线跑通后接下来替换成树模型。当前表格数据建模场景下XGBoost和LightGBM是两种主流选择。两者都是梯度提升框架区别主要在实现细节和训练效率XGBoost对小数据集更稳LightGBM在大数据集上训练更快。实际项目中如果没有特殊约束我用LightGBM更多一些因为它省时间、显存占用低参数调起来也相对顺手。树模型能自动捕捉非线性关系和特征交互效果通常会比线性模型好一截。但代价是可解释性下降。解决办法是配合树模型的特征重要性分析以及用SHAP做局部解释这个在后面的落地章节会细说。训练时要注意过拟合。树模型在表格数据上很容易“背下来”训练集的噪声。常规做法是设置合适的学习率典型值0.01到0.1控制树的深度一般4到8就够过深容易过拟合使用早停在验证集指标不再改善时停止训练开启正则化参数抑制模型复杂度。我见过不少项目训练AUC做到0.95以上测试AUC只有0.75这就是典型的过拟合。流失预测的样本量通常几万到几十万不复杂不需要把树模型的容量拉满。5. 样本不平衡与阈值优化5.1 不平衡问题的处理方式流失用户占比偏低这是几乎所有流失预测项目都会遇到的问题。处理不平衡之前先想清楚一个问题模型是真的需要“平衡”还是只是评估指标选错了很多情况下AUC已经能比较稳定地反映模型能力这时强行做重采样反而不一定能提升实际效果。但如果用阈值敏感的业务指标比如精确率、召回率来评估不平衡问题就需要处理。常见做法有这几种类别权重调整在损失函数里给少数类更高的权重。LightGBM和XGBoost都有scale_pos_weight参数可以直接调整简单有效。下采样随机剔除多数类样本让正负样本达到1:1或1:2。缺点是丢掉了很多信息但对模型训练速度有帮助。上采样/合成样本比如SMOTE在特征空间内插值生成新的少数类样本。这个方法在小数据集上可能有效但在海量用户数据上往往没必要反而可能引入噪声。我的经验是先用类别权重效果不够再考虑采样策略。不要一上来就SMOTE因为这类方法在表格数据上的收益很不稳定还容易造成过拟合。5.2 用价格矩阵确定最优阈值模型输出的是流失概率但业务上最终要做一个二分类判断这个用户要不要进入挽留名单。这个判断需要一个阈值。很多项目直接把阈值设成0.5这在流失场景下通常不是最优的。更好的做法是引入“代价矩阵”来算阈值。假设一个高价值用户流失造成的损失是挽留成本的10倍给用户做一次挽留比如赠送流量、减免月费的成本是50元用户流失带来的月收入损失是200元平均生命周期剩余12个月那么流失损失约2400元。那么只要预测的流失概率 P 满足P × 流失损失 挽留成本就值得把这个用户放进挽留名单。即P 挽留成本 / 流失损失。代入上面的数字P 50 / 2400 ≈ 0.02。也就是说在这个业务假设下阈值只需要大约0.02甚至更低远低于默认的0.5。这正是逻辑回归和树模型输出概率的价值所在——你可以根据业务成本灵活调整阈值而不是被模型固定输出绑死。实际操作里我会先画出精确率-召回率曲线然后结合代价矩阵选择曲线上最优点。这里的核心思路是把模型评估和业务决策连接起来而不是只看技术指标。6. 结论落地从预测到挽留动作6.1 流失概率分群的运营策略模型建得再好如果只输出一个名单没有后续运营动作项目价值就打折了。流失预测项目的最终交付物应该是一套分层运营策略。我会把模型输出的流失概率和用户价值两个维度结合做一个四象限分群用户分组特征运营策略高价值-高风险消费能力强流失概率高优先挽留人工客服外呼提供专属优惠或服务升级低价值-高风险消费贡献低流失概率高不做高成本挽留可推送自动优惠券顺其自然高价值-低风险消费能力强忠诚度高保持服务体验适时推荐升级套餐做好维系低价值-低风险消费贡献低忠诚度高维持现状不投入额外资源这个分群的价值在于它避免了“一刀切”式的挽留。低价值用户流失对业务影响有限花人力去逐一挽留反而亏本高价值用户的流失则是真金白银的损失值得用最充分的资源去干预。针对高价值高风险用户挽留手段也不一定非要送钱。常见做法包括合约到期前推荐新合约计划并附带优惠、为客户提供专属客服通道、检测到服务故障时主动关怀。本质上是通过“让用户觉得被重视”来降低转网意愿。6.2 模型可解释性的价值工业场景里模型可解释性不是“锦上添花”而是刚需。客服外呼时要说得出口运营策划时要决定给什么优惠管理层要理解模型判断的依据这些都需要可解释性。树模型的特征重要性只能告诉你“哪些特征重要”但不能告诉你“某个用户为什么被判为高风险”。一份好的流失预测报告里应该包含对典型高风险用户画像的描述比如“在网时间短、月付合同、订阅服务少、投诉次数多”这样运营侧才能有针对性地制定策略。具体工具上SHAP是目前用得最广泛的解释方法。它能算出每个特征对某个用户流失概率的贡献方向与大小。比如某个用户合同类型是月付这一项让他的流失概率提升了0.12在网时长3个月又让概率提升了0.08订阅了5个服务让概率下降了0.15。这些数值可以直接作为运营人员决策的参考依据。7. 实操中踩过的坑与避坑清单7.1 特征泄漏问题特征泄漏是流失预测项目里最容易犯、后果也最严重的错误。举一个真实的例子某次建模过程中业务方把“是否已提交销户申请”当成一个特征放进了模型结果AUC高达0.99当时大家都很兴奋。稍微一查就发现问题了用户提交销户申请之后基本都会流失这个特征实际上已经是“结果”而不是“原因”。用这样的特征做预测等于预测未来之前先告诉你未来。模型上线后真实预测时根本拿不到这个字段的实时值效果断崖式下跌。避免特征泄漏的关键方法是做特征审查逐个字段问一句“这个字段在预测时点之前就能获取吗”如果是之后才能获取的信息哪怕预测力再强也不能用。7.2 训练测试集划分的时间一致性另一个容易被忽略的问题是时间窗口错位。有的项目用2023年的数据训练用2024年的数据测试这里面有两个隐患一是用户的消费行为和流失模式会随季节和竞争环境变化两段数据分布不同二是标签口径在两个时间段可能发生了变化比如业务侧调整了“流失”的定义这会让模型的评估结果失真。我的建议是训练集和测试集最好来自相邻的时间窗口比如用1月到3月作为训练期4月到5月作为验证期6月作为测试期。这样既接近真实场景又不会因时间跨度过大导致概念漂移。7.3 特征分布漂移与监控模型上线只是开始不是结束。用户行为会随着时间变化套餐政策会调整市场竞争会变化这些都会让之前训练好的模型逐渐失效。比较典型的现象是“半年后模型精度下降”但业务侧可能感知不到。如果条件允许上线前就规划一个监控体系定期检查模型预测分布的稳定性、特征分布的漂移程度、以及核心业务指标比如用户流失率的变化。设置预警提醒一旦模型效果明显退化就要考虑重新训练或调整特征。纯做一次性的预测分析、交付一份报告就结束很多时候流失模型的效果只能维持几个月。7.4 关于“完美模型”的预期管理最后一点是关于预期。流失建模不是算法竞赛它的天花板由数据质量和业务干预能力共同决定。如果数据里没有客服交互记录、没有竞争对手活动信息、没有套餐变更日志模型的提升空间就有限。如果运营侧没有成体系的挽留动作和资源再精准的预测也难以转化为业务价值。我在实际项目中的体会是流失预测模型的效果提升通常是阶梯式的特征工程做到位AUC能到0.85左右用上树模型和阈值优化能到0.90左右再往上就需要更细粒度的时间序列行为数据或者引入外部数据源。而业务侧真正关心的从来不是AUC 0.88还是0.90而是挽留成功率提升了多少、无效营销减少了多少。所以在做这个项目时我建议不要只盯着模型指标多花时间和运营同事聊流失用户被识别出来之后到底有多少种挽留手段资源够不够流程顺不顺把分析、预测和运营动作串成一个闭环这个项目才算真正做完。