简介面向数据分析与机器学习入门者的电信用户流失预测完整项目基于Kaggle公开数据集从数据读取与清洗起步依次完成三大特征群可视化对比、皮尔逊相关系数剔除冗余特征、类别不平衡处理等关键步骤并采用K折交叉验证对逻辑回归、随机森林、AdaBoost、XGBoost四种模型进行评估最后合并预测流失率与真实流失率形成可用于客户召回决策的分组阈值方案。资源共5个文件包含主分析脚本py、Notebook逐步实现ipynb、原始CSV数据、项目说明文档md与答辩PPT整体压缩包仅10.88MB。已有805人学习下载。借助这套资料可快速复现完整建模流程学习特征工程与不平衡样本处理技巧参考可视化图表与模型对比结果适用于课程设计、学术答辩及Kaggle实战入门。1. 电信用户流失预测为什么流失率降一个点比拉新一万户更值钱电信用户流失预测是数据科学里少有的几个「业务价值可以直接用钱算出来」的场景。一个老用户每多留一个月带来的收入是确定的而获取一个新用户的成本通常是维系一个老用户的五到七倍。所以各家运营商都在做同一件事用Python从历史账单、通话记录、投诉工单里挖出「即将要走的人」赶在他离网之前用优惠券、客服回访或者套餐降档把他拦住。这个方向不算新但真正把它做好并不容易——难点不在模型算法而在标签怎么定义、特征怎么建、以及预测结果怎么变成运营动作。这篇文章我会按自己做过的一版完整流程来讲从数据表长什么样开始到特征工程、基线模型、类别不平衡处理再到踩过的坑和落地技巧。适合刚接触分类问题、想拿一个真实业务场景练手的Python学习者也适合已经在做运营分析、想自己搭一套流失预警的从业者。2. 流失预测的建模思路先定标签、再定特征、最后才谈模型很多人一上来就调模型结果指标虚高上线一测就翻车。问题往往出在最前面流失的标签定义和业务口径根本没有对齐。这一章先把建模的三块地基讲清楚。2.1 流失标签怎么定义三种常见口径与选择标准流失不是一个客观存在的物理量它是业务定义出来的。我见过三种最常见的口径第一种是合约口径。用户签订的合约比如一年期宽带或手机套餐到期后没有续约就记为流失。这个口径最干净数据也好取但缺点是滞后——用户可能合约到期前两个月就已经不用了你等到到期才标记反应太慢。第二种是使用行为口径。连续N天没有通话、没有流量消耗、没有登录App就判定为沉默流失。这个口径时效性好能提前发现「人在但不用」的客户但阈值N怎么定很玄学定短了会把正常低活用户误伤。第三种是主动销户口径。用户到营业厅或客服热线办了拆机、销号这是最确凿的流失信号但问题是你只能在用户已经决定走的时候才知道预测的意义就大打折扣。我做项目时一般用组合口径主标签用合约到期未续约辅标签用连续30天零使用。训练模型时先把两类都算出来对比一下覆盖率。选标签的标准是三条业务上能不能解释、数据上能不能取到、时间上能不能提前预警。如果标签本身滞后两周那模型做得再好也只是事后诸葛亮。2.2 特征工程的骨架用户属性、消费行为、交互痕迹三类特征流失预测的特征可以粗分为三大类每一类都有它的作用和坑。用户静态属性入网时长、年龄、性别、所在地域、套餐类型、合约类型、付费方式预付费还是后付费。这类特征变化慢但往往预测力很强。特别是入网时长业界普遍观察到「新用户头三个月流失率最高老用户流失率稳步下降」所以tenure几乎是所有流失模型里排前三的特征。消费行为特征月均话费、流量使用量、超出套餐部分的金额、账单金额的波动幅度、欠费次数、缴费是否准时。这里有个关键点——不要只取平均值。平均值会抹掉趋势比如一个用户月均消费100元跟另一个从150元掉到50元的用户平均值可能一样但后者显然更危险。所以要构造差分特征本月消费比过去三个月均值下降了多少、流量使用量的环比变化率。交互与投诉特征近30天投诉次数、客服通话时长、账单异议次数、是否曾申请过停机保号。投诉是最强的流失前兆之一但要注意做时间对齐——投诉发生在标签日之前才算有效特征发生在标签日之后的要去掉。我在实际项目里的经验是特征别贪多先围绕业务逻辑造30到50个跑基线模型看特征重要性把明显没用的砍掉。一上来就堆几百个特征反而容易过拟合而且上线后特征计算成本高运维也痛苦。2.3 评估指标选哪个准确率是陷阱召回率和AUC才是主线流失预测是一个典型的类别不平衡问题真实流失率通常在5%到15%之间。如果模型对所有人都预测「不流失」准确率能到90%以上但这个模型毫无价值。所以评估指标要从业务目标倒推。假设运营团队的诉求是「给我一份最可能流失的用户名单我们去打电话回访」。那核心指标就是召回率——在所有真正流失的用户里模型找出来了多少。回访预算有限所以还要看精确率——名单里打过去真的有流失倾向的人占比多少。精确率和召回率是跷跷板通常用F1分数平衡但业务上我会更看重召回率因为漏掉一个流失用户损失的是全年收入而多打几个电话只是多花一点人力成本。另外两个指标是AUC和KS。AUC不依赖具体阈值适合评估模型排序能力KS则常用于信用评分场景在流失预测里也能用它衡量的是好坏用户得分分布的最大分离程度。我一般先看AUC确认模型整体有效再按业务预算去调精确率和召回率的阈值平衡点。2.4 数据切分的时间意识不要随机打乱要按时间窗口切这一点要单独强调。很多人直接用train_test_split随机切分这在流失预测里是有问题的。流失预测讲究的是「用过去预测未来」训练集应该是1月到6月的数据标签是6月之后是否流失验证集和测试集应该是7到9月的数据。如果随机打乱相当于模型偷看了未来测试指标会虚高上线后立刻打回原形。后面避坑章节会再展开这里先记住一个原则流失预测的切分方式必须是时间序列切分而不是随机切分。3. 用Python跑通最小流程从CSV到第一版模型这一章直接上代码。我会用一个模拟的电信用户数据表字段结构跟常见的运营商流失分析数据集保持一致你换成自己公司的表也能按同样的流程走。3.1 数据加载与探索性分析先看清流失率和字段分布import pandas as pd import numpy as np # 模拟数据加载实际使用时替换为真实数据路径 df pd.read_csv(telecom_churn.csv) print(df.shape) # 查看行数和列数 print(df.head(3)) # 预览前几行 # 核心业务指标流失率 churn_rate df[churn].mean() print(f整体流失率: {churn_rate:.2%}) # 查看每个字段的缺失情况和类型 df.info() # 分类字段的取值分布重点看是否有异常值 for col in [contract_type, payment_method, region]: print(f\n{col} 分布:) print(df[col].value_counts(normalizeTrue))这段代码做了三件事确认数据规模、算整体流失率、检查字段类型和缺失。流失率如果低于2%或高于40%都要停下来想想标签口径是不是有问题。df.info()能快速暴露字段类型错乱——比如把数值字段读成了object通常是因为数据里有空格或特殊字符。# 数值字段的分布摘要 num_cols [tenure_months, monthly_charges, total_charges, avg_monthly_usage, complaint_count_30d] print(df[num_cols].describe().T)describe()输出的均值、分位数是判断特征是否需要处理的依据。比如complaint_count_30d如果90%的用户都是0这说明特征非常稀疏后面可以考虑做二值化有没有投诉而不是用原始计数。3.2 特征编码与数据集切分分类变量转数值时间窗口切数据from sklearn.model_selection import train_test_split from sklearn.preprocessing import OneHotEncoder, StandardScaler from sklearn.compose import ColumnTransformer import pandas as pd # 特征列把字段按类型分组 cat_cols [contract_type, payment_method, region, gender] num_cols [tenure_months, monthly_charges, total_charges, avg_monthly_usage, usage_change_ratio, complaint_count_30d] # 标签1表示流失0表示不流失 y df[churn] X df[cat_cols num_cols] # 关键点按时间切分而不是随机切分 # 假设数据里有一个月份字段我们按前7个月训练、后3个月验证 train_mask df[month] 7 test_mask df[month] 7 X_train, X_test X[train_mask], X[test_mask] y_train, y_test y[train_mask], y[test_mask] # 分类变量独热编码数值变量标准化 preprocessor ColumnTransformer( transformers[ (num, StandardScaler(), num_cols), (cat, OneHotEncoder(handle_unknownignore), cat_cols) ]) X_train_processed preprocessor.fit_transform(X_train) X_test_processed preprocessor.transform(X_test) print(f训练集样本数: {X_train_processed.shape[0]}) print(f测试集样本数: {X_test_processed.shape[0]})这里有两个容易忽略的参数。OneHotEncoder(handle_unknownignore)是必须的——线上预测时新用户可能来自训练数据里没见过的地区不设置这个参数程序会直接报错。ColumnTransformer把数值和分类特征的处理封装在一个对象里fit只用在训练集上transform同时用在训练和测试集这是防止数据泄漏的标准做法。3.3 基线模型逻辑回归和随机森林各跑一版对比from sklearn.linear_model import LogisticRegression from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import roc_auc_score, precision_recall_curve, f1_score # 逻辑回归基线class_weightbalanced处理类别不平衡 lr LogisticRegression(max_iter1000, class_weightbalanced, random_state42) lr.fit(X_train_processed, y_train) # 随机森林基线 rf RandomForestClassifier( n_estimators200, # 树的数量200够用再多收益有限 max_depth6, # 限制深度防止过拟合 min_samples_leaf50, # 叶子节点最少样本数降方差 class_weightbalanced, random_state42, n_jobs-1 # 使用所有CPU核心加速训练 ) rf.fit(X_train_processed, y_train) # 在测试集上评估 for name, model in [(逻辑回归, lr), (随机森林, rf)]: y_prob model.predict_proba(X_test_processed)[:, 1] auc roc_auc_score(y_test, y_prob) print(f{name} AUC: {auc:.4f})先说逻辑回归的两个参数。max_iter1000是给优化器足够的迭代次数默认100有时不收敛会弹警告。class_weightbalanced让模型自动按类别频率加权多数类不流失权重低、少数类流失权重高这是处理类别不平衡最省事的方式。随机森林的max_depth6和min_samples_leaf50是我习惯的保守配置。树不深、叶子不小模型方差就低对流失这种噪声很大的业务数据更稳。跑完对比AUC我一般会遇到两种结果逻辑回归和随机森林AUC接近或者随机森林略高。AUC接近说明特征里的线性信号已经够用这时候我会优先选逻辑回归——可解释性强上线之后运营团队问「为什么预测这个人流失」你至少能说出是哪些特征在驱动。4. 效果再往上走不平衡处理、阈值调优、特征解读基线模型跑通只是第一步。这一章讲三个能显著提升实际效果的操作都是可以在现有代码上直接改的。4.1 类别不平衡的正规处理SMOTE采样和class_weight怎么选class_weightbalanced是成本最低的基线方案但它本质是给样本加权不会增加模型见过的少数类样本多样性。如果想要更强的效果可以考虑过采样。业界最常见的做法是SMOTE它对少数类样本做插值生成新样本。from imblearn.over_sampling import SMOTE from imblearn.pipeline import Pipeline as ImbPipeline # 注意SMOTE必须在训练集上做绝不能对测试集做 smote SMOTE(random_state42, k_neighbors5) # 如果用Pipeline要确保smote在特征处理之后、模型训练之前 pipeline ImbPipeline([ (preprocessor, preprocessor), (smote, smote), (classifier, LogisticRegression(max_iter1000, random_state42)) ]) pipeline.fit(X_train, y_train) y_prob pipeline.predict_proba(X_test)[:, 1] print(fSMOTE 逻辑回归 AUC: {roc_auc_score(y_test, y_prob):.4f})这里要注意k_neighbors的默认值是5如果少数类样本非常稀疏比如流失用户只有几百人插值生成的样本会很靠近边界甚至重叠这时候可以把k_neighbors调小到3。另外SMOTE只对训练集做——如果对测试集做等于人为改变了真实流失率的分布评估指标会完全失真。这也是为什么我用ImbPipeline把SMOTE和模型封装在一起从结构上避免误操作。# 对比只用class_weight和加了SMOTE的效果差异 from collections import Counter print(原始训练集类别分布:, Counter(y_train)) X_resampled, y_resampled smote.fit_resample(X_train_processed, y_train) print(SMOTE后训练集类别分布:, Counter(y_resampled))我实际跑下来SMOTE对逻辑回归的提升通常在1到3个AUC点对随机森林的提升不明显甚至可能下降。原因是树模型本身对不平衡相对鲁棒而插值生成的样本可能引入噪声。所以我的建议是先用class_weightbalanced跑通如果AUC不够再试SMOTE不要一开始就上重武器。4.2 阈值调优用精确率-召回率曲线找业务最优切分点模型输出的概率本身没有业务含义只有当你设定一个阈值——概率大于0.6才拉入预警名单——它才变成可执行的决策。默认0.5在这个场景往往不是最优的因为流失率只有10%左右模型预测的概率分布整体偏低。from sklearn.metrics import precision_recall_curve import matplotlib.pyplot as plt # 计算不同阈值下的精确率和召回率 precision, recall, thresholds precision_recall_curve(y_test, y_prob) # 找F1最高的阈值 f1_scores 2 * precision * recall / (precision recall 1e-9) best_idx f1_scores.argmax() best_threshold thresholds[best_idx] print(fF1最优阈值: {best_threshold:.3f}, F1: {f1_scores[best_idx]:.3f}) # 业务视角假如回访团队每天只能处理100个用户就看召回率在哪个阈值 target_precision 0.5 # 假设名单里至少一半要真的是流失倾向 valid_idx [i for i, p in enumerate(precision) if p target_precision] if valid_idx: idx valid_idx[-1] # 精确率达标时召回率最高的点 print(f精确率{target_precision}时推荐阈值: {thresholds[idx]:.3f}, f召回率: {recall[idx]:.3f})这个逻辑很重要阈值不是一个模型参数它是业务决策变量。回访人力充足就把阈值调低宁可多打骚扰电话也不放过一个回访人力紧张就把阈值调高只盯概率最高的那批人。我一般会输出一张阈值-精确率-召回率对照表让运营负责人自己选而不是我替他拍板。4.3 特征重要性模型说谁在驱动流失帮你验证逻辑模型如果是随机森林直接取特征重要性如果是逻辑回归看系数绝对值。两种都可以用来跟业务方对答案。# 随机森林特征重要性 import numpy as np # 拿到独热编码后的特征名 feature_names (num_cols list(preprocessor.named_transformers_[cat] .get_feature_names_out(cat_cols))) importances rf.feature_importances_ sorted_idx np.argsort(importances)[::-1] print(Top 10 特征:) for i in sorted_idx[:10]: print(f {feature_names[i]}: {importances[i]:.4f})我拿到特征重要性列表的第一件事不是看排名而是看有没有违反业务常识的特征排在最前面。比如「地域_某市」重要性异常高而业务方说那个市没什么特别——那就要警惕是不是数据里有泄漏或者样本量偏差。特征重要性不只是解释模型它还是数据质量的探针。5. 流失预测的四大常见坑与排查清单这一章写我踩过的坑按「现象 → 原因 → 解决」的顺序每条都是真实项目里出现过的。5.1 数据泄漏AUC高达0.98上线后一塌糊涂现象测试集AUC跑到0.95以上看着非常漂亮结果模型上线后实际区分度很差运营按名单回访命中率远低于测试预期。原因特征里混进了「未来信息」。最典型的是把「是否已提交销户申请」「当月套餐外费用是否已扣」这种只在流失发生后才能确定的字段当成了预测特征。模型学到的是「看到销户申请就预测流失」而不是「从行为模式预测流失风险」。解决把特征分成两类——标签日之前能拿到的数据才允许入选。我有一个习惯做法每个特征都问一句「在预测时间点 T 这一刻这个值我能知道吗」不知道的一律砍掉。另外可以做一次泄漏扫描单特征AUC超过0.85的基本都是泄漏嫌疑逐个人工审核。5.2 时间切分错误随机打乱导致的虚高指标现象AUC测试集0.89按时间窗口切分后同一套模型掉到0.78。原因随机切分把同一个月的数据既放进了训练集又放进了测试集用户的消费行为在月份之间有很强的自相关性模型等于记住了「见过这个人」。而真实场景里你要预测的是未来三个月谁流失模型面对的完全是没见过的用户。解决严格按时间窗口切分训练集和测试集之间留一段gap。比如用1到6月训练、7到8月做gap不参与训练也不参与测试、9到12月测试。gap的意义是防止上一个月的消费行为特征直接预报下个月流失——因为实际部署时特征计算和预测之间也有时间差。5.3 特征方向反了消费金额越高反而越预测流失现象特征重要性显示「月消费金额」排在前面但系数是正的——消费越高越流失。业务方看了直接说不可能高消费用户是核心资产怎么会流失。原因数据里的高消费用户一般是合约到期前被收了高额套餐费他们流失是因为套餐太贵而不是因为消费高本身。换句话说这个特征在特定场景下是「价格敏感型流失」的代理变量。解决不要急着删特征先做分层分析——把用户按合约类型、入网时长分段看「高消费」在不同客群里的流失率方向是否一致。如果只在某个客群反向就把特征和客群做交互项再放进模型。流失预测里的特征方向问题很少是数据错更多是业务结构没被模型拆开。5.4 上线后效果衰减AUC每季度掉10%现象模型刚上线时AUC有0.82跑了两个季度掉到0.73运营开始质疑模型有效性。原因业务环境在变。套餐政策调整、竞品促销、节假日营销活动都会改变用户的流失行为模式。模型训练时的规律逐渐失效这是概念漂移。解决建立模型监控例行任务。每个星期统计线上预测分布和实际流失率的偏差如果KS统计量连续上升或者实际流失率偏离训练分布超过30%就要触发重新训练。另外模型上线后要保留预测结果快照这样后续分析「当时为什么预测错了」才有据可查。6. 把概率变成运营动作从预警名单到A/B测试模型跑得再好不能在业务流程里用起来就是一堆数字。这一章讲最后一步——怎么把预测结果变成一线运营能直接执行的清单。我的做法是产出一个分层名单按流失概率切成三个档位高危概率大于0.7、中危0.4到0.7、低危0.2到0.4。高危名单给客服团队打电话回访话术重点放在套餐降档和赠送流量包中危名单推送App优惠券不打电话成本低覆盖面大低危名单只做标记不主动打扰防止过度营销把用户推走。名单产出用一行代码就能搞定# 假设model是训练好的模型preprocessor是已拟合的特征处理器 def generate_churn_list(df_new, model, preprocessor, high_threshold0.7, mid_threshold0.4): X_new preprocessor.transform(df_new) prob model.predict_proba(X_new)[:, 1] result df_new[[user_id, phone, plan_type]].copy() result[churn_prob] prob result[risk_level] pd.cut( prob, bins[0, mid_threshold, high_threshold, 1.0], labels[低危, 中危, 高危] ) return result.sort_values(churn_prob, ascendingFalse) churn_list generate_churn_list(df_this_month, pipeline, preprocessor) # 高危名单单独导出给客服团队 high_risk churn_list[churn_list[risk_level] 高危] high_risk.to_csv(high_risk_customers.csv, indexFalse) print(f高危用户数: {len(high_risk)})名单发下去之后一定要做闭环验证。一个月后对比「打了回访电话的高危用户」和「没打回访电话的高危用户」的实际流失率差异这个差异就是模型的增量价值。如果没差异要么是话术不对要么是模型预测出的风险本来就不该用电话这种手段去干预。我自己的教训是A/B测试的对照组留10%到20%就够了不要因为觉得「明明知道他要走还不拦」心里过不去而把对照组设得太小太小了差异就不显著后面反而说不清模型到底有没有用。流失预测模型的价值不在AUC上在哪个数字上就是回访组的流失率比对照组低了多少个百分点。把这个数算清楚你的模型才算真正落地。做模型做到后面越来越觉得技术只占三成剩下七成是跟业务方对齐口径、盯数据质量、跟运营拆解话术。希望你上手的时候少走我走过的弯路——先把标签定义和切分方式钉死再回头调参顺序对了事情就成了一半。希望帮到你。本文还有配套的精品资源点击获取