这才是真正的数据分析项目

---

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

第一类：监控类

监控类的需求很多，但做成项目就有一定难度了，因为很多时候业务方就是丢一纸临时取数需求，甚至一个电话过来口述一个朦胧的需求。这时候一定要做数据的同学自己打起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天天发明新指标口径，销售不按规范操作数据乱录……这都是老生常谈的问题。应对方法一大堆，落实不下去是常事。

 

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

第六类：计划类

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

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

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

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

加入CPDA，拥有更完备的数据分析能力！

---

---