用户流失率是指用户的流失数量与全部使用/消费产品(或服务)用户的数量的比例，是用户流失的定量表述，以及判断用户流失的主要指标，直接反映了产品的市场接受程度如何，以及运营工作的好坏。
–正文–
一般来说，这个指标用在“订阅型产品”的情形居多，如信息订阅类App“锤子阅读”、绝大多数的在线SaaS产品，甚至传统的牛奶订购。由于留住当前的用户要比获取新用户来的划算，所以预测流失率的目标在于：
预测用户将会在哪个时间点离开(在订阅期结束前)，在合适的时间点对这些用户施加影响，挽留他们，如通过短信、邮件或APP，利用超低价商品吸引回访或者专属优惠券等，这些策略对于一些流失用户是很有效的!
接下来，通过简单的统计学知识，介绍一种基于用户不活跃记录的用户流失预测模型。该模型在不使用机器学习算法的情况下，可以给出一个容易理解的用户流失预测，以便我们对将要离开的用户有一个相当准确的洞察。
用户活跃的操作性定义
在我们正式开始预测用户流失率之前，我们需要记录用户的历史活跃情况。做这个的目的在于，了解用户是否在使用我们的产品或服务。那么，问题就来了，用户的“活跃”该做怎样的操作性定义(即根据可观察、可测量、可操作的特征来界定变量含义的方法)?实际上，“用户活跃”的定义取决于你的业务背景，跟产品或者服务具体场景密切相关，不同类型的产品对“用户活跃”有不同的定义。
以新浪微舆情的“信息监测”为例，它是一款订阅型的社会化大数据产品，用户通过设置各种关键词组合来检索相关信息，然后选择邮件或者客户端订阅，通过自定义的接收频次来准时收取订阅信息。
对于这款大数据产品来说，“用户活跃”可以这样定义—如果一个用户是活跃的，那么，ta在指定时间段内(分析的时间单位取决于分析者对业务的理解，可以是天、周、月、季度或年)，应该包含如下付费、使用或者互动行为：
- 该用户对“信息监测”的订阅尚未过期;
- 该用户在web端或者移动端登录产品页面;
- 该用户使用了产品的部分或全部功能，如基于信息源或者地域的定向监测功能;
- 该用户在此期间产生了一定消费，如文本数据下载、订阅续费、定制报告等;
- 该用户在此期间对该产品有各种反馈，包括投诉。
…
对于这款产品来说，以月份为单位来分析用户行为是很有意义的—因为该产品最短的订阅期是一个月，最长的订阅期是一年。
一旦清晰的界定了“用户活跃”的定义，我们就可以用这些操作性定义来对每个月份的用户(不)活跃情况进行编码，利用二进制值(0,1)—假如在X月份，用户是活跃的，将ta的活跃值设定为1，否则设定为0。
建立“用户不活跃档案”
现在，对于每位用户，我们有了一个以月为单位的“活跃标记”，接下来我们以此为基础，建立起“用户不活跃档案”。这意味着，对于每个用户，笔者想对他们连续不活跃的月份数进行计数统计。
在这里，笔者选择了一年的“分析窗口”(也就是把12个月作为分析的时间范围)，将“活跃档案”和“不活跃档案”以表格的形式呈现—蓝色表单显示每位用户在各个月份上的活跃记录，绿色表单则显示用户的不活跃记录。根据用户在此时间段内可能出现的活跃情形，笔者枚举出3种典型用户，如下表所示：
用户A：该用户在刚进入“分析窗口”时是活跃的，然而在5月变得不活跃(也就是说，5月份是第一个不活跃的月份)。接下来，这个用户的不活跃状态持续到了12月，也就一直持续到了“分析窗口”的末尾。因此，从5月到12月，“用户不活跃档案”对用户连续不活跃的月份进行逐月累加的计数统计。
用户B：跟用户A一样，该用户刚开始也是活跃的。不同的是，该用户在3~6月期间是不活跃的，在7月仅维持了一个月的活跃状态， 接着在8月和9月又进入不活跃状态，最后在“分析窗口”的10月，11月和12月又回到活跃状态。在这种情况下，每当用户由不活跃状态返回活跃状态时，前面的不活跃月份计数需要重置。也就是说，当我们再次对该用户的连续不活跃月份进行计数时，需要重新从1开始计数，前面的不活跃月份计数不再累加。
用户C：与上述提及的两类用户不同，该用户刚进入“分析窗口”时，是不活跃的状态。这种情形的发生，可能是用户的订阅早已过期(最好在正式分析前排除这种情形，因为很难处理)，或者该用户在“分析窗口”开始前就是不活跃的。因为我们看不到“分析窗口”前的用户活跃情况，所以用户在此之前的活跃状态，我们是不了解的。鉴于此状况，我们对这些月份进行特殊的标记—使用-1标记用户C头几个不活跃的月份。该用户其他的不活跃情形，可以参照前面两类用户方式进行计数。
Note:后面绿色的表单，也就是“用户不活跃档案”，才是我们接下来建立用户流失模型的数据基础。
构建用户流失模型
有了上述的关于用户不活跃的操作性定义，我们就可以在“分析窗口”内(1月份到12月份)以月份为单位，对从0到12的连续不活跃月份数上的用户数量进行计数统计。
这个步骤可以通过数据透视表实现—通过聚合每个月、每个不活跃级别的用户数量。 如下表所示：
上表中，从列的方向上来看，每个单元格的数值表示每个月的连续不活跃X个月的用户的数量。举个例子来说，上表中第一个高亮数值(574)，代表1月份已经不活跃1个月的用户数量，该数值来自于前面12月份的4815个活跃用户。第二个高亮数值(425)表示在2月份已经连续不活跃2个月的用户数量—425来自于574(1月份不活跃1个月的用户数，它是2月份不活跃2个月的用户数的基数)。值得注意的是，第一行的0个连续不活跃月份数，其实表示的是基数中活跃用户的数量。
使用这些数据，我们可以计算出在“分析窗口”内，每个月连续不活跃月份数的用户占比情况。如下面的绿色表格所示：
上表中，高亮的数值(74%)表示2月份已经连续2个月不活跃的用户占比。该百分比是这样计算得到的：
想获得最具代表性的数值，由此可以对“分析窗口”的最末4个月(9月，10月，11月和12月)取平均值。我们可能没有足够的数据去计算这些平均值(比如10月份，11月份和12月份)—在这种情况下，我们取所有可用数值的平均值(用于计算平均值的数值区域以红色线框标记)：
计算用户流失概率
哈哈，如果你还在看这篇文章，那么恭喜你!我们将要探讨最激动人心的部分…在这部分，我们将用上一点统计学的小知识。让我们回顾一下本文的终极目标—计算各个连续不活跃月份数(0-12)下的用户流失概率。
也就是说，如果某个用户已经连续X个月不活跃，那么这个用户接下来将要流失的可能性有多大?从数学上来说，我们可以使出贝叶斯公式这个大杀器来计算用户流失率。贝叶斯公式尽管是一个数学公式，但它的原理不要数字也能明了。如果，你看到一个人总是做一些好事，则那个人多半会是一个好人。该数学公式包含着朴素的真理：
在这里，A和B都代表事件(Event)，同时P(B)≠0。P(A)和P(B) 分别代表A和B的先验概率或边缘概率。之所以称为”先验”是因为它不考虑任何A(B)方面的因素。P(A|B)是已知B发生后A的条件概率，也由于得自B的取值而被称作A的后验概率。P(B|A)是已知A发生后B的条件概率，也由于得自A的取值而被称作B的后验概率。
在本案例中，对应的公式如下所示：
然并卵，上面公式里有一项是没啥意义的—P(连续X个月不活跃|流失)，它的含义是“在已经流失的情况下，连续X个月不活跃的概率“。试想一下，假如你已经流失掉了，你不可能是一个不活跃的状态，这个概率值是么有啥业务意义的。鉴于此种情形，笔者果断抛弃这一项(谨记!)。由此，我们得到了一个终极版的流失率计算公式：
接下来，让我们看看公式右端的两项(分子和分母)，然后计算它们在每个不活跃月份上的数值，进而得到我们想要的用户流失概率值(注意，它是一个条件概率值，也就是在连续不活跃X个月的情况下的用户流失概率)。
先说说分母P(连续X个月不活跃)，之前已经计算过它们—也就是“分析窗口”最后4个月占比平均值：
P(1) = 19%
P(2) = 81%
P(3) = 89%
P(4) = 92%
P(5) = 93%
P(6) = 95%
P(7) = 96%
P(8) = 97%
…
接下来，我们再来通过例子求解分子P(流失)。首先，1个月不活跃的用户的流失概率P(C1)是多少呢?对于这些将要流失的用户，他们将要连续性的不活跃的月份数已经在我们所考虑的集合之内了，换言之，这些用户将要不活跃的月份数为1个月，2个月，3个月，…，。因而，我们这样定义已经不活跃1个月的用户的流失概率P(C1)：
现在， 以同样的方式， 持续2个月不活跃的用户的 P(流失) ，也就是P(C2)是多少呢?对于这些将要流失的用户，他们将要持续性的不活跃，2个月，3个月，4个月，…，12个月。因而，我们这样定义已经连续不活跃2个月的用户的流失概率P(C2)：
通过归纳和演绎，我们以同样的方式来计算每个不活跃月份的用户流失概率：
在这里，n是连续不活跃月份数的极限值，而我们发现，这个概率是稳定的。从上面的表单里可以到，这个发生在第7个连续的月份，这里的概率值维持在95~96%。
简化起见，我们假设，在连续月份上不活跃是相互独立的事件。此时， P(A ∩ B )= P(A)* P(B)。因而，我们可以采用如下的公式：
现在，我们已经算出了每个不活跃月份概率对应的分子和分母，那我们就可以启动最后一步—算出每个各个连续不活跃月份数的用户流失概率。先前我们已经讨论过了，n的值为7。
…
最终的计算结果如下表所示：
请注意，活跃用户(也就是第一行连续0个月不活跃的情形)的流失率由P(1) Ⅹ P(2) Ⅹ P(3) Ⅹ P(4) Ⅹ … Ⅹ P(7)计算得出。这里我们并没有除以任何值，这是因为—当用户处于活跃状态时， P(连续0个月不活跃)为1。
最后，我们还可用一条流失率曲线来直观的反映流失率的变化情况，由此决定对非活跃用户进行挽留操作的最佳时机，该曲线所下图所示：
本文中并没有提供该模型批量化使用的具体执行细节，假如你理解了这个模型构建的逻辑，那么你可以使用SQL、Python，甚至是Excel来实现它。
此外，在实践中，这个模型最好是分不同的用户群进行运行。文中仅仅在某一类用户上运行，然而，根据不同的标准来划分用户群体会对实际业务更有意义。比如，你可以根据用户价值进行划分，然后对每个用户子群体进行用户流失预测。
当然，文中所讲的只是在月份的尺度上进行用户流失分析，但是，对于很多业务场景，更细粒度的分析视角可能更有意义，比如按周和按天。
案例分析：漏斗模型与流失率优化
例如在App使用的每个环节中都可能有用户流失，每一步都有流失的可能性，找到流失的关键节点对每个运营人员都至关重要！所以建立使用漏斗模型，是你必不可少的技能之一。
漏斗模型是一个看似简单的评判产品健康度的数据工具，简单来说，就是通过产品每一个设计步骤的数据反馈得出产品的运行情况，然后通过各阶段的具体分析改善产品的设计，提升产品的用户体验。
漏斗模型普遍适用于互联网产品：网站、APP、客户端，用户从刚进入到完成产品经理设计的产品目标时，中间的步骤肯定会发生损耗，在很多时候，这个损耗还很大。比如，用户进入一家电商网站，到浏览商品，到把商品放入购物车，最后到支付，每一个环节都有很多的用户流失损耗，没有产品能够做到100%的转化。
今天我们通过案例来讲一下如何通过U-App建立使用漏斗模型。
第一步：集成U-App自定义事件统计，收集数据；
第二步：根据产品预设操作顺序完成漏斗设置；
第三步：次日可在[功能使用]-[事件转化率]中可查看漏斗数据，能够清楚看见每个步骤的转化情况。
操作时应注意：
1.数据异常—如果出现某步没有数据或数据量少的情况，应检查你的漏斗设置是否合理，如用户没有按既定路径点击按钮，漏斗就会出现数据异常的情况。以此也可以判断产品经理设计的路径是否合理。
2.漏斗优化—用户从点击到完成转化的路径可以有多种，你可以根据多种组合路径分别设置漏斗模型，由此对比不同漏斗的转化情况，对产品优化和后续运营提供数据支撑。
3.自由切换— 事件转化率页面可实现多个漏斗间切换、交叉选择版本和渠道、选择查看时段、查看数据类型的功能。
3、举个电商App的小栗子
电商应用如何通过漏斗模型进行产品优化？
如图可发现：支付到完成交易的转化率是95.2%，订单到支付的转化率是83.3%，这两步的转化率已经比较高。而购物车到订单的转化率69.4%，相对较低。
此时应该具体分析下导致问题出现的原因，例如：UI设计、交互体验、功能设置、产品性能等多方位进行分析，找到问题所在，从而进行产品优化。
一般情况下，电商类App可能造成用户流失的原因：
首页：首页的流失率往往较高，可能是用户被投放的广告吸引，进入后发现与预期严重不合，造成流失。
商品列表：客户通过检索或推荐到列表页面但没找到合适的产品，流失会明显提高。（这时候就需要大数据的力量了！）
商品详情页：如果商品的详细描述与列表页图片不符或者评价过低，流失会明显提高。
购物车：加入购物车不付款的情况也多有发生。比如，我经常将喜欢的商品加入购物车，期待有人帮我清空它（zuomeng！）。此类用户有较强的购买需求，因此，可通过圈定已加入购物车用户群体，进行精准推送促销信息，刺激用户完成购买。
生成订单：生成订单页面步骤过多都可能导致流失。例如，我前两天在某电商网站买书，从下单到完成付款需要6步，每一步都会造成用户流失，优化购物流程是至关重要的。
付款：这个步骤的流失可能与App内付款方式、支持平台等原因有关，尽量给客户多些选择。
在运用漏斗模型进行运营分析的时候，我们最需要注意的就是：关键路径的转化率。确定整个流程的设计是否合理，进行优化。通过漏斗模型，了解用户真正需求，为用户提供更好优质的服务和体验。
