时间: 2021-07-30 09:14:45 人气: 27 评论: 0
笔者基于自己工作中遇到的一些产品数据分析问题，与大家分享其对于数据分析的见解与感悟。期望以简单易懂的文字让产品数据分析小白，能通过改文章对数据分析有一定的了解。
一直想把产品工作中遇到的数据分析问题做一个系统的总结，但因为种种原因一直没有下笔。前些天详细梳理了一番，打算通过几篇文章将产品工作中的“数据分析”说清楚，文章尽量用通俗易懂的言语阐述。
对于这些文章，我心里有一个小目标：让一个毫无基础的人，看了这几篇文章也能对产品的数据分析有一个初步的了解。
废话不多说，我们开始吧！
宏观指标**从：新增、卸载、留存、活跃，四个维度来进行介绍，当然每个维度又有具体的细分。
宏观指标通常出现在数据面板（Dashboard）中，用于日常数据的监测，来判断产品的异常与否。
因为文章篇幅限制，本篇文章只**介绍前两个指标：『新增』『卸载』，剩余的部分**在接下来的文章里面进行阐述。
在正式介绍数据指标之前，我们要明确一个概念：用户数量统计的基本单位。
实际上，目前市面上常见的数据数据统计平台，还没有能力真正识别一个真正的人。
回顾一下国家是怎么统计人口的：是为每个人分配唯一的一个身份编号，这个编号不仅仅保存在户口本与身份证上，还保留在国家的统计局里。
但是，如果一个人有两个不同的身份证号，其实从国家的角度来看，就是完全独立的两个人。
对于产品统计平台来说，也是如此。
数据统计平台也是通过为用户分配唯一编号的形式进行确认的，目前常见的方式有三种：
不同的应用对于用户单位的定义也不尽相同：对于拥有账号体系的应用，一个用户特指注册的账号，但是对于没有账号体系的应用，多数使用的是应用id作为用户数量的基本单位，而设备id通常作为补充。
这里补充一点：接下来所有的案例均以应用id作为基本单位进行阐述。
在明确了用户数量的『基本单位』后，我们正式进入产品数据核心指标的阐述部分。
所谓的核心指标指的是：能够衡量产品状态的数据标准。
通过这些指标就能很直观的判断：产品整体表现的好与坏，局部改动的得与失。
其中核心指标主要分为两类：宏观指标与微观/功能指标。
宏观指标主要衡量产品的整体状况，而微观指标则能够精准的呈现产品中某些功能的使用情况。
为了方便，我们先凭空造出一个App，名为：示例App。
接下来所有的数据指标都来源于『示例App』。
新增顾名思义，指的是：没有使用过示例App的用户。
如果这用户开始使用了，那么该用户便是示例App的一个新增用户。
如果从职责划分的角度，新增指标更多的属于运营指标。因为产品功能上的改动，往往对新增数据的影响不大。新用户的获取属于流量获取行为，更多的的归因于宣传活动、广告投放、产品ASO的优化等。
如果笼统的说新增这个指标，上面那段文字的描述就已经足够了，但是如果你想细致的了解，那可以从以下几个维度进行细分：
传统行业中的新增用户很好定义——就是个体的人。
例如：某个餐馆开张，第一天来了100个顾客，那么这一天的新增用户就是100人。
但是对于手机App来说，这个维度就显得有些粗了，举个几个例子：
或许看完了以上四个问题，你心中充满了困惑，这里建议你再重新看一次『用户数量的基本单位』的阐述——如果我们以App id为基本单位，则一切以App的时机数量为准。
所以，前两个问题的答案就迎刃而解。
对于第三个问题，用户卸载了App又进行了重装，那么这个用户还算不算新增用户？
这里给出的答案：依然是新增用户。
举个例子，『员工甲』在自己的『A公司』办理了离职手续，几个月后又重新入职，那么对于A公司来说，员工甲算不算是公司新人呢？
原则上肯定是公司新人，虽然之前员工甲对于A公司爱过、痛过，但毕竟现在是重新来过！
对于最后一个问题：升级的用户，对于新版本来说算不算是新用户？
一般来讲，应该不算是新用户的。
接着上面的案例说：员工甲在A公司努力工作，职位升了，对于新到的部分来说，可能算是新面孔，但是对于公司来讲，肯定不算是新员工了。
当然，上述文字只是说了最一般的情况。其实最终对于新增单位的定义还要看具体数据统计平台自己的定义，至于关于数据统计平台的阐述，这就是后话了。
定义完了新增的基本单位，接下来要说新增的触发时机了。
发生了什么行为的用户算作是新增用户呢？
这里有两个关键的操作：安装与首次打开。
一般情况下，还是默认为：只有发生了首次打开的事件才**被认为是有效新增。因为只有用户打开了示例App，才能体验示例App的提供的服务（功能或内容），同样只是安装但是一直没有打开，那基本上等同于无效安装。
继续以员工甲与A公司为例：如果员工甲在A公司只是提交了入职材料，但是一直没有来公司上班。那么，对于A公司来说，员工甲基本上算是无效员工，只有员工甲为A公司真正工作了、服务了，这样的员工才算是一个合格的员工。
所以，我们一般情况下定义的新增用户，指的是：安装并且打开过示例App的用户。
如果按照时间范围这个维度来划分新增用户，一般可以分为『单位时间新增』与『累计新增』。
单位时间新增又可以分为：每日新增、每周新增、每月新增、每季……
当然最长用的还是每日新增。
最开始提到过：新增是衡量运营同学工作的核心指标之一。
这里要更加精确一些：『每日新增』才是衡量运营同学工作非常的核心指标。
至于累计新增这个指标，可能对外提到的**多一些，例如：全中国一共有XXX用户用过我们的软件这样的描述，无论对于吸引投资还是展示公司的形象，都是挺管用的。
一直再考虑要不要加上『卸载』这么一个指标，纠结的原因主要在于：
首先卸载是衡量一个产品好与坏非常直观的指标，所以非常的有意义；
但是，卸载这个指标非常的难以统计到，以至于市面上主流的统计平台只有Google的Firebase统计平台才能获取。但是，国内的互联网环境你们也懂，很多国内的Android系统内置的Google服务被阉割了。所以，主要面向国内市场的互联网公司根本就拿不到。
但是，抱着内心中仅存的一丝幻想：万一将来Google又回来了呢？
所以关于卸载仍然要说上几句。
卸载指标从时间连续性上可以分为两个类型：『卸载率』与『卸载曲线』。
卸载率指的是：截止到某一时刻，某批新增用户中，卸载用户的占比。
而卸载曲线则是：卸载率在时间这个维度上的动态变化。
再次重申一下『卸载率』的定义：
某一批的新增用户中，截止到某一时刻，卸载用户占据新增用户的比例。
举个例子：如果今天的新增用户有100人，这100个人中，有30人在首次打开示例App后的24小时内，把示例App卸载了。那么可以定义：今天示例App的24小时卸载率为30% 。
其实单纯的看卸载率所获取的信息是远远不够的。
因为很多时候，我们不仅仅要看某一刻的卸载率，还要观测一段时间内，示例App的卸载率的变化，所以通常情况下，我们更多的是查看「长期卸载率」。
长期卸载率指的是：在一段时间内（一般以天为单位），每天前XX分钟/小时的卸载率的集合，如下图所示：
上面两条曲线分别代表：对照组与实验组在15天的时间里，前24小时的卸载率的变化曲线。
给人最直观的感受是：实验组的卸载率显著低于对照组。
所以，很容易得出结论：实验组要好于对照组。
虽然结论很容易得出，但是真的就这样结束了吗？
试想这样一个场景：实验组和对照组唯一的区别就是实验组砍掉了A功能。
通过数据可以看出：砍掉功能A后，卸载率降低了，但是我们真的能斩钉截铁的说用户不喜欢功能A吗？
如果是因为功能A的存在，导致了用户安装1小时之后**有极大的概率出现严重的bug，而用户实际上非常喜欢功能A，只是因为忍受不了这个bug而被迫进行卸载，那么这个时候仅仅通过长期卸载率是无法归结出正确的原因的。
更确切的说：如果App从被打开到使用了1个小时的过程中，实验组的卸载率要远高于对照组。但是1个小时之后，对照组的卸载率才开始反**实验组。
所以，这个时候只盯着固定时刻的卸载率，很容易导致我们的误判。如果这个时候能够结合着『卸载曲线』去分析，就**避免这样的问题。
关于卸载曲线，纯粹用文字解释可能比较麻烦，所以先给大家看一个示例图：
这张图展示的就是：示例App的卸载曲线。
现在我们可以给卸载曲线下一个定义：指的是在指定的时间段内（一般以分钟为单位），每个时刻的卸载用户数占新增用户数的比例的集合。
从图中我们可以看到：无论是实验组，还是对照组，其卸载曲线在前几分钟内急剧的上升，然后有急剧的回落，最终逐渐的平稳，直至趋向于一条直线。
从卸载曲线的示意图中，我们可以明显的看出：实验组的卸载峰值高度明显低于对照组，而且峰值时间也要比对照组晚一些。
这说明：实验组确实要比对照组好很多，那么可以进一步证明A功能确实不受用户的待见。
而实际上的卸载曲线的峰值**更快与更高，因为一个普通的新用户对于一个陌生App的耐受程度是非常低的。在使用App的前几分钟内，如果觉得不爽，那就**毫不犹豫的删除掉，这关键的几分钟也被称之为：新手窗口期。
这意味着在设计产品的时候，要尽量让用户在刚打开App的时候，就能看到该App的特色/优势。如果将这些功能藏着掖着，待用户自己发掘，结果很有可能是这些功能根本没有展示的机**，就胎死腹中！
当然了，能不能把两张图结合在一起来看呢？
或许『累计卸载率』能满足这样的要求。
累计卸载率指的是：在指定的时间段内（一般时间范围为1天），单位时刻（一般单位为分）的累计卸载率。
如下图所示：
每个节点代表着截止到某一时刻为止，总的卸载率。
而某段时间内卸载率的变化趋势/斜率，则代表着：这段时间内用户的卸载速度。
累计卸载率既能体现出卸载的过程，又能直观的看到每个时间节点的累计卸载率。
这篇比较详细的说明了『统计单位』『宏观指标』『新增』『卸载』的概念。
虽然种类不多，但深究起来，也足以值得细细品味，不再多说，下期见！
作者：MING，个人公众号：MING的大航海，知乎专栏：产品见知录
本文由 @MING 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
