前面谈到了客户细分，这里说下流失分析吧
流失分析是客户细分大框架里面的一部分最重要的标签。切割用户有很多角度（例如性别、年龄等自然属性；成长状况等生命周期属性；贡献情况等价值属性；问题倾向等风险属性；消费特性等行为属性），我觉得最重要的特征是价值和风险，也就是说切割用户的头两刀应该是分开不同价值、风险倾向的用户
流失分析是获得用户风险倾向的分析，分析的结果是按照业务定义的风险类型，给用户打上不同的风险分值和风险分群
有了客户细分模型后，我们可以尝试在做更复杂模型是，进行模型的交叉，也就是说把细分等一些初等模型的结果成为重要模型的输入变量，这有利于提高精确度，最重要的是给模型的解释和实施代理很大的帮助（试想下，我们知道一个人有问题，但如果知道了这个人的细分标签，就意味着我们可以动手拯救他，而不是卧在桥头看水流）
说说流失分析的过程吧
step1-流失的界定：流失的界定是整个流失分析的重要环节，需要结合业务目的和数据状况界定流失（一般来说业务方界定的流失和技术上界定的流失不一致）。如何才算好的流失界定呢个
 1、有业务含义，围绕着用户的业务目的来界定流失，例如：目的是促成用户消费，则xx天前有消费，当前没有消费的界定为流失；目的是促成用户提升价值，曾xx天前比当前消费降低50%以上的用户界定为流失
 2、有稳定性：可以引入流动性分析，看用户在什么样的流失界定下，自然回复率低，也就是说如果我们不管他，他一般就挂了
 3、操作性：回忆下人生（其实我也很年轻，那就回忆别人的吧，呵呵），最大的流失莫过于失去生命，如果到用户死了后再抢救有效果么？？呵呵，所以我们界定的用户流失，一定是在发现流失后，有可以行动的方案
 3、churn级别设定：详细分开，用户有几种阶段（好-有点问题-有问题-问题过大），我们需要在数据上给每个用户在churn中打一个级别，这对于模型学习有意义，最终使用好用户和有问题的用户对比建模，而不是用有点问题和问题过大的用户。这样有些复杂，但我对比尝试过，虽然对模型准确率没太大提升，但对模型的解释性有帮助，在稳定性上也会好一些吧
 5、可以考虑定义多个流失，分别做模型：有多少种业务情况，就有多少种流失，最终可以考虑再做一个大模型，把所有的流失再封装一层
step2-变量列表：重复我个人的观点，变量列表的设计是以了解业务为基础的，每个变量都应该有业务猜测和原因。常把“变量是否有效要模型结果说了算”挂在嘴边的人，不知道技术如何，模型应用上肯定是傻子，尝试着说服他们更多的关注业务吧
 1、尽量选择已有的变量，会使得变量准备的工作量小
 2、按照业务内容把变量分类，综合考虑业务需要和计算量选择合适的变量；同时可以衍生一些从数据加工角度看冗余，但建模需要的变量（例如把入网时间->在网月份数）
 3、确认变量获取的时间长度是否足够：对于消费总量的纯增量数据，只要系统最近没有大割接问题都不大；对于用户等级等快照变量，要想回溯快照可不是件容易的事情，要想好哦
 4、已有的模型结果变量，可以作为准备变量交叉参与模型
step3-数据加工和检验：检验比加工更重要
 1、数据加工不说了，有些用数据库，有人用c，有人用sas或climenting挖掘工具处理数据，都可以，没有哪个好，只有熟不熟
 2、数据检验非常重要（会决定项目的成败），分成3类：单指标验证（每个指标的数据分布状况）、多指标交叉验证（指标间的大小、量级、加和等关系，需要穷举）、时间序列检验（在时间上的稳定性）--我曾经写了大约2000行代码的sas数据检验程序，可以配置的生成html报告，感觉对效率提升很大
 3、调整和反馈：这个看起来小事，实际做起来占用50%以上的数据准备时间，一般第一轮准备的变量都有问题，反馈几轮后数据加工的逻辑问题会减少，但越多会发现数据准备人员和建模人员对变量的理解不一致，没办法不熟悉模型的数据加工人员是要交学费的，只有2个选择-放弃变量或重新获取（有些重新获取是要改动底层的），抉择吧，呵呵
 4、问题数据记录：数据检验后，经常发现boss数据源问题，例如银行中发现身份证年龄不足、通信行业发现boss计费或调涨错误，呵呵，记下来，考虑对哪些样本从建模和打分中排除（也能作为模型不准的时候打马虎眼的说辞，试试看？？）
step-好好睡个觉，呵呵以上过程已经占用了建模60%以上的工作量（我今天也困了，改天继续）

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8739744/viewspace-628021/，如需转载，请注明出处，否则将追究法律责任。