APP新增用户与留存分析！

 

01 新增用户

如果大家看过咱们系列的第一篇文章：《数据扫盲（1）：我们常说的DAU、MAU是啥？》应该是知道这样一句话：

对数据基本功的扎实了解，是沟通的桥梁！

这句话是贯穿我们数据扫盲系列始终的，跟着新增用户我们举一个场景，大家可以再次深度感受一下这句话。

我们的运营同学为了推广app，去找渠道商进行合作，涉及到结算钱的时候，商量以新增用户为指标进行结算，但是对于新增用户的具体定义，大家发生了争执：

• 渠道商：只要用户在我们渠道的推广页面点击了产品下载按钮，就记作一次新增用户。
• 运营喵：那不成，点了按钮没下载那意义不大啊。咱们下载成功记作一次新增，且多次点击记作一次。
• 产品狗：错了错了，咱们app这么牛，至少也要启动一次记作一次，让他们体验下，要不然数据质量不大，不具备参考价值。
• 工程狮：都打住啊，你们这yy半天不行啊，不注册我们后台都没有数据。必须注册了才算新增用户。

面对这样的场景，我们很难去说对错，我们更关心的是彼此间对于数据指标如何达成共识！

那么新增到底指的是什么呢？

我们把新增用户进行说文解字般的拆解，新增=新+增。接下来我们需要明确两个问题：

Q1：什么是增？在哪个节点为增？

A1：一般来说，在用户与产品发生关系之前，往往会经历如下图所示路径：

用户通过不同的渠道衔接进入到渠道页（例如某度广告页，某企鹅广告页）；用户在渠道页面点击下载或者通过渠道页进入到应用商店下载；安装，启动应用，来到应用首页；触发相应的激活行为（不同业务激活行为不同，例如注册成功、购买商品、亦或是观看一次视频等等）。

理论上不同的节点，都是可以作为一次新增，这里呢，我总结一下不同节点作为新增的优劣势，以及适合的场景。

大家就可以根据表中总结的，结合自己公司业务选择适合自己的节点。

Q2:怎么判断是否为新？

A2：这个问题是由一个实例引入的，假设我们以安装启动这个节点作为增，一个用户下载了某app并安装启动，装了两天卸载了，又重新安装启动，此时他是否算作新增用户？这里，我们一般有两种判断方法：

1. 基于设备：用户第一次安装启动时，记录设备。再次安装则不记录。其中涉及的不同系统之间（ios，安卓，web）判断设备的门道，详情细节可见上一篇文章《再也不怕别人问我DAU和MAU了》其中关于user部分的介绍。
2. 基于账号关联。

以账号作为判断基准，和后台已有的账号进行比对，看以前是否存在此账号。

02 留存用户

本文提到的留存都是指的新增用户的留存，下不赘述。

首先我们来看一下友盟平台对于留存是怎么下定义的。

宋老湿还是给大家引入一个案例，来帮助大家理解定义。

案例还是一款悲催的app，上线第一天新增了100名用户，之后就再也没有获取新增用户。下面给出其上线七日的日活表：

我们由表可以得出MAU=100，这点如果有疑问，请查看数据扫盲系列文章一《再也不怕别人问我DAU和MAU呢~ 数据扫盲系列（1）》。

问题：如何计算新增用户七日日留存？

这里给出两个算法。

算法一：（第七天留存用户数/第一天新增用户数）*100%

算法二：（第二天~第七天去重后的留存用户数/第一天新增用户数）*100%

根据留存的定义，“某段时间内的新增用户，经过一段时间后，仍继续使用应用的，为留存用户”。从中可以提炼出留存用户是某段时间新增用户的子集。

就本题而言，上线第一天新增了用户100人且之后再没有新增用户，所以第一天之后几天的活跃用户都是第一天新增用户的子集,即第X日留存用户数=第X日活跃用户数，第一天的新增用户=第一天的活跃用户。

但是，如果没有“第一天新增100人后再无新增用户”的前提，则第X日留存用户数≠第X日活跃用户数，准确表述应为第X日留存用户数=第X日来自于第一天新增用户中的活跃用户。

这里有一点绕，我举一小例子帮助大家理解一下。

（假设5月份新增用户200，这200人在6月份启动过应用的有100人，7月份启动过应用的有80人，则6月份留存用户为100人，7月份留存用户为80人。）

那么采用哪一个算法呢？

如果您有心记得，宋老湿反复强调过：数据分析一定是基于业务的，是有目的（即留存用户这个数据指标的意义）。

目的一般来说，留存的计算与分析有以下目的：

1. 观测不同渠道带来用户的质量；
2. 版本更新后的新功能上线的效果反馈。（功能这一块，会涉及到用户关键行为的触发。属于精准留存的问题，后期文章我们会讲解）

此处我们以区分渠道质量来做讲解：

算法一

假设某app有两个获客渠道A和B，且都是1月1日上线，当日新增用户100名之后再无新增用户。已知两个渠道1月1日~1月7日每日的活跃用户的数量，用算法一【（第七天留存用户数/第一天新增用户数）*100%】计算分别得到两个七日留存率。

这里可能会有一些朋友会觉得，用算法一计算忽略了2日到6日的用户数据，这样计算得到数据不准确。其实不是这样的，我们获取了两个数据是为了进行数据对比，从对比中洞察业务爆破点。因为无论是渠道A还是渠道B，我们都只使用第一天和第七天的数据，同时忽略了2日到6日的数据，忽略的信息是一致的。

因为单一影响因素相同，所以采用算法一计算进行对比是相对公平合理的。

当然，即使这样，可能还会有一些朋友会问那有什么办法不忽略2日到6日的数据呢？

算法二

【第二天~第七天去重后的留存用户数/第一天新增用户数）*100%】这种计算方式就是把2日到6日之间的活跃用户计算在内，但是这样的计算方法是否适合用来评估渠道质量呢？

我们可以看下下图是关于渠道A和B七天日活用户的折线图，我们严格按照算法二计算会得出渠道A留存率高于渠道B，实际上我们由图可以看出渠道B的活跃用户曲线更接近于自然平缓下降，同时第七日的活跃用户也高于渠道A。综合来说渠道B的用户质量是高于渠道A。

所以用算法二来计算留存评估渠道质量是不ok的，究其原因，恰恰是引入第二日和第六日的数据，反而影响了结果的判断。

通过以上的案例，大家应该理解了两者的区别。

算法一我们可以称之为七日日留存，算法二为七日内留存。

当然，存在既有合理性，算法二并不是没有适用场景，针对一些用特定使用周期的app就更适合，例如某app是专注于周末轰趴，活跃用户大部分聚集在周六和周日，我们如果去计算工作日（周一至周五）任一天的新增用户七日日留存，会发现明显偏低于周末。

针对这种情况，我们只看第七天的日留存显然不能反应真实情况，反之，关心七日内的留存就更为真实可靠。

那么，宋老湿还是以友盟数据平台一组七日留存的表格，大家可以尝试看下友盟采用的是算法一还是算法二。

有些朋友可能有些摸不到头脑，有些朋友直觉可能觉得友盟用的是算法一。实际上，友盟平台计算方法和算法一很相似但有些许不同。我们暂且称之为算法三。

算法三

（第七天的留存用户数/第0天的新增用户）*100%。

这个第0天其实指的就是计算留存的当日，和算法一中的第一天指的是同一天。如上图所示，如果计算2018—08—01的七日日留存，则算法一中的第1天和算法三中的第0天都是指的08-01的新增用户数339人。再仔细看上图会发现，友盟统计时采用1天后，2天后对应就是算法一中的第二天与第三天。

那么友盟为什么采用算法三，这样计算有什么好处吗？希望大家动脑子想一下。

（这里给一个提示：和一周七天有关联）。

揭晓答案：这是因为采用算法三我们可以规避星期对数据的干扰。

举一个例子，2018-08-01是星期三，采用算法一的第七天则是08-07星期二，算法三则是七天后08-08星期三，这样同时用星期三的数据，就可以合理规避今日是周几对数据的干扰。

那么我们一共讲了三种算法，每种算法都有其存在的意义，具体的要根据自己公司业务进行选择，保证公司内部采用同一种标准即可。

这里，宋老湿给大家做一个表格进行总结，大家可以保存图片备用。

基于此，新增或和留存咱们是聊得差不多了。大家应该会有种毛塞顿开的感觉。

 

作者：宋老湿

来源：产品经理吐槽喵