数据分析会犯的错误,新人十有九中

作者:接地气的陈老师

-----------------------------------------------------------------

讲一个很严重,很明显,但是很容易被新人们忽视的错误:把要求当需求。最最最典型的,某过于老板丢了句“做个用户画像看一下”于是数据专员吭哧吭哧跑数据,做词云,画图标,码PPT。忙得不亦乐乎。最后辛辛苦苦交了用户画像的报告。老板一句话劈头盖脸丢过来

“我早知道了”

“你做了有什么用”

“这不是我想要的”

那感觉,简直就是一盆冷水泼下来,一口老血涌上头。好想拿出录了“做个用户画像看一下”的录音笔查到丫耳朵里。这还是好的呢。如果碰到一个不怎么懂的话题,比如“做个聚类分析”“做个因子分析”,可能跑数的小哥还得到处找资料,查书,上各种《数据分析爱好者》QQ群问:“有没有大神教一下怎么做啊??”结果回来还是碰壁,就真的气不打一处来了。

问题出在哪里?问题出在从一开始,这就不是需求,而是一个要求。并且它是出自非专业人士的要求。举个类似的例子,就好比病人去医院看病,对医生说:“来个感冒药”然后回头说医生“你这药不灵啊!你这医生会不会看病啊!”你说这医生当的冤不冤。

冤,也不冤。冤,是冤在明明是病人自己要求的,我按你说的办,为啥让我背黑锅。不冤,是因为大家默认了医生就是专业人士,doctor的另一重含义就是博士,为什么一个专业博士要听不懂医的人安排呢?所以作为专业人士,就得提专业意见。而不是听风就是雨。就算病人指名道姓的要感冒药,你也得问他到底是什么病,对症下药才是正道。

具体到数据分析上,类似“用户画像”“聚类分析”“回归算法”只是具体的分析工具,而不是要分析的问题。领导要求看用户画像,可能是因为之前不了解我们的用户群体特征,想要看个概况;也可能是因为对某一类用户有了思考,想看深入分析。这里要我们进一步去挖掘需求,而不是停在表面。具体来说,可以按思路如下图所示:

先确认做这个的目的是什么,是不是想了解用户?是不是了解用户有具体问题?摸清底细再动手

这样一层层开展,不但能弄清楚问题到底是什么,而且可以顺便了解下领导期望值。哪些是已知的结论,哪些是未知领域搞清楚,就可以避免“我早知道了”的尴尬。把真正的问题找到,就能避免“你做了有什么用”的窘境。两者结合,自然是做出“我想要的”结果。

这样做的另一个好处,是聚焦问题、排除干扰。对于“用户画像”这种可大可小的问题特别合适。因为一提到“用户画像”,大家都会想到一堆用户相关的指标,问题是:我们有没有这些数据?我们有的数据靠不靠谱?是不是解决问题一定需要这些数据?如果不聚焦问题,做出来的东西没有用还是小事。为了搞这个没有用的东西而大费周章,劳民伤财,最后还不落好,就是大事了。当然,业务方可以随口一说:我们需要用“大数据用户画像”解决XX。但做数据的同学们,就得特别小心观察,到底用哪些数据,具体到一个个字段。

再进一步的讨论,可以看业务方解决问题的限制。因为实际上能解决问题的手段非常有限。比如业务方想了解“高端用户”的画像。很有可能连这些人开什么车,吃什么馆子,看什么报纸,蹲什么茅坑都想知道。问题是知道这些维度又能怎样?去厕所门上刷小广告“枪支麻药迷昏剂”吗。这种接近窥探隐私的、超细节的分析,更适合用调查的方式进行。数据分析基于内部系统采集数据,还是更适合做基础性的常规采集。这时候可能聚焦:高端用户从什么渠道进入,有什么消费习惯,对哪些品类更忠诚,更容易输出有价值的结果。

一提到用户画像,大家就像各种稀奇古怪的字段,可聚焦到一个问题,比如促销费的问题,这些字段远没有获客渠道、产品组合、营销活动这些字段管用

类似的问题还有很多,比如“做一个判断模型”“做一个聚类分析”“做一个回归预测”这些都是具体的要求,而不是需求。遇到这一类问题,一定要打起十二分精神,问清楚:

  • 做一个模型用来解决XXXX问题?(真实痛点)
  • 这个问题有没有预判或假设?(真实困惑)
  • 解决问题的时间、方法有没有限制?(可行性)

这样摸清底,后续就会做出

  • 很想要的(真实的痛点才真实想要)
  • 眼前一亮(解决了真实的疑惑)
  • 非常有用(考虑了执行可行性)

的分析成果。废话,我们已经到他们知道什么不知道什么吗。很多同学苦思冥想,试图想出一个业务方见都没见过的东西,以为这样才算是分析的高深。殊不知,真要丢出这种结果,十有八九会得到一个:“太离谱了,不符合业务逻辑”的评价。其实好的分析成果不一定复杂,不一定异想天开。答疑解惑,药到病除,才是最好的状态。

其他的问题还有很多,限于篇幅,回来慢慢分享,之所以只说了这一个,因为这个是方向问题。是头等问题。这个问题不解决,只怕后续的问题会越来越多。可恰恰在这里,新人们往往不敢深入讨论,怕被鄙视能力不行,怕被人给脸色。可为什么老手们不怕呢?一来是被坑多了,知道为了面子拿自己去填坑不值当。二来是表达技巧会更好,一图以蔽之,看下边。

了解需求和审问需求方是两个问题,板着脸问:“你为什么要这个数”肯定被人骂,沟通方式可以灵活机动。当然,如何沟通,是另一个复杂的问题了。

对了,开头的问题已经很有技术含量了。至少提需求的时候提了“用户画像”四个字。更惨的场面,可能是这种:

“那谁谁,我要个数”

这时候就得更加小心了哈。本质都是一样的,这也是个要求。然而又有很多同学听到要个数,就急匆匆的跑数去了……o(╯□╰)o

原文地址:https://www.cnblogs.com/luoluo-123/p/10127721.html

时间: 2024-11-09 03:22:50

数据分析会犯的错误,新人十有九中的相关文章

Python新人常犯的错误有哪些?

Python 以其简单易懂的语法格式与其它语言形成鲜明对比,初学者遇到最多的问题就是不按照 Python 的规则来写,即便是有编程经验的程序员,也容易按照固有的思维和语法格式来写 Python 代码,有一个外国小伙总结了一些大家常犯的错误,我把他翻译过来并在原来的基础补充了我的一些理解,希望可以让你避开这些坑,更好的学习python. 0.忘记写冒号 在 if.elif.else.for.while.class.def 语句后面忘记添加 ":" if spam == 42 print(

犯个错误 在派出所跳楼,至于吗,这样不是给我们民警抹黑

mnesia在频繁操作数据的过程可能会报错:** WARNING ** Mnesia is overloaded: {dump_log, write_threshold},可以看出,mnesia应该是过载了.这个警告在mnesia dump操作会发生这个问题,表类型为disc_only_copies .disc_copies都可能会发生. 如何重现这个问题,例子的场景是多个进程同时在不断地mnesia:dirty_write/2 mnesia过载分析 1.抛出警告是在mnesia 增加dump

转:学习为了什么?我一直说学习是为了学会更好的思考,其实更通俗的讲学习是为了避免犯大错误

㊣华哥日记㊣ 3.22 学习为了什么?我一直说学习是为了学会更好的思考,其实更通俗的讲学习是为了避免犯大错误,兄弟姐妹们,你们知道一个大错误可以让我们浪费几年甚至十几年吗,人生承受不住大错误,可我们大多数人懒于思考,每次在深圳都会听到各种悲剧的故事,张三和王二十年前合伙做生意赚了500万,平分分赃,张三在龙岗买了一块地,王二回老家盖了个房子,现在张三亿万家财,王二在深圳还在租房!深圳之行见了很多米粉,生意上质一样的进步,可是他们中去年选择置业的明显更幸福,没置业的不是没能力,真的,他们去年缺乏一

信息安全事故中企业常犯的错误

古语云:"亡羊补牢,犹未为晚".随着信息化的飞速发展,企业的信息安全正受到日益严峻的挑战,近年来,很多大企业都遭受到了攻击而泄露数据的事故,更何况一些中小企业或个人.最近的iCloud信息泄露事件,不仅"坑到"了众多好莱坞女星,也再一次在信息安全领域拉响了数据危机警报. 企业在受到攻击数据泄露后,尤其是对外部,如果不能正确处理,将导致事态恶化,并对企业品牌.业绩造成二次打击,更有甚者会带来进法律风险.如何有效的处理,这其实是<信息安全管理实施指南>即IS

C#新手常犯的错误汇总

本文所述为C#新手常犯的错误,但是实际上很多有经验的程序员也经常犯这些错误,对此特别整理了一下,供大家参考.具体如下: 1.遍历List的错误 ,比如如下代码: List<String> strList =newList<String> for(int i =0; i<strList.Count; i++) { strList.RemoveAt(i); } 这段代码看上去是删除了所有元素,实际上每次调用RemoveAt方法会导致List元素索引重排,最后导致元素没有完全删除.

初学C语言编程时最容易犯的错误,你踩坑了吗?

C编译的程序对语法检查并不像其它高级语言那么严格,这就给编程人员留下"灵活的余地",但还是由于这个灵活给程序的调试带来了许多不便,尤其对初学C语言的人来说,经常会出一些连自己都不知道错在哪里的错误.看着有错的程序,不知该如何改起,通过对C的学习,积累了一些C编程时常犯的错误,以供参考. 1.书写标识符时,忽略了大小写字母的区别 main() {  int a=5;  printf("%d",A); } 编译程序把a和A认为是两个不同的变量名,而显示出错信息.C认为大

嵌入式软件容易犯的错误和规避方法总结

当今世界,放眼江湖,有电子的地方就有嵌入式软件,有电子故障的地方,也就有嵌入式软件设计缺陷的影子.那么捷配小编今天就把软件所容易犯的错误和规避的方法一一罗列,并给出应对之法.嵌入式软件的最大特点是以控制为主,软硬结合的较多,功能性的操作较多,模块相互间调用的较多,外部工作环境复杂容易受到干扰或干扰别的设备,且执行错误的后果不仅仅是数据错误而是有可能导致不可估量的灾难,所以总结起来,嵌入式软件可靠性设计需注意的问题有四个方面:1.软件接口先说软件接口中容易出问题的地方和编程人员容易犯的错误.软件接

PHP二维数组的引用赋值容易犯的错误

大家一起来分析一下下面这段代码: <?php $arr = array(); $arr["abc"] = array("sex" => 100, "age" => 18); $arr["bcd"] = array("sex" => 200, "age" => 19); $arr["cde"] = array("sex"

表单提交时如何将错误信息传递到页面中,并且保存原来提交数据

曾经何时,你还有我或许都在困惑,如何方便的将验证不通过的表单信息再返回到前台页面,例如我注册一个账号,辛辛苦苦填写了N多项,一个格式验证没有通过,一切都需要充填,虽然Ajax可以解决这个问题,但是我们总不能把所有表单提交都弄成ajax,更何况有若干人就是没事把javascript给禁止了.哎哎,好了解决方案来了,下面以用户登录为例,说说我的解决方案. 服务器端用nodejs实现: login.html 简单的提交表单 <form action="" id="loginF