数据分析师进阶第一步

丶紧系住的心跳

文章介绍数据分析师迈向高阶的“捷径”，进阶之路。所谓“捷径”，本质是方法论，是找到对的努力的方向，不让战略上的失误，导致自己的勤奋事倍功半。文章以互联网行业产品经理们的需求为例进行了阐述，也具备实操意义。

数据分析师/数据研发工程师最不愿意做的工作是：跑数。一个一个数据需求“砸”过来，找不到自己的价值感。为什么说像“沼泽”？沼泽的特点是你动的越多，陷得越深，除非有人救或旁边有棵救命稻草，否则很难出来，跑数据也正是如此。你跑的越多，需求方给你的定位越是跑数，跑数越久，人设越稳；在跑数需求满足好之前，即使挤出时间来做自认为有价值的事情（数据驱动业务），需求方（也是业务方）是不会买单的。那么，你唯一的出路，先服务好需求方！如何服务好需求方，还体现自己的价值呢？



首先，换位思考，从需求方的工作模式中找规律。

思考需求方的目的，为什么需要数据，要解决什么问题？你会发现需求方的需求都是有规律的，你需要抓住这个规律；而这个规律的本质是需求方使用数据时的痛点，而你的价值是如何解决这个痛点。

以互联网公司产品和运营的需求为例，他们的需求是最底层、最繁琐、最多的----

分析产品和运营的工作模式，是大致这样的流程：立项调研--评审--项目开发--项目灰度--项目上线--项目运营

再总结大量需求的总结，会发现产品和运营的需求（90%以上）是出于如下目的：

立项调研，论证项目的可行性，预估项目的收益
项目开发，如何埋点才能保证我想要的数据都能看到？
项目灰度，ABtest，或验收数据埋点准确性
项目上线，效果评估，告诉领导项目效果
项目运营，KPI监控与定位原因，监控项目的KPI，一旦发生异常，需要跟领导汇报原因
目的明确后，数据分析师便可以从繁琐的临时跑数需求中抽离出来，去通过建立数据分析模型，在业务方需求产出前有解决方案，也体现出了数据分析师的专业性，也建立了与需求方的信任，其他专题分析更容易与业务方沟通，形成良性循环。



其次，思考最佳解决方案。

（1）立项调研

需求特征：宏观，重复度低，维度多

最佳解决方案：多维查询工具。支持多维度交叉，支持多指标展现，多样化，能满足此类80%以上的需求，毕竟破格创新是少数，大多立项是立足原产品进行优化。多维查询工具所需要的数据内容，数据分析师往往有较大的话语权，需要从日积月累的需求中提取出使用率最多的数据指标和维度，来搭建多维查询工具。



（2）项目开发

需求特征：仅埋点需求，真正的需求滞后。

埋点在很多公司分析师不参与（尤其是高阶分析师往往更不愿意参与），是产品经理（PM）、产品研发工程师和数据工程师来决定的，在这三者中，似乎数据工程师是关键角色，且在大型互联网公司大多是有埋点规范的，那么，数据工程师会把控，要求研发工程师执行好埋点规范；但其实最关键的角色是PM，PM要能够在开发阶段就明确需求，实际上很多公司的PM是做不到的：一方面，认为数据埋点是产品研发过程中的小事，总是由低阶的PM或新PM来提；另一方面，认真的需求往往到上线后才会开始准备，会发现：①好些需求无法满足，埋点存在问题；②需求无法快速满足，埋点不合理。注意，这里追查埋点问题，往往是谁负责？数据分析师。总结奇怪的点：数据分析师不参加埋点，却要为埋点问题买单。



最佳解决方案：

1）数据分析师参与埋点。但并不是随便一个分析师都可以做好，需要很强的结构化思维能力（我承认，这不是一个很容易量化的能力，也不是一个容易自我发现短板的能力，大部分人都认为自己有这一能力。你可以通过别人对你的分享和分析报告的反馈来感受自己的这方面能力水平：当负面反馈、质疑越来越少时，这方面的能力越来越好）；

2）怎么做（可以有教程的部分）：①熟悉公司制定的埋点规范；②在介入埋点需求时，要确定PM上线后对效果评估与KPI异常追查的需求；③确定你理解了业务方在做什么，目标是什么；④请大致拆解好如果让你做效果评估与异常追查你需要哪些维度什么指标。

第2点的本质是：一方面通过分析师提醒将需求前置，防止埋点风险；另一方面数据分析师是提供数据化解决方案的人，体现了数据分析师的价值，有你在，数据化运营更高效。



（3）项目灰度

需求特征：数据埋点验收，ABtest（部分公司具备该能力）

最佳解决方案：推进工具化，系统判断数据有无，PM判断数据量级是否准确后在线上确认。解放数据分析师跑数验收。ABtest在这里不展开，ABtest的工具化讲细节篇幅大可另起一篇文章。



（4）项目上线

需求特征：本质是分析需求，但被PM拆解成为一个一个的临时统计需求，分析师可能看不到全貌。

最佳解决方案：效果评估分析。一方面，效果评估分析如果公平公正，应该让在第三方立场的数据分析师来完成，需要客观；另一方面，在实践中往往负责项目的人会避重就轻，无法真实评估项目效果，在错误的产品方向上越走越远；第三，在埋点时，你已经跟PM沟通了你的效果评估方案。想做到这一点，一方面在日常的交互中，与业务方积累了信任，业务方知道分析师的专业性；另一方面，业务方leader与分析师leader应达成共识，由第三方立场的分析师来主导效果评估；第三，效率，要在较短时间内完成效果评估，是业务方的诉求。



（5）项目运营

需求特征：明确。

建报表监控需求：进入日常运营阶段后，会有各种推广策略，PM会监控产品的核心指标的波动；

异常追查：使用了各种资源做了推广，当KPI波动时，必然需要定位波动原因。

但，PM往往是只提报表需求，异常追查是在发生后作为临时需求提出，且一步步验证自己的假设，会有好几轮需求砸给你。这里会有幸存者偏差[1]，即PM从自己理解的角度来建立假设提需求，但往往数据的波动是多因素影响，但PM没有数据的全局观。



最佳解决方案：

需求前置。在埋点阶段理清KPI和业务的逻辑后，便应筹备KPI报表和归因体系的搭建。
做归因工具（数据解决方案），让PM自己查异常。搭建每个项目的归因体系，应成为常态，分析师面对的问题中，最多的就是为什么？从诸多数据中，定位问题原因。
把归因体系搭建的很好的分析师很少见，很多分析师会从数据视角拆数据，“我把我看到的指标全拆一遍，肯定能找到问题”，这是错误的，应从业务视角拆数据，这是截然不同的结果，但跟很多分析师分享这个时，有的意识不到这个问题。这两个视角的差异：数据视角没有带着分析目的去，往往浅薄，可以知其然，但无法知其所以然。

如何做好归因体系，



一方面，要有业务视角。

业务视角本质是结构化思维，有论点论据，层层拆解，最后是拆解到无法再拆，能反映业务动作的指标。业务方往往会认为分析师不懂业务，懂业务的本质是深刻理解业务的闭环和生意的本质，所以大家都不一定懂。大家日常口中的懂业务实际上是信息的不对称，不是懂业务本身。信息不对称是很容易解决的，比如：参与埋点过程会帮助你了解一个项目的所有细节。



另一方面，要总结规律。

KPI报表数据往往是极度汇总性质的数据，融合了很多信息，因此其波动，也往往是多种因素影响，对动因进行归类，并统计出现的频次，从高到低便是归因体系中体现的位次，这些动因能覆盖90%以上的异常波动---这里存在冷启动，新业务没有归因经验如何对动因进行归类，这是考验一个分析师日常积累够不够的地方，能否从其他项目经验中提炼出共性，如果修炼不够，可以先上线，后优化迭代；
归因体系不是一个个报表，是归因看板，需要有可视化工具的支持才会真正的高效，也才会让PM体验好，没有看板事倍功半。


第三，5why分析法[2]，即多问自己几次为什么。

这是一种查验自己是否真正拆解到极致，能反映业务动作了的方法。像是一种心理暗示，却很有效。


分析师是很辛苦的岗位，大家辛辛苦苦一年，年底绩效考核时往往会惊诧：这一年我都做了什么，竟然总结不出来。因为工作是零散的，被一个个不成项目的临时需求占据。

上文所讲，是多方共赢的方法论：一方面分析师从一个个项目中得到成长，绩效考核时也有令人满意的成绩；另一方面，解放了分析师和业务方PM的人力，可以做更有价值的事情，这边是分析师在进阶；第三，在业务方建立了信任，更容易推进分析结论的落地；第四，公司的数据化运营更高效。

希望看到文章的人能够理解文章的思路，能够融汇贯通，应用于工作。




注释：

[1]幸存者偏差：指的是只能看到经过某种筛选而产生的结果，而没有意识到筛选的过程，因此忽略了被筛选掉的关键信息。典型案例：在二战期间，发现幸存的轰炸机中，机翼中弹的数量很多，而机身中弹的却很少，因此有的专家认为我们应该加固飞机的机翼。其实不然，就是因为机翼中弹多还能飞回来，所以机翼中弹并没有影响飞机返航；而机身中弹的少则说明了子弹打中机身对飞机的影响更大，导致飞机不能返航。



[2]所谓5why分析法，又称“5问法”，也就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因为止，有时可能只要3次，有时也许要10次，如古话所言：打破砂锅问到底。