「Why-What-How」:数据分析的基本方法论

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

2017.12.3受「水滴互助」的朋友相邀,分享了个人在数据分析领域的一些基本方法论。数据产品以沉淀数据分析思路为基本点,这两个领域略有重合之处。在这里整理成文章分享给大家。


「Why-What-How」在讲解概念和执行上是个不错的思维模型
,这次依例按此框架来拆分「数据分析」。相信很多朋友已经有了较丰富的分析经验,这里权且从个人的角度进行梳理,以资参考。为了帮助大家更好地理解本文,先贴出一张思维脑图:

一、WHY:为什么要做数据分析

在目前讲解数据分析的文章里,大多数会忽略数据分析本身的目的。这会导致我们在执行时,会出现动作变形的情况。

以终为始,才能保证不会跑偏。

个人的理解上:数据分析是为了能以量化的方式来分析业务问题并得出结论。

其中有两个重点词语:量化和业务。

首先讲下量化。

量化是为了统一认知,并且确保路径可回溯,可复制。统一认知后,才能保证不同层级,不同部门的人在平等话语权和同一个方向进行讨论和协作,才能避免公司内的人以「我感觉」「我猜测」来猜测当前业务的情况。

路径可回溯可复制指的是:通过量化后的结果,许多优化的方法是可以被找到原因并且可以被复制的。同样是转化率优化,用 A 方案和 B 方案,谁的效果会比较好和具体好多少,都是可被预测的。

要想做到量化,需要做到三点:建立量化体系,明确量化重点和保证数据准确性。

1.1 建立量化体系

建立量化体系,主要是根据「指标设计方法」,设计业务的「核心指标+拆解指标+业务指标」,最后落地成全公司通用的「指标字典」和「维度字典」。

这种工作一般是由数据分析师或数据 PM 来担任完成。通过这种方式,我们就能初步建立面向全公司全面,系统的量化分析框架,保证日常分析可以做到「逐层拆解,不重不漏」

1.1.1 指标设计方法

讲到指标设计方法,大家可能觉得:之前听过了产品设计方法、程序开发方法,指标这种东西也有设计方法么?

确实有,指标设计是一套以准确和易懂为准则,集合统计学和业务效果的方法论。

准确是指能够准确满足衡量目的,易懂是指标算法能直观显示好与坏,并且指标的算法也能够通俗易懂。这两者很多时候需要有所抉择,准确是第一位的。举个例子:当我们想衡量一个群体收入的差异性时,用方差还是用基尼系数?

方差好懂,但不能显示两个极端的差异性多大。基尼系数算法不好懂,但能准确描述这个问题。

具体到指标设计,我们需要使用一些常用的统计学工具:

以顾客质量分析为例:概况是我们看下顾客的平均支付金额,或者支付中位数,来了解顾客概况。如果我们想了解这批顾客的质量是都比较好,还是良莠不齐,则需要通过方差和标准差来描述。如果想知道更详细的内容,可以了解每个区间的用户数是多少,来做判断。

有一些 Tips 供大家参考:

  1. 比率指标:关注实际效果(下单转化率,光看下单数是没有用的)
  2. 伴生指标:既要看新客数也要看 CAC,确保数量的前提也要确保质量
  3. 防止坏指标:错误指标,虚荣指标,复杂指标

这里简单解释下每个 Tips 的目标。

之所以采取比率指标和伴生指标,是因为能够明显反映业务的「效率」且能够有效防止因为追求单个指标而导致动作变形。

如果说这辆车能跑十万公里,其实并不能表示这辆车的性能怎么样;只有「速率=路程/时间」,才能反映这辆车的效率。

同时,如果片面追求速率,会导致汽车在设计时剑走偏锋,给驾驶者带来危险;因此需要再加个「故障率」或「事故率」等伴生指标来确保安全。

坏指标中的「虚荣指标」首次出现《精益数据分析》一书中,作者简单把「PV/UV」等指标都归为虚荣指标。

刚开始时我颇为认可,但后续在实际的应用过程中,发现对于很多业务的监控,这些指标并避免不了。后续我便把「虚荣指标」更正为「把距离业务目标过远的环节定义为核心监控指标」

对于一个即时通讯 APP 来讲,下载次数、启动用户数、注册用户数需要监控,但不能作为核心监控的指标;更合适的应该是消息数或「进行过对话的用户数」。

复杂指标往往是各种「指数」,用了很多指标各种加减乘除,这会导致此类指标在发生波动时,很难分析原因。

拥有对指标的定义权和解释权是个段位非常高的事情,这要求设计者深入了解业务和拥有极高的抽象能力。

对于分析师来讲,拥有指标定义权将凸显出你在业务方的重要性——当然,这里并不是鼓励大家为了定义指标而定义指标。寻找业界已有量化方法并在公司内推广,也是件功德无量的事情。

举个美女外卖的「美女厨师率加权指导值」为例。为避免泄露商业机密,将这个原本用来衡量用户体验的指标换成「美女厨师率」,以下背景也稍作修改,大家领会精神即可:

指标的背景是为了保证用户的用餐体验,美女外卖总部提出每个城市的商家必须配备一定比例的美女厨师。但城市提出异议:不同城市拥有的商家情况不一样——大型的商家厨师多,美女厨师率会相对较低,不能用统一的值来对比所有城市。因此总部便设计出来这么一个指导值:将全国商家进行分层,每个层次的商家得出全国平均值,然后各个城市对标平均值产出自身的对标值,即「美女厨师率加权指导值」。虽然在计算上稍微复杂点,但在实际应用的过程中,BD 们只需要知道总体的差距和每一层商家的差别,很容易针对性的落地和优化。

1.1.2 建立指标体系

在根据「指标设计方法」上,如何建立起围绕业务的指标体系呢?

核心是根据业务特征确定核心指标,在核心指标的基础上以不同的角度进行拆解,然后再慢慢补充其他业务的指标情况。

拆解的时候,要做到按指标拆解而非维度。比如订单数,也可以拆解为各品类的订单数合计,这一点可以通过保持上下两层指标名称不一致来避免。拆解的过程依照金字塔方法论的「逐层拆解,不重不漏(MECE)」。若拆解出来或业务补充的指标过多,可借鉴数据仓库的「域」概念来管理这些指标,如上图的「交易域」,「商品域」和「用户域」。

在一个规范的指标体系中,已经涉及到元数据管理的领域了。包括针对指标命名的规范,数据存储和计算的管理等等。大家有兴趣地可以搜下相关文章,或阅读阿里巴巴新出的《阿里巴巴大数据实践之路》。

下面截取一张来自云栖大会的,关于指标命名规范的 PPT 给大家:

1.1.3 建设指标维度字典

这里是转转公司早期部分的指标维度字典,(Bus Matrix),一定程度上解决了之前公司内对于指标定义不清或不统一的问题。现在这套东西已经产品化,可以在可视化产品中查看和显示了。

对于暂没能力产品化的公司,建议可由分析师们通过 Google Docs 或 Wiki 对一些关键和常用的指标进行统一的维护。

对于维度总线矩阵,主要是在以维度建模的数据仓库,设计数据产品,多维度交叉分析时提供框架和基础。

1.2 明确量化重点

每个阶段,都应该明确当前的业务重点;量化体系需要根据业务阶段,更改量化重点及方式。

这同时意味着:有更细节的指标及更大的监控和推广力度。

比如外卖行业早期,经历了看重订单数,到订单额,到新客数+补贴率,到新客数+资金使用效率(交易完成进度/费用完成进度)的历程。

我们可以看到:随着战争的阶段不断升级和变化,从不计成本打下市场份额,到看中订单质量,到存量市场争得差不多了,开始考虑新客数量,同时控制补贴力度,到战争趋于常态化,开始控制整体补贴额度,靠拼效率来战胜对手。每个阶段,都需要根据不同的战场情况来判断当前重点,从而围绕该重点建立一套360度无死角的分析监控体系。

1.3 确保数据准确性

在数据准确性这个话题里,数据产品已经有成熟的数据质量管理方法;涉及了数据源,指标计算和数据呈现等各个环节的监控。

本文主要从分析师的角度阐述确保准确性的方法,数据产品相关的就先不赘述了。

  1. 采取可信来源:多来源交叉确认,采用新来源时需格外小心
  2. 确认加工方式:指标定义和加工算法
  3. Double Check:量级,计算逻辑和业务常识

这里着重讲下 Double Check 的技巧,这些技巧可以让很多管理层或投资人在不了解业务的前提下,就能判断出来数据是否有问题。

  • 量级 Check:每个数据有它的大概范围,比如 DAU,WAU 和 MAU。
  • 计算逻辑 Check:一般对于整体部分型的分数,比如市场份额,那么它必须满足:1,取值最大不能超过1;2,各部分加和应为1;3,两数字加和后,和应该在中间范围内。
  • 业务常识 Check:根据其他常用数字推算出该业务范围。如果有人跟你说某某社交 APP DAU 过亿,你大概知道是否在吹牛,因为日活过亿的 APP 就那么几个。对于 DAU/MAU,各个行业都有响应的范围值,淘宝为:34.6%,天猫15.5%,京东15.8%。

1.4 站在业务方的角度

除了「量化」之外,另外一个重点词语是「业务」。

只有解决业务问题分析才能创造价值。

价值包括个人价值和公司价值。

对于公司来讲,你提高了收入水平或者降低了业务成本,对于个人来讲,你知道怎么去利用数据解决业务问题,这对个人的能力成长和职业生涯都有非常大的帮助。

如何站在业务方的角度思考问题呢,总结起来就是八个字「忧其所虑,给其所欲」。

这里不仅适用于分析师这个岗位,在所有以供需为主要关系的交互过程里,精准理解对方需求对于供给方都是最重要的。比如 PM 对于用户,分析师对于业务方,下级对于上级。

在具体的落地过程中,主要是在这以下几个环节

  1. 沟通充分
  2. 结论简明
  3. 提供信息量及可落地建议
  4. 寻求反馈

在沟通上,确定业务方想要分析什么,提出更合理专业的衡量和分析方式,同时做好节点同步,切忌一条路走到黑。在分析业务需求上,跟很多产品需求分析方法论是类似的,需要明确所要数据背后的含义。

举例来讲,业务方说要看「页面停留时长」,但他实际想要的,可能是想衡量用户质量,那么「留存率」「目标转化率」才是更合适的指标。

在阐述分析结果上,要记得结论先行,逐层讲解,再提供论据。论据上,图 > 表 > 文字。因为业务方或管理层时间都是有限的,洋洋洒洒一大篇邮件,未看先晕,谁都没心思看你到底分析了啥。需要做到:在邮件最前面,用 1-3 句话先把结论给出来,即使需求方不看后续内容都可以了解你报告 80% 的内容。

在「提供信息量及可落地建议」上,先要明白什么叫信息量:提供了对方不知道的信息。太阳明天从东方升起不算信息量,从西方升起才是。在分析的过程中,一定要从专业的角度,从已知边界向未知边界进军,力求角度新颖论证扎实,并且根据分析内容给出可落地的建议。

举个简单例子:

寻求反馈是很多分析过程所缺乏的一步,数据分析给出去后便没有持续跟进。那你就不知道到底做得对不对。

反馈犹如一面镜子,让你及时地调整和优化自己的方法论。

二、WHAT:什么是数据分析

数据分析的本质是抓住「变」与「不变」。

「变」是数据分析的基础,如果一个业务每天订单是 10000 单,或者每天都是以 10% 的速度稳步增长,那就没有分析的必要了。而若想抓住「变」,得先形成「不变」的意识。

积累「不变」,就是养成「数据常识(Data Common Sense)」的过程。「不变」是根据对历史数据不断的观察和积累而来。一般来说会是个范围,范围越精准,你对「变」就越敏感。这里有三个个人的习惯,可以帮助养成「不变」:

  1. 形成习惯,每天上班第一时间查看数据:实时&日周月报
  2. 记住各个指标大数,反复推算
  3. 记录关键数据(榜单&报告)

大部分指标没有记住全部数字的必要,简单记住大数,万以下只需要记到万位,有些数字只需要记住百分比。 而指标之间的推算可以帮助你对各个指标的数量级关系和逻辑脉络梳理清楚,出现波动时便能更加敏感。记录关键数据是将工作生活遇到的比较有趣的榜单或数据报告保存在一个统一的地方,方便查阅和分析。

在「不变」的基础上,便能逐渐培养出指标敏感性,即意识指标偏离的能力。这主要是通过各种日环比,周月同比的监控以及日常的好奇心来保持。

这里插播一则管理林元帅的野史:林彪领军,有个习惯是记清楚每场战斗的缴获和歼敌的数量和种类。在 1948 辽沈战役寻找对方军长的过程中,发现了一个遭遇战的战报数据有了细微的变化。他从过去「不变」的基础意识到了指标偏离:缴获的短枪与长枪比例,缴获和击毁的小车与大车比例及俘虏和击毙的军官与士兵比例都比其它战斗略高。他根据这个偏离的指标迅速圈定了对方指挥所的所在地,一举端掉了对方的大本营。

我们从一个 Questmobile 2017 年春季榜单上,来简单看下「指标偏离」是怎么应用到日常的分析上的:

这里先跟大家分享下怎么看这种榜单:

  1. 看整体排行:看哪些 APP 排在前方是出乎你意料之外的
  2. 分行业看排行:看行业里排行及其变动
  3. 看增长率:哪些 APP 增长比较快
  4. 看使用时长等其他指标

这里我试着抛出几个问题:

  1. 新浪新闻竟然比腾讯新闻还高?今日头条竟然比一点资讯低?
  2. 秒拍竟然比快手高?
  3. 百度地图在榜单上比高德高,为什么去年俞永福还敢宣称活跃终端数第一位?
  4. QQ 的时长已经连续两个季度月活出现下降了,是否意味着什么?
  5. 按增长率排序,最快的王者荣耀,其次是今日头条,快手,高德地图。高德既然还算增长得较快的 APP?

数据分析的定义,还有国外一本商务分析的书籍的定义作为注脚:

三、HOW:怎么进行数据分析

任何数据分析都是「细分,对比,溯源」这三种行为的不断交叉。最常见的细分对比维度是时间,我们通过时间进行周月同比,发现数据异常后,再进行维度或流程上的细分,一步步拆解找到问题所在。如果找到了某个维度的问题,则需要溯源到业务端或现实端,确认问题产生的源头。如果多次细分对比下来仍然没有确认问题,则需要溯源到业务日志或用户访谈来更进一步摸清楚情况。

3.1 细分

以下内容在上篇《大数据与用户研究》中略有提及,这里再做一个总结。在细分方式上,主要有以下三种方式

  1. 横切:根据某个维度对指标进行切分及交叉分析
  2. 纵切:以时间变化为轴,切分指标上下游
  3. 内切:根据某个模型从目标内部进行划分

横切上,以转转举例,我们对维度和指标做做了分类和交叉,当某一类的指标出现问题时,我们便知道该从什么维度进行分析。在进行横切分析时,经常需要多个维度交叉着使用。这在数据分析术语上叫:交叉多维分析。这也是刚才讲的「维度总线矩阵」看到的各维度交叉情况了。

纵切上,有目的有路径,则用漏斗分析。无目的有路径,则用轨迹分析。无目的无路径,则用日志分析。

漏斗分析分为长漏斗和短漏斗。长漏斗的特征是涉及环节较多,时间周期较长。常用的长漏斗有渠道归因模型,AARRR,用户生命周期漏斗等等。短漏斗是有明确的目的,时间短,如订单转化漏斗和注册漏斗。在轨迹分析里,桑基图是一种常用的方式。常见于各页面的流转关系,电商中各品类的转移关系等等。日志分析,则通过直接浏览用户前后端日志,来分析用户的每一个动作。

各种手段的细分往往交叉着使用,如订单漏斗纵切完可以接着横切,看看是哪个维度的转化率导致的问题。

内切上,主要是根据现有市面上常见的分析模型,RFM,Cohort 和 Segment等方式进行分析。RFM 即最近购买时间,频率及金额三个指标综合来判定用户忠诚度及粘性。Cohort,即同期群分析,是通过对不同时期进入平台的新用户分群分析,来区分不同新用户的质量,如留存率或目标转化率等。Segment 通过若干个条件对用户分层,然后针对不同用户进行分层分析和运营,如用户活跃度分层等等。

3.2 对比

对比主要分为以下几种:

  1. 横切对比:根据细分中的横切维度进行对比,如城市和品类
  2. 纵切对比:与细分中的纵切维护进行对比,如漏斗不同阶段的转化率
  3. 目标对比:常见于目标管理,如完成率等
  4. 时间对比:日环比,周月同比;7天滑动平均值对比,7天内极值对比

时间对比严格来说属于横切对比。但因为时间这个维度在数据分析和产品中极为重要,所以单拎出来说。横切对比中,有个比较著名的数据应用方式即是「「排行榜」。通过这种简单粗暴的方式,来驱动人们完成目标,或者占领人们的认知。前者有销售完成排行榜。后者有品类售卖畅销榜。

3.3 溯源

经过反复的细分对比后,基本可以确认问题所在了。这时候就需要和业务方确认是否因为某些业务动作导致的数据异常,包括新版本上线,或者活动策略优化等等。

如果仍然没有头绪,那么只能从最细颗粒度查起了,如

  1. 用户日志分析
  2. 用户访谈
  3. 外在环境了解,如外部活动,政策经济条件变化等等

3.4 衍生模型

在「细分对比」的基础上,可以衍生出来很多模型。这些模型的意义是能够帮你快速判断一个事情的关键要素,并做到不重不漏。

这里列举几个以供参考:

  • Why-How-What
  • 5W1H
  • 5Why
  • 4P模型(产品,价格,渠道,宣传)
  • SWOT 模型(优势,劣势,机会,威胁)
  • PEST 模型(政治,经济,社会,科技)
  • 波士顿矩阵

举个例子:

最近京东和美团外卖可能会发现送货时长延长,针对物流相关的客诉增加,从 PEST 模型就可以分析出来是否在政治上出了问题。而当你在竞品做比对分析时,SWOT 或者 4P 模型能够给你提供不同的角度。

四、数据分析如何落地

以上讲的都偏「道术技」中的「术」部分,下面则通过汇总以上内容,和实际工作进行结合,落地成「技」部分。

4.1 数据分析流程和场景

根据不同的流程和场景,会有些不同的注意点和「术」的结合

4.2 数据分析常见谬误

控制变量谬误:在做 A/B 测试时没有控制好变量,导致测试结果不能反映实验结果。或者在进行数据对比时,两个指标没有可比性。

样本谬误:在做抽样分析时,选取的样本不够随机或不够有代表性。举例来讲,互联网圈的人会发现身边的人几乎不用「今日头条」,为什么这 APP 还能有这么大浏览量?有个类似的概念,叫 幸存者偏差

定义谬误:在看某些报告或者公开数据时,经常会有人鱼目混珠。「网站访问量过亿」,是指的访问用户数还是访问页面数?

比率谬误:比率型或比例型的指标出现的谬误以至于可以单独拎出来将。一个是每次谈论此类型指标时,都需要明确分子和分母是什么。另一方面,在讨论变化的百分比时,需要注意到基数是多少。有些人即使工资只涨 10% ,那也可能是 150万…

因果相关谬误:会误把相关当因果,忽略中介变量。比如,有人发现雪糕的销量和河溪溺死的儿童数量呈明显相关,就下令削减雪糕销量。其实可能只是因为这两者都是发生在天气炎热的夏天。天气炎热,购买雪糕的人就越多,而去河里游泳的人也显著增多。

辛普森悖论:简单来说,就是在两个相差较多的分组数据相加时,在分组比较中都占优势的一方,会在总评中反而是失势的一方。

最后以几句话作为总结,也是全文中心:

  1. 数据准确性是第一位的
  2. 站在业务方的角度思考问题:忧其所虑,予其所欲
  3. 定义「变」与「不变」
  4. 细分,对比,溯源

 

作者:陈新涛,公众号ourStone

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

题图来自 Unsplash ,基于 CC0 协议

赞赏是对原创者的最大认可
5人打赏
评论
欢迎留言交流
  1. 很厉害,谢谢分享

    回复
  2. 写的很棒,学习了。

    回复