完整的数据分析师能力体系应该包括底层认知、业务场景及能力三板斧。

底层认知

在建立数据分析思维之前,应该先在底层认知达成共识。
什么是认知?是对事物底层逻辑的了解,是对是世界万物的判断,认知的本质就是做决定。 也就是说,为了帮助数据分析中每个决策的有效性(选择什么指标、分析方法?接下来做什么?等等),需要先建立底层认知。

这一步,我们需要去明确数据分析的定义:数据分析是什么?目的/产出?分析流程?

数据分析是什么

同学们在求职过程中会发现,同样是数据分析师岗位,但是面试的内容千差万别,有考察机器学习、统计学等专业能力的,也有考察市场/行业分析的,还有考察产品分析的。
此时就有同学问,这些真的是数据分析该做的吗?

我们从字面上拆解,数据分析 = 数据×分析,进一步拆:

• 数据能力 = 统计学 ∪ 机器学习 ∪ 建模能力 ∪ 工具使用 ∪ ...

• 分析能力 = 经营分析 ∪ 用户分析 ∪ 产品分析 ∪ ...

这就是认知上的偏差:当一些同学认为数据分析就是用Excel做表、python写脚本、机器学习建模时(其实这些只是组成数据分析能力的一部分),求职市场对数据分析师的要求更为完整。

回过头来看,数据分析到底是什么?笔者认为,数据分析是一个过程,是利用数据能力做分析的过程:从发现问题、分析原因,到落地建议;这还是一个“解构”的过程:从整体拆到局部,从一般到特殊,从面到线到点,不断下钻剖析,找到具体可落地的点。

数据分析产出是什么?

了解完什么是数据分析后,深入思考一个问题:这个过程的最终产出的交付物是什么?

要回答这个问题,我们需要回到数据分析的本质:解决业务问题。 也就是回到业务层面的需求是什么,才能决定最后落地交付物:

1. 解决问题

最常见的数据分析场景,就是业务发现销售额下降、用户流失、产品跳失率高,也就是业务层面出现了一个问题待解决,此时需要数据分析师介入帮助从数据层面挖掘原因、给出解决建议。

分析过程可能是做一些探索性数据分析、统计分析、机器学习建模,甚至是做AB测试实验,最终交付分析报告,或者模型部署上线。

2. 理解现象

有时业务可能并不存在确切的“问题”,更多旨在通过加深对现有场景的理解,来提高现有业务模型、策略的效果;比如,现在业务使用的是客单价平均值将客户分为高、低两个人群进行营销,此时数据分析师通过对消费者的洞察分析,给予更精准的人群划分方案:利用客单价分位数,将客户分为三个人群,这样业务利用更新后的策略进行营销设计,提高转化效果。

分析过程可能是做相关分析、回归分析,甚至是无监督的聚类,来对现状进行解释。

3. 支持诊断

按照需求的时效性,可以把业务需求分为临时需求和常规需求,而前面两者属于业务的临时需求,或者说是专项分析需求。对于常规需求,主要旨在提高业务流程的效率,比如对于电商运营中的商品库存管理业务,运营需要及时查询库存情况,并结合销售趋势对低库存量的商品进行补单;此时,数据分析师可以通过交付“低库存预警报表”来帮助优化该流程效率。

支持诊断的内容主要集中在自动化的报表,甚至是商业智能(BI)体系的搭建。

4. 探索发现

如果说前面是基于已知模式的分析,那么业务中还存在一种需求,就是对未知的探索。最为典型的场景则是对市场、对消费者的洞察后,给出品牌及业务增长的策略。

分析过程更多是基于行业、基于市场,使用如PEST、SWOT、波特五力等商业分析模型。

分析生命周期

至此,我们知道了数据分析是什么,以及最终的产出交付物,那这个过程如何实现的呢?从落地的角度来看,数据分析是一个从发散到收敛的过程:业务理解-数据探索-分析模型-落地交付-产品生命周期

·业务理解

数据分析是从业务到数据再回到业务的过程,所以理解业务是数据分析的起点。

1. 业务场景

“无场景不分析”、“脱离业务场景的分析都是耍流氓”等资深数据分析师的建议无不说明业务场景的重要性。数据分析能力模型中的业务场景模型:用户-产品-场景,就是为了帮助读者理解业务场景而设计的,在这里不赘述。

2. 问题定义

不知道读者有没这样的体验?就是领导交代任务给你,或者是朋友有求于你时,执行力强的人很快就完成了任务请求,但是最后却被告知这结果并不是对方想要的?这种情况很常发生在初入数据分析岗位的新同学身上,原因归根结底就是没有做好问题定义!

在理解了需求所处的业务场景后,可以借助逻辑树工具来对问题进行拆解,拆解的过程尽量要遵循MECE、“相互独立,完全穷尽”的金字塔原理。

3. 预期价值

其实,很多企业都在讨论数据分析师的价值在哪?从这一现象可以看出数据分析师需要时刻关注价值产出,围绕价值的开展工作。

如果说前面定义问题是明确做什么,那在这一步就是要明确做到什么程度?

比如面对销售额下降的问题,做数据分析,最终是产出一份数据分析报告就好了,还是说需要介入到测试实验,给出增长策略?如果是后者,那对销售额的提升幅度要提升多少才有价值?是不痛不痒的1%还是要达到显著的10%?

如果不在价值层面做思考,并付诸价值落地的行动,最后很容易产生“价值在哪”的灵魂拷问,面临被优化的风险。

·数据探索

在业务理解阶段,我们是站在业务层面与需求方沟通,但是数据分析的核心部分都是在数据层面进行的。所以在正式开始分析之前,我们需要把业务需求转成数据需求,这个过程就是数据探索。

1. 数据初探与探索性验证

拿到业务需求时的定义问题阶段,需要数据的辅助:用数据透视业务,判断现状与描述是否一致。比如,业务说销售额下降了需要分析,但是这个下降是和谁比?环比下降但是同比提升,同比下降,但是和竞品相比是提升的。

这个步骤比较多的是使用探索性数据分析(Exploratory data analysis),或者说通过常见的统计指标来对数据现状进行剖析。

2. 数据需求

如果说第一步是在用数据验证需求的有效性,那这一步则是真正把业务问题转为数据需求。

此外,还需要判断数据质量及能做的特征工程,比如某些字段缺失率太高,这会影响特征的构建。

分析模型

了解业务、明确数据需求后,就可以挑选合适的武器(分析方法、模型框架)上阵。

概括来说,有四种分析方法:

1. 比较分析

指标的好坏、特征是否显著等都可以通过比较分析的方法来实现,比如常见的归因业务场景,本质就是做比较,通过横向、纵向的比较找出原因。

分析方法:比如T检验、方差分析、同比环比、同期群分析等

2. 相关分析

分析变量之间的相关性是重要的分析场景。比如业务中想知道提高广告预算是否能、甚至是能提升多少的销售业绩?这样的相关性分析或许能找到最优投放ROI的配置方案。

分析方法:卡方、皮尔逊(Pearson)相关系数、斯皮尔曼(Spearman)相关系数、结构分析等

3. 预测(有监督)

不论是对企业销售的预测、还是对用户行为的预测,都能帮助提升业务效率,比如常见的预测用户流失分析,及时得到高概率流失的人群名单,运营通过提前营销干预,提高用户留存率;常见的销售预测能帮助企业在供应链侧做准备。这类场景主要应用的是机器学习中的有监督分类模型。

分析方法:线性/逻辑回归、决策树、时间序列分析、贝叶斯等;

4. 发现(无监督)

前面三种都是基于企业已知模式的分析逻辑,还有一种分析方法——无监督的机器学习模型,可以应对未知模式的分析。比如不知道应该把现有人群分成多少个组来进行营销最合适,就可以对人群基于核心特征做无监督的聚类分析,得出有效分组的界限。

分析方法:Kmeans聚类、DBScan聚类等;

·交付落地

交付落地的最佳实践是让数据和分析从理论渗透到业务中,对流程进行变革提效。

1. 方案评估

在交付给业务之前,需要先对给出的解决方案做有效性评估:

• 模型验证与落地评价

分析如果涉及模型的开发使用,需要通过AB测试,或者ROC等指标来证明模型在数据层面上的有效。在数据层面完成验证后,回到业务分析需求,评估交付的方案在业务层面上的有效落地。

• 影响预估

数据分析是围绕业务价值而展开的,所以在最后的落地,也得就价值进行讨论,回答这个方案解决业务问题的途径和程度:

A. 途径是对流程的优化(降本提效)还是对数据的优化(数据体系效率、数据质量)?

B. 这方式能多大程度上帮助解决?比如对业务的提升是10%还是30%?是对单次项目的应用,还是说可以部署到日常流程中,在更长时间、更广范围内影响业务?

C. 此外,要实现这样的效果,需要投入的资源是什么

2. 讲故事

分析项目的落地需要多方参与,即使是业务能力丰富的分析师,由于流程边界的存在也不可能每步都参与执行。因此,确保项目能否有效落地的一个重要因素则是能否和业务达成共识。

如何做到?讲数据故事:起因(需求定义)、过程(分析逻辑)、结局(重要结论)是否引人入胜(被认可)。

这个过程需要制作PPT向上汇报、与业务沟通,甚至是做跨部门的演讲。

3. 模型实施

不论是业务模型还是算法模型,最终都有一个“靴子落地”的过程--落地实施。模型测试有效、与业务达成共识后就到了模型的部署上线阶段:

• 对于业务模型,如RFM,则是部署到业务流程中,应用在会员管理、活动营销等环节

• 对于算法模型,如推荐算法,则是部署到产品功能上线,可以以内置算法、REST接口等形式落地

·产品生命周期

接在分析生命周期最后的是分析产品的生命周期:以产品的思维看待数据分析,交付至业务落地的模型应用就是产品。数据分析这个过程并不是静态、单次的,而是一个PDCA不断迭代升级的过程。(这个分析产品的定义包括分析服务、数据产品。)

1. 流程再造

从产品思维的角度,分析结论落地到业务流程中,对流程进行再造,提高运营效率。

2. 数据产品

当数据分析流程成熟后,大量重复执行的流程可以抽取出来,形成自动化的产品,用于服务数据分析(主要对象为数据分析师,也包括运营),这就是数据产品。分析师的结论模型就可以部署到现有的数据产品中,优化分析效率。

3. 持续改进

之所以要从产品思维的角度来看数据分析过程,是因为要像迭代产品那样去迭代分析模型:不论是优化算法参数,还是调整分析框架,都能得到更优的结论。

业务场景

在数据分析生命周期第一步的“理解业务”中,我们提到业务场景的重要性。

根据业务经验,笔者沉淀了一套便于理解的模型:业务场景 = 用户 × 产品 × 场景

也就是说,要理解业务,就要了解用户,熟悉产品,明确分析所处的上下文场景。它们决定了分析的目标、处理逻辑以及落地建议。

更详细的讨论见:回归到营销理论,谈谈到底什么是业务场景?

能力三板斧

对数据分析有了底层认知、了解业务场景后,就需要有看得见摸得着的“招式”来行动:思维方法、工具技术和项目能力这三板斧能组成不同招式应对多变的问题。

经常看到有人说数据分析如做饭,如果是这样的话,在数据分析这个厨房里,工具技术就是锅铲、铁锅、勺子等器皿,思维方法就是切配、烹饪、打荷等技艺手法,项目能力则是最后的装盘上菜。

思维方法

很多人学做饭,可能是因为在抖音或B站看到某个美食视频,然后就开始按照视频步骤备料烹饪。这个过程,也就是数据分析中学习思维方法的过程。数据分析也是先有思维方法,才能谈得上是分析。

刚开始学做饭时,通常先学基础的煎、炒、炸、烤、煮、蒸、焖、拌烹饪方式。这些基础的能力在数据分析中就是统计学、相关分析、归因分析等通用分析思维。

正如美食有八大菜系,分别满足不同地域人群的口味,数据分析在不同场景下,也有不同的“分析”招式来满足不同的业务需求:

• 用户分析:同期群分析、漏斗分析、RFM用户分层模型等

• 产品分析:竞品分析、帕累托分析等

• 商业分析:PEST分析、SWOT分析等

• ...

工具技术

习得了做饭的方法后,就可以选择几件趁手的器皿,来提高烹饪效率。

之所以不是先选择器皿再研究做饭流程,是因为工具始终是工具,完成同一个目标或许有多种工具可以实现,再不济我用原始的土灶也能烧饭。

不过对于部分复杂的烹饪需求,也是需要选择特定的器皿才能完成。

常见的工具技术及应用:

• 表格工具Excel:是几乎所有人第一个接触的分析工具,可以做简单的分析及可视化图表制作,但对于量级较大的数据处理起来显得力不从心;

• 数据库SQL:“巧妇难为无米之炊”,对数据分析师来说没有数据就谈不上分析,对于绝大数企业来说,数据存储在数据库中,因此有必要学习数据库语言SQL来对数据进行抽取、清洗、甚至是分析。

• 脚本语言Python/R:编程是与机器交流的方式,同时也是新的思考方式。学习编程语言的作用在于利用机器帮我们处理工作,比如自动化办公、复杂业务分析逻辑、以及重要的机器学习算法模型等。

• SPSS:说到机器学习算法的应用,不得不提到SPSS工具,它不仅能实现大部分统计方法,还能通过简单的点选实现机器学习算法的计算。

• PowerBI/Tableau:商业智能工具做可视化仪表盘也是数据分析中常见的落地形式;与Excel相比,PowerBI/Tableau能实现更复杂的图表,且可实现交互、动态报表。

项目能力

菜做好后一定要及时出锅、装盘、上菜,要不然再美味的菜肴也只是空中阁楼。

项目能力强调的是数据分析项目的落地。理论的分析方法如何在业务场景中落地赋能,体现数据价值?这是很多企业数据团队在讨论的课题。

说项目能力像是烹饪最后的上菜阶段,其实不太严谨,因为落地能力是一种软性的能力,贯穿分析项目的整个过程:

1. 需求管理:这个过程也是价值管理的过程,将有限的分析资源(时间、精力)分配到更有价值的需求上

2. 项目计划:形成从提出问题到落地实施的完整SOP流程,制作可落地的项目计划可有效指引分析落地工作

3. 横向连接:推动跨部门协作的沟通能力本质就是在连接不同资源,尤其是在实验过程中,需要连接比如零售行业中用户运营部门的人群触达资源、产品部门的供应资源、销售管理部门的价格折扣资源等来推动落地

4. 向上管理:在企业中,必要领导才有能力推动项目,如何利用管理手段帮助推动落地是一门有趣的学问

5. 结论报告:同样的分析内容,如何通过结构化地呈现?通过制作体现价值的分析报告把数据故事讲出来很重要,因为只有这样才能把分析形成闭环。