数据分析,你逃不掉的几大“坑”

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解一下

今天想写的主题是:数据分析 ,我一直觉得这属于很多人不知道Ta有多重要、一部分人知道Ta重要但并不重视,只有极少数人真正在工作中重视Ta并且运用Ta。

说一个东西重要,肯定要讲为什么,不然绝对是要被拿着刀追几条街的。

那么,数据分析为什么重要呢?至少有以下好处:

  1. 相比“似乎”、“好像”,能够更加客观的呈现真实现状;
  2. 相比“我以为”、“我觉得”,数据的改变是对产品”改变”做出的最直观、最无声的投票,数据可以佐证“改变”是否正确、恰当以及效果如何;
  3. 相比所谓的“经验”、“年纪”、“职位”,数据能够排除掉这些太不可控的“主观”的影响/压力,作为另一个相对客观的决策依据;

说的更加大白话一些的,那就是:

  • 你刚接手个新业务,搞不清现状,小伙伴也东一嘴西一嘴的讲的碎碎的,你可以看数据;
  • 如果你想做某个需求,人家不给你做,你可以甩数据给他看,证明需求的必要性;
  • 如果你不想做某个需求,但人家硬要你做,你还是可以甩数据,证明需求无意义或者效果不理想;
  • 如果你做了需求不知道要不要继续迭代下去,你还是可以看数据,去看用户的无声投票如何;

数据是产品、运营、技术日常装备中必不可少的矛和盾。至于什么时候是矛,什么时候是盾,那就看不同场合不同情况了。

// 补充:数据分析辅助决策,但并不是决策的唯一要素。我并不鼓吹数据分析天下第一,请注意,合理使用才是王道。

数据的最大天坑

数据分析,字面意思,数据分析由两个部分组成:一是数据,二是分析,看起来跟废话一样,但却也是绝大多数人都忽略的。

大多数人在讲到数据分析的时候,更加注重的是分析,而并不是数据本身,这就造成了数据分析最大的误区:不关心数据怎么来,使劲儿做无用功

举个简单的例子呗?

在App的新版本上,产品经理新加了个子频道。版本上了一段时间数据稳定后,产品经理从数据发现,哎哟,这个子频道很吊炸天啊,点击率、登录比等数据同比甩其他子频道N条街啊,恩,说明这个子频道用户很需要呀,以后要接着往这个方向上做。

看似,产品经理好像做了正确决策吧?

然而,oh,no,不幸的消息来了!

程序员在数据埋点的时候不小心埋错了,他把另一个热门子频道的数据和这个新频道埋在了一起,数据计算的是这两个频道的总和!(抱歉,程序员又一次实力背锅,之后会为你们正名)

因为错误的数据,得出了错误的分析结果,并且还做了后续错误方向的工作,这在日常中其实并不少见,虽然真的很蠢。

有效数据分析的前提,是对正确的数据做分析。

分析的最大天坑

数据怎么来的,是基础。得来的数据怎么分析,是进阶。光有数据不分析,假把式,还糟蹋了人家的SQL。

这就引来了一个重要问题:为什么要分析?

  • 用基本的分析去了解现状以及趋势;
  • 用针对的分析去验证或者踢翻自己的想法;

看似很简单,实际做起来却一点儿都不简单。又要举个常见例子呗:

新版本发布了一段时间,数据也稳定了,产品经理让实习生A、B、C分别做一份用户对新版本各项修改内容的数据分析反馈报告。

实习生A:这个简单啊,数据组的同学一定有数据,拿过来就是了。

最后他把各种原始数据表发给了产品经理;

产品经理内心独白:X,我要你有个啥用?

实习生B:这个工作,数据同学说不定已经做了,直接找他问就好了嘛。

最后他把数据挖掘童鞋的口述内容写成了报告发给了产品经理;

产品经理内心独白:虽然比之前的那个好,但依旧X,你自己的脑子呢?

实习生C:这个报告不是那么好写的,至少得:

  1. 看下新增、优化、影响了哪些地方做重点观察;
  2. 围绕着这些地方,分别列好目标和可能的猜想;
  3. 找数据挖掘童鞋聊并且记录根据他的角度数据处于什么样的情况,还得记得拿原始数据;
  4. 自己再做一次针对性的数据分析工作;
  5. 得出一些结论,保留一些疑惑等;

最后他把根据以上步骤得出的观点做成了报告发给了产品经理,同时附带了原始数据的各种变形计算;

产品经理内心独白:这个上道,可以的可以的。

实习生A、B其实都属于没有搞清楚为什么要分析,分析的目的到底是什么。没有想清楚这一环节,自然给到的分析结果也没什么用了。

分析目的是指南针,只有方向对了,后续的各种分析方法以及分析结果才有意义。

上文举的例子,其实一部分说明了数据分析过程中除了以上两大坑之外的一些其他小坑坑,下面也来简单列一列:

1. 小团队的数据正确性很难被保证

这个就是上文举例的时候我说会为开发同学正名的部分。大公司暂且不说,毕竟,光是数据支持团队就比人家小公司一整个团队的人还要多了。

小公司往往没有资源去组建自己的数据团队,这个时候就要使用各种第三方的统计软件来做数据埋点。然而,各个统计软件又有各自的问题:

  • GA:需要翻墙,数据会计漏;
  • 百度:额,不说了;
  • 友盟:统计大的数据ok,但是在细致的用户行为方面就比较菜了,代码埋点也是个坑,数据也不图表化!(好久前用的,可能现在已经慢慢有图表了吧?);
  • fabric:和友盟其实差不多,但是强在程序报错上,另外数据图表化做的也是很炫酷,但,还是坑爹的代码埋点;
  • growing io/诸葛io:强于细致的用户行为数据分析,同时宣称可以无代码埋点。然而无代码埋点又是另一个不亚于代码埋点的大坑,必须符合他的框架写法才行,不然数据统计不上或者出错。然而,框架写法又没有明确的文本说明,开发也不一定能改掉自己的写法。另外,细致的用户行为数据分析,在实际分析操作上也是很蛋疼的;

完蛋,扯远了,这块如果感兴趣,可以专门搞篇文章写写。想说的是,代码埋点会产生很多问题,例如:

  • 可能因为不同程序员的页面代码写法不同,计算结果不同;
  • 可能因为埋点过程中没有沟通好,出现理解偏差,计算结果不同;
  • 可能因为开发不小心埋错点,计算结果不同;
  • 可能因为版本迭代修改了某个地方,导致计算结果不同;

非常多可能性,导致埋点错误,从而导致数据错误。每次看移动端数据,都要ios和android端一起对着看,谁能懂?特么的跟侦探一样样的。

2. 存在已久并不代表一定正

这个存在已有,不仅是指数据,同样也指分析结果。

某个数据存在已有,所有人都对Ta没有质疑,这就能说明这个数据没错了么?

其实不一定哦,也许这个数据从未被人注意过,也有可能大家都把质疑数据的正确性这个前提给忽略掉了。

所以,如果在分析的过程中发现,数据的横向对比或者纵向对比,结果存在一定的违背,那么这个时候就要注意了。

至于分析结果的存在已久嘛,没啥好说的,产品功能、产品运营手法都有可能导致数据的大变动,分析时段自然要比较新鲜才有用。

3. 数据条件很重要

数据条件是什么意思?说白了就是放在数据这两字前的定语,即:什么样的数据。(这是定语还是形容词,傻傻搞不清)

举个例子:

极度活跃用户、一般活跃用户、不活跃用户、沉默用户、流失用户。在用户之前的字就是数据条件。

为啥说数据条件很重要呢?原因在于不同条件的数据在各项指标上可能都会差异非常大,而无法用简单的均值来做概括。例如极度活跃用户在活跃天数、活跃时长、日活跃次数、留存率等上都会甩掉其他用户好几个级别。

当然,更为日常的情况是,在和数据同学沟通的时候,一定要先确保大家的沟通前提处在同一条件下,不然很可能出现的情况是:拿到的数据是正确的,但是条件是偏差的。

4. 第一手分析很重要

很多小伙伴喜欢偷懒,觉得有数据挖掘同学分析数据就可以了,但其实并不是这样的。

其一:除了数据本身是客观的之外,对数据做的任何处理都是主观的,不管是用模型还是各种数据之间的变形计算,都是主观的,差别在于主观的程度多少而已,每个人都会站在自己的背景知识去处理数据,如何保证别人的和自己相同呢?

其二:在分析数据的过程中,一般来说,各种横纵向对比,是可以发现一些自己之前没有注意过的结论的。而这点,别人帮你分析的过程中,一般这些信息无形中就不见了。

5. 分析具有联动性

绝大多数情况下,单独看某一个数据,一般意义不那么大,或者说达不到更好的效率。

举些例子:

  • 评价某模块做的好不好,只看绝对uv,而不同时看模块登录比,介是耍流氓;
  • 评价内容做的好不好,只看生产的绝对量,而不同时看不同类型内容的分别用户uv占比/生产量,介也是耍流氓;

联动的看数据,才能更加综合的去判断。

感觉写的差不多了,那就先这样呗?虽然还有一些其他小坑,哎哟,以后再写吧。再熬夜,感觉一周都要缓不过去了。

题图来自 Unsplash ,基于 CC0 协议

#专栏作家#

瑶子,微信公众号killifer,人人都是产品经理专栏作家。原选股宝首席打杂PM汪,现某厂打杂运营喵。从0到1分别做过产品和运营,相信懂业务懂人性的商人才可能是个好产品运营。

本文原创发布于人人都是产品经理。未经许可,禁止转载

给作者打赏,鼓励TA抓紧创作!
6人打赏
评论
欢迎留言讨论~!
  1. 啊,各种数据采集方式的优劣势对比,评论竟然不能配图。有需要的朋友可以私聊我或者加我微信hhhcccmmm

    回复
    1. 另外,所有的分析产品都有一定的优劣,还没见过有哪一款产品在整个数据分析链路上做到100分的。当然,我们也不会去苛求这件事,一般的分析童鞋都是取几款数据平台的各自长处一起使用的。

      针对我提出来的一些体验问题,不需要太过介怀。

      回复
  2. 首先,关于作者文中提到的数据分析的第一大误区,我个人表示赞同:不关心数据怎么来,使劲儿做无用功。确实,在做分析之前的上一层,一定是数据来源或者是采集的准确性,这也是我们服务客户过程中在采集这块儿着重强调的,比如采集时机的重要性,团队内部的信息通畅。对于文中提到了诸葛io的部分,可能我会从以下两个方面做些说明:
    一、关于采集
    诸葛io 主张代码采集,(我们在市场层面从没有主打过可以无代码埋点)虽然我们今年也支持了全埋点、可视化埋点,但我们认为他有不同的应用场景,后两者我们建议用在落地页、或产品页面体验层面的衡量,这些页面对数据偏统计需求,或者因为量太大加上开发资源紧张等等。更重要的一点是因为代码埋点的准确程度、精细化程度以及对数据的二次可用性都要远远优于后两者。
    关于目前的几种数据采集方式的优劣势如下图:

    二、关于提到的代码埋点的问题
    从文中罗列的几个问题来看,其实都不是这项技术本身的问题,都可以通过内容沟通和协同解决。因为就目前看来,没有比代码埋点采集到的数据更准确了,以“注册按钮”点击为例,通常我们判断用户注册成功需要请求服务器,当服务器返回注册成功的判断时才会记为这个按钮成功触发了,而通过可视化埋点只能采集页面元素的点击情况,也就是不管你有没有输入手机号验证码,只要这个按钮可点击,用户一但点击,就会+1,如果通过这个按钮的点击情况确定注册人数肯定会有误差。但恰恰是代码埋点的灵活性,你可以采集click,也可以等服务器判断成功了再记,那这个过程中最大的问题就是需求提清楚,需求是采集click就行还是需要准确的注册,直接影响这段代码放哪儿。
    不能直接判断准确与否,准确是建立在明确了某个数据是在什么样的背景条件下来的就是准确的。
    在从需求到采集到测试到正式环境发版,我们有一套完整的团队协作流程。这可以最大程度的避免文中提到的问题的发生。

    以上~

    回复
    1. 抱歉,可能是我行文略有不当导致您产生了误解,我可能需要解释一下哈:

      1、针对埋点我列出了非常多的问题,但是并不代表我否认这个技术。诚如你所说,代码埋点依旧是最精准的;

      2、虽然代码埋点准确,但是我列的是人在使用这项技术的时候会出现的问题以及不容易被注意到的易产生数据错误的非技术原因。这个我认为依旧是非常有必要提醒相关的分析童鞋的。技术没有对错,但人的使用方法是有对错、有使用性能问题的。指出认为因素,并不是说不要用,而是说要注意的用;

      3、针对诸葛io采集数据的技术问题,确实是我的行文使用的专有名词不当,我文中所提到的“无代码埋点”的意思基本等于你所说的“全埋点、可视化埋点”,想要表达的意思,也确实没有明说,只是一笔带过,意思就是区别于代码埋点的另一种新的方式,可以达到基本不需要再让程序员做一一的点对应埋点,而是可以加入一个sdk包引入相关的埋点资源,让数据同学可以通过一定的界面去自行配置所要监测的位置,这样的一种方法。这个方法确实有一定的优势,但同时,我所说的问题也都存在。

      回复
  3. 观点不错,但后面扯得有点远,最大的坑,不是在数据产生之后,而是需要什么地方出产数据,产品经理必须要明白各个埋点的作用,尤其在开始阶段切忌大而泛,自己曾经就有痛苦的经历,在第一版本已经提出了非常多的需求,虽然都很有用,但研发写代码都忙疯了,还要照顾如此之多的埋点,真正上线的时候经常出现缺胳膊少腿的情况,经常是缺失了某项导致原来构想的全盘逻辑缺失。因此需要在各个版本首先明确核心的目标,逐步完善分步实施,用数据证明需要更多的数据,把大家的胃口都调动起来,整个数据分析工作才能更加有条不紊的展开

    回复
    1. 对的,这个其实也可以单总结一篇。我个人觉得吧,大而泛不是最大的坑点,而是大但数据链路不顺,也就是在埋点之前,只是觉得说要埋点也不知道为什么,所以会出现各个点都埋,可能数据还丢失的情况。如果在一开始就想明白要验证的用户链路是怎么样的,这链路上有哪些点,然后再去埋点,这样就会稍稍避免一些问题。
      另外,区分优先级、把握粗细粒度确实是很大的坑点,这其实包含在文章中说的“分析的目的”,您说的很有道理,我周末就总结下这块的内容,希望到时候可以再探讨一下,嘻嘻~

      回复
  4. 沙发点赞。 :smile:

    回复