产品数据分析的指标（产品经理要懂的数据分析）

编辑导语：在产品经理的工作中，要结合具体业务、数据分析、数据工程这三个方面来进行数据分析，而其中所涉及的步骤工具又可以分为6个模块。本文作者对其中的一个模块——指标建模进行分析阐述，一起来看一下吧。

产品经理所要进行的数据分析要结合3个方面来进行——具体业务、数据分析、数据工程，而整个数据分析所涉及的步骤工具等又可以分为6个模块——指标建模、数据工具、数据处理、数据分析基础、数据分析进阶、数据采集。今天我们来讲一下指标建模模块。

一、指标建模概述

笔者先提出几个问题作为本文的引子——什么是数据指标？常用的数据指标有哪些？它们是怎么定义的？日常工作中查看这些指标会碰到哪些坑？如何选择数据指标？选择数据指标会遇到哪些坑呢？

选好数据指标的常用方法论：

如果老板问到：“刚上线的社区产品，最近表现如何？”

新人产品：“很不错——日活每天都在涨，新增也很多。”

资深产品：“现状堪忧——日活按设备数看一直在涨，但如果按注册用户数看并不乐观。新增用户转化成注册用户的只有20%，说明我们社区现在还没有促使用户注册的动机。”

三个月后，老板想知道是否要开始推广？

新人产品：“最近日活平稳，新增用户减少，要不要推广拿不准。”——表现平平

资深产品：“最近日活虽然上涨趋势不大，但：1. 用户人均发帖量相比刚上线时翻了一番，2. 用户间的好友密度月环比上涨30%，我觉得社区氛围已经形成，3. 这个从新用户次日留存由上个月的35%增长到50%也能得到验证。因此，认为可以开始大规模推广。”——十分靠谱

二、认识常见的数据指标

什么是数据指标？即对当前业务有参考价值的统计数据。进一步说明，当前业务 有价值——不是所有的数据都叫指标，与当前业务无关的，也意义不大；可统计——数据不是凭空产生的，不能脱离现实。

举一个直白的小例子，老板为了提高自己小卖部的营业额搞了促销活动，为了衡量促销效果，他首先记录了一天中小卖部门口的路过人数为3，进店人数为2，购买人数为1，这些即是统计数据（可被观测、统计、记录）；随后计算出进店率为67%，购买率为50%，这就是对业务有参考价值的数据（衡量活动是否有效）。

常见的数据指标有哪些？即如何量化“谁干了什么，结果怎样”这句话，谁——用户数据，干了什么——行为数据，结果怎样——业务数据。

1. DAU/MAU

DAU/MAU=Daily/Monthly Active User

1）理解Daily/Monthly

2）理解Active

方法一：数据统计系统的定义

基于事件上报判定活跃：有事件上报->该用户活跃。

tips：上报可能有坑——假定了事件上报一定来自用户主动操作；谨防活跃暴增，其他数据并无显著增加的情况。

预制报表的统计系统（友盟、百度统计、GA、……）都是基于事件上报进行统计，其统计逻辑是：今天上报过事件（->用户进行了主动操作）->这个用户是活跃的。

然而有时上报并不说明用户的真实行为，如手机收到PUSH后上报事件，这属于后台回报消息，并非用户行为。

这个坑的终极来源可能是运营一周前向RD提出需求：“我要统计发下去的PUSH，的指导有多少条PUSH是到达了用户设备上的，不然无法优化推送转化。”RD采用如下解决方案：“我在后台给你写一个Service，APP收到PUSH的时候，我就给友盟上报一个事件说我收到了。”

方法二：业务上的定义

基于关键事件上报：用户执行了关键事件->该用户活跃。

tips：存在维护成本——需不断维护日活事件列表；存在沟通成本——团队内外对[活跃]的认知需统一。

这需要制作日活事件列表，定义哪些事件需要上报。比如：

3）理解User

认人：每位注册用户一个唯一ID，但未登录的用户会被漏掉。

具体操作：给每位用户一个唯一的专属ID，只适合强注册/登录环境，用户数=访问过服务的ID数。

认设备：每台设备一串唯一标识符，但无法对对应设备背后的用户。

具体操作：在网页cookie中买下一段长随机字符串，作为设备唯一标识符，用户数=访问过服务的设备数。

关于到底是认人还是认设备，笔者总结方法如下：

2. 如何定义新增

每个人都在提[新增]，每个人嘴里面讲的新增其实都不一样。

• 渠道商：“只要点了你们产品的下载按钮，就算一次新增了”
• 运营：“总得下载成功了才算吧，而且一个用户一天最多算一次”
• 产品：“我们按启动算吧。没打开APP也算，数据质量太差了”
• RD：“注册了才叫新增[用户]，否则后台根本没这条数据”

所以需要根据具体业务统一[新增的定义]。

1）增——选择合适地节点，定义[增]

因为渠道商往往强势，所以在哪个节点结算应该谈清楚。

2）新——用适当的方法，判别[新]

• 基于设备：IOS、Android、web各有门道
• 基于账号关联：与后台已有账号比对匹配

3. 如何理解留存

为什么要看留存，这个表格可以简明概括留存的作用。

举例：以7日日留存的三种算法为例来评估某渠道的质量。

算法一：（第七天/第一天）x100%——7日日留存，只关心到特定日的留存情况，避免了其他日数据的干扰。比如比较渠道在Day7的留存情况时，引入Day2~Day7的用户数据，反而影响判断。

算法二：（第二天~第七天去重后/第一天）x100%——7日内留存，引入了其他日数据，适用于有固定使用周期，且周期较长的业务。有些时候恰恰需要引入Day2~Day7的数据，比如，有些情况下用户访问特别集中（如kfc疯狂星期四，大量肯德基APP访问集中在星期三、四），只看Day7来评价，往往不能反映真实情况。此时，关注7日内活跃情况，更能描述渠道质量。

算法三：（ 第七天/第0天）x100%——7日日留存，新增当日为第0日，下一日为1日，使第7日与新增当日对齐，某种程度上能抵消某些星期级别的周期性差异。

同理，当不再以日为统计单位，而是以更长时间周期来统计时，就得到了周留存/月留存，此时可以更好观察整个大盘。注意，在计算时务必将用户去重，公式如下：

无论使用哪一种算法，公司内部结合业务特性达成彼此认同时最重要的。

4. 渠道来源怎么看?

关于“用户从哪儿来的？”这个问题，我们通常可以看渠道来源这一指标解决。在实际工作中，产品经理会通过公司合作的数据机构给出的各类报表查看。在这里笔者简单总结几种主要渠道。

不同的网站统计工具与分析工具对网站流量获取的渠道各有差异，但基本上可分为几个渠道：

• 直接访问（Direct）
• 引荐流量（Referral）
• 搜索引擎自然流量（Organic Search）
• 付费搜索流量（Paid Search）
• 社交媒体（Social）

直接访问（Direct）：指的是用户直接访问网站，而不是从其他网站或搜索引擎进入。包括但不限于：用户在地址栏输入网址访问网站、从浏览器收藏夹访问、用户点击聊天工具里的链接如QQ聊天记录里的链接。

引荐流量（Referral）：从用户非搜索引擎与社交网站点击进入网站。比如友链互惠网站、百度贴吧等站外社区论坛。

搜索引擎自然流量（Organic Search）：从搜索引擎自然搜索结果链接进入网站的流量。区别于Paid Search，自然流量时搜索引擎自然排名结果的链接，通俗讲就是非竞价非付费的搜索引擎排名页面链接。另外值得一提的是，某些有中国特色的搜索引擎如百度，出了提供搜索引擎服务外，也提供很多的内容产品服务比如百度贴吧、百度知道等，从这些非搜索引擎搜索页面进入的流量并不归属于自然流量，而是引荐。

付费搜索（Paid Search）：即搜索引擎竞价，很多没有搜索引擎优化资源的网站，短平快的流量获取方式。在国内，竞价流量已经成为众多网站流量获取的主要渠道。

社交媒体（Social）：社交网站流量在绝大多数国产网站统计工具中并没有单独列出来。但是，全球最大的搜索引擎谷歌搜索的排名因素中，社交媒体因素已经占有超过10%的权重，所以也要引起重视。

还有在国内互联网圈不太提的几类:Email、展示广告、其他广告。另外，许多数据工具如果统计不到用户的渠道来源，会默认其为直接访问（Direct）。

5. PV UV 转化率 访问深度

PV（Page Views），即次数；UV（Unique Visitors），即人数。然而在衡量完成目标行为的潜力时，通常会用PV/PV表示该页面引发下一行为的能力；UV/UV表示用户的行为倾向；PV/UV表示人均行为次数。

1）PV/PV；UV/UV

2）PV/UV

3）访问深度

算法一：用户对某些关键行为的访问次数。

算法二：将网站内容/功能分成几个层级，以用户本次访问过最深的一级计算。

6. 访问时常

1）为何要统计访问时长

通过统计特殊事件，支持业务需求。比如，记录暂停/关闭页面后、播放器中视频进度条当前的位置，可以统计视频被消费程度，评价内容质量。

2）如何统计访问时长

• Web时代，直接统计页面打开时长（但如果我一直没关，或是上了个洗手间……）
• APP时代，统计前台驻留时常（如果我开着APP中途被叫去聊天……）
• 通过瞳孔与注意识别，即摄像头观察，瞳孔是否注视屏幕（需要外设和隐私授权……）

总之，采用何种方式统计访问时长一定要回归业务本身。

7. 业务相关的数据指标

举例：小卖部老板想知道，一共卖了多少钱？消费水平怎么样？来了多少人？有多少人买东西了？有多少人是老顾客？我们的商品好不好卖？……这些涉及总量、人均、付费数、付费率，通常要看业务数据指标。

8 弹出率（Bounce Rate）

通俗理解即，用户一点开某个页面就马上退出，不进行任何下一步操作的比率。一般统计的是整个网站产生的所有会话的弹出率。

本文由 @DarcyAI 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

,