通信行业做了几年的数据项目用户流失大概是所有分析课题里最常被问起、也最难真正落地的一个。大部分团队不缺数据也不缺建模流程真正缺的是对业务口径的较真、对特征背后含义的理解以及从预测结果到运营动作之间那段路的走法。这篇文章就把电信用户流失分析与预测这件事完整的拆开讲一遍从最开始的流失定义、数据清洗、特征构建到后面的建模选择、模型解释和落地评估都会按实际操作顺序走下来。无论你手里是真实运营商的脱敏数据集还是只想完整跑通一个分析项目的学生这篇都能给你一套可以直接抄作业、也可以按自己场景改的完整流程。1. 流失分析的第一步其实是把流失这件事定义清楚很多人拿到数据集第一件事就是跑模型这是个大坑。流失分析里谁算流失用户比用什么模型重要得多因为定义直接决定标签质量标签质量又直接决定模型上限。1.1 业务视角下的流失定义不止是离网这一种口径在运营商体系内流失这个词远没有看上去那么简单。最容易被想到的流失定义是用户办理了销户不再使用该运营商的服务这确实是流失但只是最狭义的一种。实际运营中项目组通常要区分三种口径硬流失用户主动销户转网去了别的运营商这是终极意义上的流失软流失用户没有销户但通话时长、流量使用、充值频率持续下滑处于半死不活状态随时可能转网准流失用户因为欠费停机、长期不活跃等原因事实上已经停止使用但号码还在那里没有走销户流程。这三种口径对应完全不同的运营策略。硬流失用户要的是挽留软流失用户要的是激活准流失用户要的是确认状态后决定是否放弃。建模之前如果不定清楚做哪一种后面的标签、特征、评估都会变得很模糊。在真实项目里,我见过某运营商把连续90天无通话、无流量、无充值作为准流失的判定标准。这个口径比是否销户更能反映用户的真实状态因为很多用户并不会主动销户而是直接用脚投票把号码丢在一边换了新卡。1.2 时间窗口的设定观察期与表现期怎么划分定义流失标签时还得想清楚时间窗口。通常的做法是把历史数据切成两段观察期和表现期。观察期用来提取用户特征表现期用来判断用户是否流失。打个比方如果今天是2025年3月1日我们以2025年1月1日到2月28日作为观察期提取用户在这两个月内的使用行为特征然后把2025年3月1日到3月31日作为表现期如果用户在这一个月内满足流失定义比如销户、或零使用就打上流失标签。这样机器学习模型才能学到过去的哪些行为特征和未来发生流失强相关。这个时间窗口的跨度要根据业务节奏来定。电信用户的流失周期通常以月为单位所以观察期取一到三个月、表现期取一个月是常见配置。观察期太短特征会不稳观察期太长特征覆盖的是太久远的行为可能和当前状态脱节。2. 数据准备电信数据集里到底有哪些料值得挖电信流失分析相比其他行业的客户分析最大的优势就是数据维度极其丰富。通话、流量、短信、位置、缴费、客服交互……几乎每个触点都在产生数据。但这些数据绝大部分是原始日志不经过加工没法直接用。2.1 典型的可用数据维度盘点做电信流失项目通常能拿到的数据大致有这几类数据类别典型字段能反映的流失信号客户基本信息在网时长、年龄、套餐档位、入网渠道在网越久流失率越低高套餐用户对价格更敏感通话行为主叫次数、被叫次数、呼转次数、国际长途次数通话频次降低是流失前兆流量行为4G/5G流量用量、WiFi使用时长、日均使用时段流量骤降说明用户切换了主力网络缴费行为缴费方式、缴费周期、欠费次数、充值金额缴费周期拉长、经常欠费是高风险信号客服交互投诉次数、投诉类型、咨询次数、万号接通率投诉暴增之后不解决就容易流失套餐信息套餐价格、套餐剩余量、是否合约期合约期用户短期内不易流失这里每个维度都不是单看一个字段而是要组合出变化趋势。一个人本月主叫100分钟、下月主叫30分钟比月均主叫65分钟这个静态数字更有信息量。2.2 常见数据质量问题和处理方式数据质量是这个项目最耗时也最磨人的环节。我从实际跑数据遇到的典型问题说起第一用户标识问题。同一个用户可能在不同系统里有不同的用户ID通话详单里的ID和缴费系统里的ID如果无法一一对应特征就会算错人。这种问题没有捷径只能靠关联字段电话号码、身份证件、设备识别码反复匹配核对。第二缺失值的正确姿势。电信数据里缺失经常不是没有数据而是一种业务信号。比如一个用户没有流量使用记录可能说明他根本不用流量也可能说明数据采集有问题。这时候不能直接填0或者填中位数建议单独构造一个是否产生流量的二值特征再配合一个流量使用量特征把缺测变成有价值的信息。第三异常值的处理。偶尔会看到月流量几百个G、通话时长几千分钟的用户这种数据有可能是企业用户、物联网设备用户也有可能是相同号码在不同系统间的记录串了。建议先做分位数截断再结合业务判断是否保留。实践中一个比较稳妥的做法是在处理完缺失值和异常值后额外保留一版原始的未清洗数据方便随时回头核对特征计算有没有引入偏差。这个习惯救过我很多次因为特征工程的迭代往往需要回溯。3. 特征工程把原始数据变成流失信号前面说过电信流失项目的成败很大程度看特征工程。这一部分我会给出一个可以直接落地的特征体系然后逐一解释每个特征为什么有用以及计算的时候要注意什么。3.1 消费与缴费类特征用户钱包的行为轨迹消费缴费类特征是流失分析里权重最高的一类原因是用户愿意花钱、花钱的节奏是否稳定直接反映了他对当前运营商服务的依赖度。ARPU每用户平均收入月度变化率( (本月ARPU - 上月ARPU) / 上月ARPU )持续下降说明用户在主动降档或减少使用流失风险提升。缴费金额离散系数用近六个月的缴费金额算标准差除以平均值离散系数越大说明缴费越不稳定。缴费金额忽高忽低的用户比稳定缴费的用户更容易流失。平均充值周期统计用户两次缴费之间的平均间隔天数。对预付费用户来说充值周期拉长是一个很明显的危险信号。近三个月欠费次数欠费次数多的用户要么是财务紧张要么是不够重视当前号码不管是哪种流失概率都偏高。计算这类特征时要特别注意缴费金额和充值金额的区别。用户可能用充值赠送、抵扣券等方式缴费单纯看银行实缴流水会漏掉一部分信号。如果数据里有充值渠道标识建议分开统计。3.2 使用行为类特征通话和流量的衰退曲线第二类核心特征是用户对网络的使用行为直接刻画用户活跃度。通话时长下降斜率用近三个月的月度主叫时长做线性拟合斜率为负且绝对值越大流失风险越高。这个特征比简单的月度差值更平滑抗噪声能力更强。流量使用筑底程度计算用户近三个月的最低单月流量除以近半年月均流量比值越低说明用户出现流量断崖式下跌的可能性越大。主被叫比例变化正常用户的被叫次数通常与社交活跃度正相关。如果主叫明显减少、被叫维持不变说明用户自己不太主动发起联系活跃度在走低。高流量时段活跃天数电信用户夜间或早晚高峰使用流量的天数反映用户的日常使用黏性。超过两周没有在高峰时段活跃流失风险显著上升。一个额外的经验是通话类特征对老年用户群体效果更好流量类特征对年轻用户群体效果更好。如果建模时有办法拿到用户年龄段可以考虑对这两个群体分开建模或者至少在特征里加入年龄段交叉项。3.3 客户服务与关系类特征那些不满意的信号客户和运营商之间每一次接触都在表达态度。这类特征在流失模型中往往是排第二梯队但不可缺少的部分。投诉次数与投诉类型近三个月投诉超过两次的用户流失概率会明显上升。但不同投诉类型差别很大网络质量投诉通常说明用户还在意服务质量是修复就能留下的用户资费投诉则往往是流失前最后的信号。投诉响应时长从用户发起投诉到投诉工单关闭的平均时长。响应越慢用户越可能积怨流失概率越高。客服主动外呼次数运营商在用户合约到期前通常会有外呼记录这些外呼次数和结果能非常直接地反映用户处在什么样的生命周期节点。历史停机次数这个特征容易被忽略但它其实很有效。历史上多次停机的用户对运营商的容忍度更低系统性风险更大。3.4 时必须加入的几个以防万一特征除了上面几类有几个特征虽然不显眼但实战中经常能挤进特征重要性排名的前二十在网时长几乎所有流失模型里都显著。在网时长超过三年的用户对运营商具有较高的忠诚度流失率远低于一年以内的新用户。但这个特征和套餐合约期要一起看新用户正在合约期内时短期内不会流失一旦合约到期就会迎来一个流失高峰。号码变更次数用户在运营商侧是否频繁更换号码但没销户一个号码用不长久的人对号码的归属感低流失概率高。是否政企用户政企用户和公众用户的流失逻辑差异巨大建模前必须单独标记。套餐饱和度月流量用量 / 套餐内含流量这个比值超过0.85的用户有流量不够用的痛点但低于0.3的用户则存在花多了但用不完的降档风险。特征工程做完后建议做一次截面分析每种特征按10等分分成十组看每组的流失率分布。如果一个特征分了十组后每组流失率都在整体均值附近说明这个特征基本没用如果组间差异很大哪怕相关性系数不高也要保留。4. 探索性分析在建模之前先让数据说出流失信号很多教程把探索性数据分析EDA轻描淡写过掉了但在我实际做下来的体感里EDA花费的时间至少占整个项目的三成。因为EDA一方面能帮你验证特征定义是否合理另一方面能让你在建模前就对哪些用户会流失有一个定性的判断这对后续调参和解释模型都有好处。4.1 单变量分析找出最锋利的切分点对每个核心特征都要画一张特征值分箱 vs 流失率的曲线观察流失率是否随特征值单调变化或者存在某些突变区间。举一个常见现象在网时长特征分箱后通常能看到一个清晰的规律——在网6个月到1年之间的用户流失率最高在网3年以上的用户流失率大幅下降。这说明运营商的新手保护期失效时就是流失风险暴露最明显的窗口期。看到这个规律后你在建模时就可以把在网时长做成分段哑变量而不是直接扔一个连续值进模型。再比如投诉次数往往是投诉0次和投诉1次的用户流失率差异不大但投诉2次及以上的用户流失率激增。这种情况下一个简单的是否投诉超过2次的0/1特征可能比投诉次数本身更好用。4.2 交叉分析在维度组合里找高危人群单变量分析只回答哪个变量有效交叉分析则更进一步回答哪一类具体的人最危险。在电信项目里比较经典的交叉观察有在网时长 × 套餐档位能看出低档套餐新用户是否是流失重灾区缴费周期 × 投诉次数缴费不规律且有过投诉的用户几乎是流失模型里必中的高危群流量使用率 × 是否合约期合约期耗尽且流量超限的用户容易流向不限量套餐的竞品。交叉表的形式一般用透视表就能完成groupby两个维度算流失率均值即可。目的是在建模前形成对用户的画像直觉而不是追求统计显著性。4.3 业务不可触碰的观察高频流失时段这类项目里还有个比较容易被忽视的分析角度用户流失的时间规律。按月统计流失用户数量观察流失高峰出现在什么月份。在我做过的数据集里每年年初和开学季往往出现流失高峰原因很容易理解——学生用户换城市、毕业生换工作带动一批号码注销或转为低使用状态。这类时间规律单看分析价值有限但它提醒你建模时如果把时间因素纳入能有效提升时效性。真实业务中流失预测通常每个月重跑一次模型纳入季节性因素后模型才能在正确的时间点给出正确的高风险名单。5. 建模选型与训练从逻辑回归到梯度提升树的实战取舍数据齐了特征也验证过有效性接下来才轮到建模。网上各种模型对比的文章很多但真正动手做项目时选择要兼顾效果、稳定性、可解释性和落地成本。我的建议是按以下顺序分层选择。5.1 Baseline模型先用逻辑回归把一个笨但稳的底打出来所有建模项目都必须先跑一个baseline流失分析项目里逻辑回归作为baseline几乎是默认选择。为什么是逻辑回归不是因为它效果好而是因为它简单、快、可解释。逻辑回归输出的概率值天然平滑后面做阈值调整时很方便每个特征的系数直接能看到正负方向可以在初期帮助检查特征逻辑是否和业务常识一致。代码示例大致是这样的from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split from sklearn.preprocessing import StandardScaler X feature_matrix.drop(churn_label, axis1) y feature_matrix[churn_label] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, stratifyy, random_state42 ) scaler StandardScaler() X_train_scaled scaler.fit_transform(X_train) X_test_scaled scaler.transform(X_test) lr LogisticRegression(max_iter1000, random_state42) lr.fit(X_train_scaled, y_train)跑完看一遍系数如果某个特征的系数方向和业务认知相反先别急着调模型回去查特征计算过程。比如在网时长系数如果是负数在网越久越不容易流失这符合认知但如果出现缴费金额越高越容易流失这种反直觉结果多半是特征计算里混进了异常值。5.2 主力模型为什么梯度提升树是流失预测的实战首选baseline验证完特征没问题后主力模型我推荐直接上梯度提升树类模型具体选择在XGBoost和LightGBM之间更推荐后者。流失预测场景有几个特点非常适合这类模型特征类型混杂有连续值、有类别值、有高基数类别值树模型天然不用做太多预处理特征之间存在大量交互效应比如套餐饱和度×是否合约期树模型可以自动学习这些组合模式数据量通常不大不小几万到几十万用户量级梯度提升树训练成本完全可控。LightGBM的代码相对简洁重点参数设置在第一次跑的时候建议这样配import lightgbm as lgb train_data lgb.Dataset(X_train, labely_train) valid_data lgb.Dataset(X_test, labely_test) params { objective: binary, metric: auc, boosting_type: gbdt, learning_rate: 0.05, num_leaves: 31, max_depth: -1, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 5, min_data_in_leaf: 50, verbose: -1 } model lgb.train( params, train_data, num_boost_round1000, valid_sets[valid_data], callbacks[lgb.early_stopping(50), lgb.log_evaluation(100)] )这些参数的经验值适合大多数电信流失数据集。第一版跑出来后优先看AUC和特征重要性然后开始调参。调参顺序有讲究先调num_leaves和min_data_in_leaf控制模型复杂度再调feature_fraction和bagging_fraction做随机化防过拟合最后调learning_rate配合num_boost_round做精细收敛。5.3 类别不平衡问题用阈值和权重而不是盲目采样电信数据集的流失率通常只有10%-20%左右有些场景甚至低至5%。这种不平衡会让模型倾向于把所有样本都预测为不流失因为这样准确率也挺高。但对业务来说毫无意义。这时需要两条处理路径第一条路径是调整损失权重。在LightGBM里给正样本流失用户更大的权重等价于让模型更关注少数类。scale_pos_weight (len(y_train[y_train 0]) / len(y_train[y_train 1])) # 或者直接用 2-5 这样的经验倍数看验证集表现而定第二种路径是不要动训练数据分布而是调预测阈值。模型输出的其实是概率默认把概率大于0.5判为流失。但在不平衡场景下这个阈值通常太低会把一大堆中风险用户误判为流失。正确做法是把验证集上的预测概率按从高到低排序看不同阈值下的精确率和召回率选择一个符合业务预期的点。我的习惯是优先试第二种路径只有在模型整体的区分能力确实不够时才配合第一种路径调权重。原因是过采样或SMOTE这类做法会让训练分布偏离真实分布虽然训练集指标很好看但上线后效果往往打折。5.4 验证策略记得用时间切片而不是随机切分流失分析场景有一个很强的时序属性用户的特征来自过去标签来自未来。如果用随机切分训练集和测试集会泄露时间趋势导致模型在测试集上表现虚高。更接近真实场景的做法是按时间切片比如使用前两个月做训练使用后一个月做验证。这样能模拟出假设我用截至2月底的数据训练模型预测3月的流失这个真实的上线场景。# 假设有 month 字段 train_mask feature_matrix[month] 2025-01-31 valid_mask feature_matrix[month] 2025-02-28 X_train feature_matrix[train_mask].drop(churn_label, axis1) y_train feature_matrix[train_mask][churn_label] X_test feature_matrix[valid_mask].drop(churn_label, axis1) y_test feature_matrix[valid_mask][churn_label]这种验证方式牺牲了一点样本量但换来的评估结果和真实上线效果更接近。我在多个项目里对比过随机切分的AUC通常比时间切分高出一截但那是因为模型偷看了未来的信息分布实际上线后表现会缩水。6. 模型效果评估与解释不只是看AUC建模完成不等于项目结束在真实项目里模型解释和业务落地才是大头。因为模型输出用户A流失概率80%这个数字运营同事没法直接用必须转换成哪些用户可以打电话挽留、应该用什么策略这样的具体行动。6.1 评估指标的取舍精确率、召回率、AUC到底看哪个流失预测场景里AUC是建模阶段最常用的指标但真正决定业务价值的是精确率和召回率的平衡。AUC回答的问题是模型有没有把流失用户排在前面它衡量的是排序能力精确率回答的问题是预测会流失的人里真的流失的比例有多少精确率低意味着运营团队打一百个电话里大多数都打给不会流失的用户浪费人力召回率回答的问题是真正流失的人里模型找到了多少召回率低意味着大量用户没被抓到就悄悄流失了。实际业务中流失关怀的人力是有限的。我曾经碰到运营部门给出的指标是每周提供最多5000个预警名单希望其中至少15%的用户是可挽留的。这种情况下就要按这个硬性约束倒推阈值在验证集上找到使精确率达到15%附近、召回率尽可能高的那个概率阈值然后把概率大于该阈值的用户名单交给运营。代码层面可以用precision_recall_curve来做这件事from sklearn.metrics import precision_recall_curve precision, recall, thresholds precision_recall_curve(y_test, proba_test) # 找到精确率 0.15 时的最高召回率对应阈值 valid_indices [i for i, p in enumerate(precision) if p 0.15] best_idx valid_indices[-1] # 精确率满足前提下召回率最大 chosen_threshold thresholds[best_idx - 1]6.2 用SHAP给运营同事一个可以说服人的挽留理由运营同事拿到名单后第一个问题往往是这是谁我们为什么打给他如果只给一个概率分对方根本不知道从哪里开口。这时候SHAP值就是最好的解释工具。SHAP的核心思想是把模型对某个用户的预测分解到每个特征上算出每个特征对流失概率的贡献是增大还是减小。import shap explainer shap.TreeExplainer(model) shap_values explainer.shap_values(X_test) # 单个用户解释 shap.force_plot(explainer.expected_value, shap_values[0,:], X_test.iloc[0,:])实际落地时可以从每个高风险预测用户里提取出贡献最靠前的两到三个正向特征原因直接用自然语言描述成挽留理由用户近三个月投诉2次涉及网络质量且当月流量用量只有上月的40%建议优先检查其所在区域网络覆盖问题。用户为高套餐用户连续两个月流量使用率不足20%建议推荐降档或转换套餐避免因套餐费用过高導致用户产生换卡冲动。用户合约期将于下月到期建议提前推送续约优惠方案。这种输出才真正实现了从预测到行动的闭环。我见过很多精良的流失模型因为不好解释被搁置在数据部门反而不如那些效果略差但能把理由说清楚、运营愿意用的模型。为了提升可解释性建模时也可以在保证效果的前提下适当减少特征数量。比如先用模型特征重要性筛出top30特征重新训练效果下降不明显的话就优先用这个精简版。特征少SHAP解释的压力就小运营理解的成本也低。6.3 特征重要性排序的几个隐藏陷阱最后还想多说几个在解释模型时容易出问题的点。第一特征重要性不等于业务重要性。一个特征在模型里重要可能只是因为它是另一个特征的代理。比如投诉类型特征重要可能本质上是用户是否使用某低效率渠道这个隐藏信息在起作用。解释时要结合SHAP的依赖图进一步确认。第二部分依赖图PDP比特征重要性更接近真实效应。比如在网时长在特征重要性里排第五但PDP图能告诉你它和流失概率之间的关系到底是什么样的曲线形状。如果PDP图显示在网时长超过5年流失概率出现回升那说明老用户也不是铁板一块要有专门的维系策略。第三类别特征的SHAP解释要小心。高基数类别特征比如用户所在城市有几百个取值在模型里可能会占用很高的特征重要性但它对业务来说可能只是地区运营差异的体现。这种情况下可以单独做一个地区效果变量而不是把几百个城市全部作为独立类别否则模型容易过拟合到个别城市的小样本上。7. 从预测到挽留项目落地的最后一公里模型评估通过后接下来的任务是把模型输出变成业务动作。这一部分最容易被忽视但往往决定项目是否真的产生价值。7.1 风险分层与名单输出不是只有高流失和非流失两种进运营环节的名单不应该是一个简单的二分类。更实用的做法是把用户分成三到四层高流失风险P 0.7立即人工干预采用有吸引力的挽留策略中高风险0.4 P 0.7系统自动触发优惠券或关怀短信观察响应情况中低风险0.2 P 0.4日常触点维护比如客服致电服务调查低风险P 0.2正常运营不打扰。分层的阈值同样要结合运营人力来定而不是按统计上的最佳点。通常运营人力是有限资源所以精确率优先的阈值适合放进人工名单召回率优先的阈值适合放进自动触达。7.2 挽留策略的A/B测试设计上了名单之后还需要通过A/B测试验证挽留策略是否真有效。比如从高流失名单里随机分成两个组一组收到100元话费券定向流量包另一组只收到常规问候短信。观察四到八周后的真实流失率差异。这里的关键点很反直觉你必须给对照组留一些流失空间。如果运营为了追求挽留率100%把所有用户都给了大力度的优惠A/B测试就失效了因为你看不出来优惠到底有没有用。所以至少在测试期一定要让一部分高流失用户自然发展忍住不给他们优惠。这种短期浪费时间的代价换来的是长期策略效果的准确判断。7.3 模型上线后的运营监控警惕数据漂移模型上线不是终点。很多流失项目死在上线三个月后模型突然不灵了。原因通常是运营和竞品的策略变了用户行为模式随之变化导致数据和建模时差异很大。所以上线后至少每月监控三类指标模型效果指标当月预测名单的真实流失命中率和验证集上的表现做对比特征分布指标核心特征ARPU变化率、投诉次数、流量使用率的均值和分布有没有明显偏移业务逻辑指标比如高流失名单里的用户构成是否从学生群体漂移成老年群体这种结构性变化意味着现实世界发生了什么大变化。一旦发现特征分布偏移明显就要考虑特征更新或模型重训。我在实际项目里的做法是每月全量重算特征每季度重训一次模型同时保留每个版本的预测结果和真实标签作为后续模型迭代的样本。8. 踩过的坑与最后想分享的心得这类项目做多了总会沉淀一些很难从教科书上学到的东西这里挑三个感触最深的说说。8.1 第一个坑把流失预测做成了流失解释见过太多很多分析做出来变成了我们发现投诉率高的用户流失率高——这当然没错但运营看了也等于没看。预测模型的价值是提前发现不是事后解释。所以业务上更关心的是用户还没投诉、还没降档的时候你能不能通过缴费周期拉长、流量使用趋势变缓这些早期信号提前预判。建模目标要围绕提前一个月识别高风险用户来设计而不是解释过去三个月谁流失了。8.2 第二个坑忽视真实的业务成本约束模型再好如果运营按名单打电话的转化率低于成本线项目就是亏钱的。我在和运营同事对接时专门算过一笔账一次人工外呼的成本约等于X元一个高价值用户的月ARPU约等于Y元挽留成功后的平均留存期Z个月。只有当外呼成本 留存收益时这个名单才值得打。所以模型调优不只是调统计指标要调到名单里的用户确定性够高、数量够符合人力这两者同时成立。8.3 第三个坑别把全部希望寄托在模型上说句实在话流失模型能告诉你的只是谁更可能走它很难告诉你怎么样才能让他不走。后者要靠产品、资费、服务、网络质量这套体系共同作用。分析的真正角色是把有限的经营资源引导到最该被关注的那批用户身上这本身就是巨大的价值。我个人的看法是一个优秀的流失分析项目应该在你做完之后让运营团队对每一批名单的用户画像和流失原因都了然于心能够并愿意立刻开展触达动作。如果你的模型输出只是躺在报表系统里的数字那它再准也没有意义。最后分享一个习惯每次迭代模型把当期的特征重要性、SHAP截图、验证集指标、上线后的结果反馈留档保存。下一次重训时对比这些历史记录你能很快判断出是业务环境变了、数据质量变了还是模型调错了。这个留档习惯比任何建模技巧都值钱。