发布时间:2023-04-01 09:30
作者介绍
杭州@阿坤
母婴电商行业数据分析师兼数据产品经理;
致力于研究电商行业的数据驱动增长以及数据产品从0到1的搭建;
“数据人创作者联盟”成员。
00 前言
数据分析师在工作大概一年之后就会开始有一些困惑,每天都被一堆业务人员纠缠,要各种各样的数据,导致每天工作量很大,经常加班到深夜。却发现自己的能力也没什么提升,天天都在做重复的工作,对业务的提升也没有拿的出手的项目,因此绩效也不会太好看。开始质疑数据分析师根本不是做网上说的那种数据驱动增长的工作,而是一名被业务支配的“取数机器人”。这往往就是大多数初中级分析师遇到的第一个较难突破的瓶颈,那么该如何突破这个瓶颈。
编辑切换为居中
添加图片注释,不超过 140 字(可选)
01 砍掉无效的需求
01 砍需求的初心
首先砍需求的时候大家不需要有心理负担,觉得拒绝业务方的需求会被认为是偷懒的行为,害怕业务方一来投诉就会影响自己的评价。
大家需要明白砍需求并不是一种为了减轻自己的工作量而去偷懒的行为,反而砍需求往往需要花费更多的精力去和业务方argue,大部分情况下比直接接下需求要花更多的时间以及很可能会特别的心累。
那砍需求的目的是什么呢?砍需求是为了减少业务方和数据分析师在不正确的地方浪费时间,把节约下来的时间花到更加有意义的事情上面去,从而提高整个业务的运转效率。
在明白砍需求背后的终极目的后,我们就能毫无负担的与业务方进行battle。
02 砍需求的流程
1.了解业务方提出的需求是否有明确的目的
很多业务方在提出一个数据需求的时候自身并没有想清楚看这些数据是为了解决什么问题,如果一个业务方提需求的时候并没有明确指出要解决什么问题,就是单纯的想看看数据,这个时候需要果断的直接拒绝。这种看看类的数据需求是无穷无尽的,并不会实际解决业务问题,反而在浪费双方的时间。
当然在实操过程中,拒绝需求也是有比较大的难度,可能双方有职级上的差异,这种时候也首先需要和你的上级对砍无效需求这件事情上达成一致,必要时寻求上级的帮助。对于自己能拒绝的需求,需要尽量拒绝,学会恰当又不失和气的拒绝也是一门值得研究的艺术。这种需要基于对方的性格灵活应对(看人下菜)。
2.判断业务方想要解决的问题是不是一个“真实”的问题
如果业务方的数据需求已经有明确的目的了,这个时候你就需要去思考他这个想要解决的问题到底是不是一个问题。当然这个判断会有一些难度,需要数据分析师对业务有比较深刻的理解,才能避免业务方抛出一个伪命题时,被业务方牵着鼻子走。在接到这种需求的时候需要特别小心的甄别,比如:
一个电商平台的运营,提需求给分析师说美妆类目的毛利率比较高,让你收入、成本、优惠、人群等各个维度综合分析下原因。
钉钉的产品经理,提需求给分析师问,为什么钉钉的工作日DAU高于周末,让你做一个专题分析,给出原因。
一个成长记录App的产品经理,提需求给分析师,为什么节假日和周末上传的照片数量会特别多,让你从各个用户群体角度做一个拆解,找一找可能原因。
这三个例子,都是业务方提的伪命题类需求,本质上都是对应业务特性导致的,如果一个分析师不懂业务,真的去进行这些伪命题类需求的分析,那就会花费大量的时间进行一个无效的分析,做了无用功还会被认为不专业。
3.思考业务方提的数据需求能不能解决他的问题
如果这个数据需求经过前两步的考验,那么恭喜你,你已经有可能接到一个能给业务带来价值的需求。但是还可能因为业务方对数据方面的专业性不够,业务方提出想看的数据指标并不能实际解决他的问题。他们可能会发生相关性认为是因果性、本末倒置、人群不合理过滤等等的问题,那拿到这些数据后往往就会得到一个错误的结论。这就是展现一个数据分析师专业性的时候到了。首先你对于自己业务的数据指标体系需要了如指掌;其次每个数据指标背后代表的业务含义要了然于胸;最后业务方想要解决的问题,背后实际的业务含义也是十分之清楚。
那就开始进入砍指标环节了,也就是提问运营的环节。问清楚运营看每个数据指标是为了干嘛,如果不看这个数据指标会怎么样。问运营对这个数据指标的预期是什么,这个数据指标的好与坏会有什么样对应的业务动作。经过这样提问会后,就会砍掉不少无用的指标。
砍完指标之后就会进入加指标的环节。业务方大部分情况下只会站在自己的一亩三分地去思考问题,很可能会缺乏对全局的思考,那我们分析师在了解清楚需求背后真实目的之后,就得思考完成这个目的需要哪些数据指标来进行对比分析,基于业务方原本提出的数据指标进行查漏补缺,最终能形成一个较完善的解决需求目的的数据方案。这一点对数据分析师的要求也是相对较高的,需要对业务有比价深刻的了解,也有较强的数据思维。
03 砍需求的好处
如果每个需求都已经通过上面的灵魂拷问后,那就可以拒绝掉很多的业务方没有想明白的无效需求;也可以弄明白业务方真正的困惑是什么,在焦虑些什么东西,利用我们的专业性优势给予更多合理的建议;也可能会升级需求类型,从普通的取数需求变成一个有较大价值的分析需求。
那长此以往的合作下去,业务方很可能就不会再来提取数需求,都是来找直接找你聊他的困惑是什么,和你一起探讨什么样的数据可以解决的他的问题,那么这种往往都会变成最能体现数据分析师综合能力的分析类需求,最后一般都是会产出一份分析报告的。那我们数据分析师就可以翻身农奴把歌唱,从一个取数工具人变成一名业务迭代参与者,最终成为一名真的能创造业务价值的数据分析师,做到了数据驱动业务的增长。
02 建立完善的数据报表体系
对于日常需要看的数据指标,我们需要落地成对应的数据报表或者对于核心的部分开发自定义的数据看板。业务的变化是十分之快的,如果跟着业务的需求去做对应的报表,那是永远无法满足业务当前的诉求的,就会无止境的陷入报表的开发当中。你需要站在业务方的立场,去想业务的核心是什么,最需要关心的是什么,然后抽象总结出一套能监控业务现状,发现业务问题、指导业务分析的数据指标体系,落地成对应数据报表。这个推荐用OSM模型来搭建数据报表体系,由于这里篇幅有限,后面会单独写一篇文章来介绍OSM模型的实际应用。
提前规划好业务方需要看数据报表体系后,就可以避免很多常规性的重复取数。帮助业务方了解自己该重点看什么数据,提早发现业务有什么存在的问题。一个好的报表体系不仅仅是展示一推数字,更是一个能帮助业务方进行分析的思维模型,当业务发生异常时,顺着报表的设计思路,业务方能自行分析定位出问题所在,最后落地对应的解决方案后还能通过报表得出改动的效果如何。
利用报表体系解决业务方的日常性的看数据需求,只有一次性开发报表的工作量,搭建的过程中可能会比较痛苦,也会持续较长的时间,但是一旦数据报表体系搭建完成之后,就会避免很多后续的临时性取数任务。
03 深度参与业务重点项目
数据分析师一定要多参与到重点项目中去,这种参与并不是通过帮助项目简单的做一些报表,取一些数据。而是自己当成项目owner去想问题,去做事情。主动用数据帮助项目发现一些问题,并且根据自己对业务的理解给出一些解决方案,利用数据分析项目已执行方案的具体效果,把一些不好的业务动作去掉,把更多的资源给到实际带给项目正向效果的事情。站在业务方视角想一些能带来的增量的事情,并且利用数据分析师的优势把想法用数据来衡量可能会带来的收益,让事情能更好的落地。
当然做这个点对应数据分析师要求十分之高,需要真的的理解业务。一个好的数据分析师必定是一个好的运营和产品经理。那在你深度参与到项目中之后,并且给项目带来看得到的效果,业务方就会明白你的价值之大,会让你越来越多的参与到项目中去,也就能做越来越多的分析报告,也是真的让你的数据分析结果落地到实际的业务中去,实践了数据驱动增长。这样业务方自然而然会舍不得让你做哪些没什么用的临时取数需求。业务方也不是傻子,自然会懂怎么样与你合作对他的利益是最大的。
04 总结
要想避免成为业务方的“取数机”,下面这些点要特别注意:
懂业务,了解业务看起来很简单,其实难之又难,要懂商业本质,要有产品sense,也要有运营思维。所以一个好的数据分析师必定是能胜任产品经理和运营的岗位的。
把自己想象成老板,用经营的视角的去思考公司的业务。想一想公司商业模式的本质,也可以时常去关注竞品的动向,想明白的目前业务的核心到底是什么,思考公司和管理层需要什么样的数据帮他们了解业务的发展情况,监控业务的迭代效果。
多站在运营的视角去想当前的业务现状是什么,运营目前的困惑是什么,什么事情是他们当下该关注的核心,什么样的北极星指标能指引运营朝着正确的方向前进。
如果一个数据分析师能把以上3点掌握透了,那必定已经达到一个新的高度,摆脱初中级分析师的瓶颈,拥有了自己的核心竞争力,向着新的成长道路出发。
Python写一个GUI界面的BMI计算器(使用PySimpleGUI)
npm安装报错(npm ERR! code EPERM npm ERR! syscall mkdir npm ERR! path C:\Program Files\nodejs\node_ca...)
机器学习(Machine Learning)与深度学习(Deep Learning)资料汇总
Android Studio warning variantOutput.getProcessResources() 无法实现tinker热修复问题解决
分布式锁用 Redis 还是 Zookeeper?看完你就明白了
我是如何将一个老系统的kafka消费者服务的性能提升近百倍的