一、 活跃用户
先给出活跃用户的定义：能被统计平台检测到的APP——简单的来说，就是活着的App。
『活跃用户』可以说是产品最息息相关的数据指标，因为只有活着才意味着App真的有被使用，这样的状态才有可能为App所属的公司产生价值。
关于活跃用户有三个重要的概念：日/月活跃、主/被动活跃、新/老用户。
『日活用户』与『月活用户』唯一的区别在于：划分的时间单位不一样。所以，这个小节重点阐述日活用户。
补充一下，日活跃用户与月活跃用户的简称分别：是日活与月活，英文简称DAU与MAU。
日活跃用户指的是：每天能够被数据平台监控到的App，如下图所示：
大家可以看到：示例App在头几天的日活波动比较大，但是在经历了一段时期的下滑之后，慢慢地回升并最终趋向了平稳。
在阐述主动活跃用户与被动活跃用户之前，先举一个例子：
第一天假设100人安装并打开了示例App，第一天结束之后，有50人卸载了示例App。
第二天在剩余的50个用户中，有5人手机关机，5人使用后台清理程序将示例App进行了后台清空，剩下的40人收到了示例App的推送通知，其中30人打开了示例App进行了使用。
虽然看完上面的文字你会有些晕，但是用于解释『主动活跃用户』与『被动活跃用户』却是一个极好的案例。
主动活跃用户简称主活，指的是：那些被打开过的App。
所以，第一天示例App的主活为100，第二天为30，同样的这部分用户也是价值最大的。
被动活跃用户又称活跃用户，是：包含了『主动活跃用户』在内的所有活跃用户——只要没有被系统杀死的App都是被动活跃。所以，只要那些还能收到通知的用户，都算作是被动活跃用户。
因此，示例App的第一天被动活跃为100，第二天的被动活跃用户为40。
其实在刚才的案例中，你也发现了：新增用户也被归为活跃用户。
这是因为新增用户也打开（使用）了示例APP，所以符合活跃用户的定义。那我们如何区分活跃用户中的新老用户呢？
对于新老用户的划分，没有一个统一的标准，目前常用的有两个划分依据：
两个划分没有优劣之分，每个产品按照自己的具体情况来进行统计。
一般来说，『24小时新用户』更加的准确，但是统计起来也相对比较麻烦；『自然日新用户』则相反，统计起来比较简单，但是在精确度上打了折扣。
最后需要强调的一点是：『活跃用户』与『新增用户』是两个相对独立的概念——即便没有新增，活跃也能单独的存在（老用户）。
这与前面提到的『卸载』，以及接下来要说的『留存』有着很大的不同，因为卸载和留存只有在新增用户的前提下，才有存在的意义。
二、 留存
在说完了『新增』『卸载』『活跃』之后，有关『留存』的很多概念理解起来就会容易很多，原因是：『留存』于上述的三个概念存在着千丝万缕的关系。
虽然从字面上觉得留存二字很好理解，但是，在实际的应用中，哪怕上述三个概念有一个没有明白，都很有可能在这个章节中云里雾里。所以，再有了这个预设后，请仔细浏览下面的阐述。
留存指的是：一批新增用户中，在指定的时间段内，没有卸载的用户。
所以，新增、卸载、留存的关系可用如下关系式表达：
新增 = 卸载 + 留存
《宏观数据指标简介(上)》 中提到过这么一句话：卸载是衡量一个产品好与坏非常直观的指标，所以非常的有意义。
可由于卸载的用户数非常难以统计到，所以根据上述公式，真正的留存也难以统计到的。但是，留存并不会因为它难以被真实统计到而被提之甚少，相反，它可能是产品数据中，几个频次出现最高的数据指标之一。
原因是：在实际的统计分析中，我们会用『活跃用户』替代『留存用户』。
在解释具体的原因之前，得先引入一个新的概念——静默用户，指的是：那些没有被卸载，同时也无法向统计平台发送事件的App。
例如：被手机清理程序杀死的App；关机状态下，手机里面的App……
所以，关于留存用户又可以通过下面的公式来表示：
留存用户=活跃用户+静默用户
讲到这里，使用活跃用户替代留存用户的原因就很明朗了：数据统计平台只能统计到活着的用户！
最后用一句话总结实际工作中的使用的留存用户：一批新增用户中，在指定的时间范围内，依然可以被数据平台统计到的App，被称之为留存用户。
接下来的文字描述中，如果对于『留存用户』没有特殊说明，均是指可以被数据统计平台统计到的App（除去静默用户）。
通常我们会用『留存率』这个指标来表示留存的好坏，常用的留存指标有：24小时留存、次日留存率、7日留存率、15天留存率、30日留存率。
这里重点要强调：『24小时留存率』与『次日留存率』
24小时留存率指的是：一批新增用户中，从首次打开示例App的时刻算起，24小时过后，依然能被数据统计平台统计到用户数量占据新增用户数量的百分比。例如第一天的新增用户为100人，这100人里面，在安装了24小时的那一刻，还能被统计平台统计到30人，那么这批新增用户的24小时留存率为30%。
而次日留存率则表示：第一天的新增用户中，在第二天依然能被数据统计平台统计到的用户。
例如：第一天的新增用户为100人，如果过了第一天24:00，还剩下50人，那么次日留存率为50%。
如果笼统来看，可能会觉得「24小时留存率」与「次日留存率」貌似没有什么太大的差别。但是如果仔细琢磨一番，两者的区别不是一般的大。
接下来继续以示例举证：
假设对于示例App来说，今天的00:00:00 — 23:59:58这个时间段一个新增用户都没有，在23:59:59这一刻瞬间增加了100个用户。
这批用户中，从明天的00:00:01开始发生卸载行为，并在明天的23:59:58这一刻刚好全部卸载。也就说，在明天的23:59:58这一刻，今天的100个用户一个都没有剩下。
那么，这100个用户中，次日留存率为100%，而24H留存率为0。
因为次日留存率的时间间隔为自然日，而24小时留存率的时间间隔是实打实的24小时。
至于「周留存」「15天留存」「30天留存」其定义跟「次日留存」是一样的，只是时间间隔由自然日变成了自然7天，自然15天，自然30天……
在「卸载」部分提到过：目前面向国内的App非常难以获得「卸载率」这么一个核心指标，所以就导致了绝大多数情况下，相关的从业人员只能通过「留存率」来评判一个产品的好与坏。
下面是一张常见的产品留存率的示意图：
大家可以看到：产品的留存率在头几天急剧的下降，后面几天留存率基本上不再有太大的变化。（当然，具体的原因就不再解释了。）
而蓝色部分的面积就可以代表：这些天累积的留存用户。
别小看了『累计留存用户』这个词汇，这个指标直接决定了示例App的生死。因为只有留下来的用户越多，示例App才有能挣更多的钱，反之，如果累计留存用户越少，那么，示例App所属的公司可能再也熬不多互联网的寒冬了。
所以，越早的知道累计留存用户，越有利于及时的做出调整，赢得更多的生存空间。
但是，如上图所示：如果通过第一天的留存率，就能预测出未来几天甚至是十几天的累计留存用户。那对于任何一个App来说，都是一件意义重大的事情，而留存系数刚好可以解决这个问题。
所谓的『留存系数』指的是：对已有的App的留存率进行积分运算，得到一个比较稳定的积分公式。
以上图为例，通过Excel的预测函数，可以推出目前示例App的『留存系数』为
y = 0.0001×4 – 0.0037×3 + 0.0478×2 – 0.2526x + 0.4826
所以，有了留存系数，我们只需要知道第一天的留存率，就能大概的预测出未来几天示例App的留存情况了。
留存存活率指的是：一批新增用户中，留存的用户中（这里特指没有卸载的用户）活跃用户的占比，主要用于衡量示例App的存活能力。
简单来说，每一款App都希望被用户一直使用着，哪怕能够偷偷摸摸在后台苟且也是一件值得庆幸的事情。因为只要活着，就有希望！
但是，残酷的事实是：现在手机对于App的管理越来越严苛，一旦示例App放入后台，那么其存活的可能性就变得极低！在这种情况下，“如何保证示例App的存活率？”，就成了一件十分头疼的事情。
常见的保活方式有两种：
至于两种方案的好坏，这里暂不评价。但是，留存存活率就是衡量上保活方案关键指标，在给出『留存存活率』的公式之前，我们再次回忆一下：新增、卸载、留存、活跃之间的关系：
新增用户 = 留存用户+卸载用户
留存用户 = 活跃用户+静默用户
至于留存存活率可用如下公式表示：
留存存活率=活跃/(新增-卸载)
不要小看存活这个能力，因为很多应用被打开的几率非常低。想想自己的手机里，是不是有很多App常年吃灰，例如：计算器。
如果一个App被安装后，再也没有存活的机会，其实跟被卸载了也没什么区别。所以，对于这些低频次的App，它所能做的就是努力的活下去。人生不易，App亦是如此！
三、小结
终于把『产品宏观数据指标』做了一个结尾，本来想对这篇文章做个精简，没想到修改下来，又多出了2000多字，不过好歹算是把该说的都说完了。
对于没有接触过产品数据分析的同学来说，这几篇文章读起来会比较累。因为每篇文章都牵扯到了很多概念，而且所有的观点与陈述，也仅仅是自己的一家之言，存在着很大的局限性甚至是错误，但对于仅仅想入门了解的话，已经是足够了~。
来源：MING的大航海
