1

这才是真正的数据分析项目,而不是爬表

 1 year ago
source link: https://www.51cto.com/article/722648.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

这才是真正的数据分析项目,而不是爬表

作者:接地气的陈老师 2022-11-14 11:55:39
作为数据部门的领导,可能最想承接的就是计划类工作,虽然技术含量低,但这是一个直接服务大老板的机会。能多在大老板面前露脸,本身就是一个绝好的立功机会。

经常有同学抱怨:每天忙于取数,不知道有啥数据分析项目可以做。今天系统性介绍一下五大类数据分析项目。它们都是可以单独立项并且做出成绩的,一起来看一下。

第一类:监控类

图片

监控类的需求很多,但做成项目就有一定难度了,因为很多时候业务方就是丢一纸临时取数需求,甚至一个电话过来口述一个朦胧的需求。这时候一定要做数据的同学自己打起12分精神了解需求背景。

1、新上线的业务

2、没有固定报表老业务

3、多次开展的测试/活动

都要和业务方坐下来详细聊聊,把业务流程,监控指标,关键KPI指标,定下来。至于输出形式可以看BI工具的完善程度和开发复杂度。能用看板的用看板,不能用看板的做自动化报表,总之把临时取数尽量干掉。

这样不但能形成良好的项目机制,也能避免业务方思考不全,隔三岔五地改取数形式,增加额外工作量。还能在有余力的时候关注下指标变化情况,为拓展其他项目铺路。

监控类的项目想出彩,就一定得整!花!活!比如老板号召今年要“数字化转型”,那先开发一个数字大屏摆在集团会议室里,把常规报表做个可视化看板。领导们一看:“嗯,不错,很数字化!” 这绩效就有着落了。

比如有重大活动,产品更新,第一时间先把监控报表整出来。发报表的时候做个海报,上书大标题“战报速递”,或者做移动报表,在微信群里群发一下,排面拉满,这绩效又有了。总之,做监控类项目,一定要“好钢用在刀刃上”,让领导们看得见,让领导们看得爽。

图片

第二类:评估类

图片

做评估本身并不复杂,定好评价标准,看实际数据表现是否达成标准即可。但是不同业务类型的评估,涉及的指标,评估方法可能不一致,因此要分开看。

常见的,比如:

1、对运营的:运营政策、促销活动评估

2、对产品的:产品功能、产品改版评估

3、对销售的:推广效果、渠道投放评估

评估类项目的核心在于:统一评估标准。

这里销售类的相对容易,因为销售收入/毛利/投放ROI是天然的判断标准。运营和产品的评估都经常出乱子。运营经常是想法太多,不设固定的评估标准,到底要不要设参照组,到底怎么算自然增长率, 每次活动都不一样。

这样搞不但没法积累分析经验,而且会给老板留下一个“你们不诚实,每次都是变着法说好”的坏印象。因此强烈建议在做运营评估的时候,先分好类,每一类内部能有相对规定的评估标准和评估指标,这样更有利于长期的工作开展。

图片

产品则经常是想法太少。让评估产品改版效果,你问他改版的目标是啥?想解决啥问题?想把指标提升到什么水平?他一口气回答三个“不清楚”,甚至有可能让做数据额“自己多想想”。还有的产品,做ABtest之前不考虑好如何控制影响因素,如何分层,做完了让数据分析师从测试数据集里再做分组对比……

图片

种种乱象,本质都是来自:业务部门缺少目标感,总想从数据里找对自己有利的部分报上去。因此,想要做好评估项目,是很需要数据分析师充分沟通,普及科学做法,逐步杜绝“看哪个数字高报哪个”的坏习惯的。当然,一些公司的产品/运营很强势,就是逼着你改到他满意,这时大家量力而行。

第三类:诊断类

图片

很多人眼中,诊断类才是真正的项目,但真到实操的时候,会发现:找一个有差异的指标,容易;真深挖问题原因,很难很难。因为大部分所谓:诊断分析,其实就是拿诸如性别、年龄、城市维度和指标做交叉,然后说:“发现A城市少了,所以A城市是问题原因。”然后被业务嫌弃:分析没深度!!!

图片

之所以出问题,是因为单纯的数据交叉,并不能直接回应业务的疑问。有些业务的疑问需要额外的采集数据,甚至需要测试几次才能知道答案。还有些情况下,面对问题业务可用的应对方案很有限,即使分析得天花乱坠,业务也没办法处理。

因此,想让诊断类项目出成绩,关键是和业务沟通好:

1、有没有分析假设?有的话,第一时间验证结果。

2、有没有应对方案?有的话,先验证是否管用?

3、有没有测试计划?有的话,看分几步测出答案。

图片

这样分析的时候,能直接回答业务的疑问,也能结合业务动作落地,是最容易表现出效果的。但是这么做,得业务方先破除一个迷信:“数据分析师能像算命师傅一样,只看几个数就得出结论”甚至有的数据新人自己也这么想,这就是自己给自己挖坑了。

第四类:预测类

图片

预测类项目是所有项目里最容易立项的,几乎每个部门领导都想你给他“精准预测一下XX”。预测类项目也是最容易翻车的。很多新人一看领导支持,觉得“可算接到大活了!”嗷一声就上了,然后被人嫌弃:“准确度不够,看不懂咋预的,你这有啥用啊!”搞得一地鸡毛。

这里有三个关键问题,在做项目时必须搞清楚:

1、业务拿到预测结果可以干啥

2、业务要不要参与到预测过程中

3、业务的资源投入,努力程度要不要作为预测变量

问题1要在项目开始前就和业务聊清楚,不但能清晰预测目标,而且保证结果有地方落地。

问题2则关系到预测方法选择。如果业务一定要参与预测过程讨论,那算法模型基本就废了,考虑把经营分析公式写出来,然后大家拍脑袋拍参数吧。

问题3则涉及“是业务先给投入假设”还是“数据先给结果”的问题。如果考虑业务投入力度,一定是业务先给假设,数据再出结果。当然也有可能是数据先给预测,业务根据预测考虑要不要追加投入。两种模式都行,但得事先说明,不然事后又是“你咋预测的不准!”“你预测完了我也不知道咋用”。

图片

所以真想让预测类项目出彩,难度非常大。往往是一些成熟的业务场景,比如外呼、风控容易做出成果。更多的目标不清、兴致起来就要预测的项目,常常会死在问题1上。因此做项目时一定要小心梳理。

第五类:治理类

图片

治理类工作是绝对的脏活累活,而是还是领导最看不到的那一部分。每个工作都喊着要搞“大数据”可你真把工作时间/人力资源都分过去了,大家又嫌弃你“支持业务不够”。更不用说产品催着上线埋点乱搞一通,运营自己写sql天天发明新指标口径,销售不按规范操作数据乱录……这都是老生常谈的问题。应对方法一大堆,落实不下去是常事。

所以大家经常选择“先污染后治理”或者“边污染边治理”,并且做这种项目,最好是“画大旗、蒙虎皮”,比如战略发展部牵头要各部门统一汇报口径,或者集团数据治理大项目,有个大旗扛在肩上,起码老板看得到。

第六类:计划类

图片

计划类工作往往和经营分析有关,在年头年尾,月度季度总结复盘的时候工作量比较大。这个活,很多同学不喜欢干,因为每次做预算、计划拆解,都会被各种领导抓住问这问那,改来改去。而且最后制定出的计划指标,可能也是领导们拍脑袋定的。做完以后,感觉自己的专业知识没啥增长,还很心累。

图片

但作为数据部门的领导,可能最想承接的就是计划类工作,虽然技术含量低,但这是一个直接服务大老板的机会。能多在大老板面前露脸,本身就是一个绝好的立功机会。

更有很多公司的数据部门领导,是靠着给大老板做计划上位的。所以不要错过这个机会,可以试着在做计划类项目的时候多和老板沟通,赢得老板信任。当然,有些公司老板行事太过严厉,你很难讨好他,那就另算。

另一方面,计划类工作在跳槽的时候也很好用。因为制定计划涉及整个公司经营分析指标体系,经营方向确认,通过计划类项目,能很好地建立全局认知,在面试官面前显得很有水平。

责任编辑:武晓燕 来源: 接地气的陈老师

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK