数据驱动的产品优化:产品经理要知道的数据收集流程

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

在产品工作中,一个完整的数据收集流程是怎样的呢?本文作者将一步一步为你解答,enjoy~

通常我们在需要对某块业务做数据分析之前,首先都要解决数据收集的问题。在没有大数据团队的支持或者完善的数据分析系统支持的情况下,产品经理需要根据实际需要,自行解决数据收集和数据分析的问题。有些小伙伴会觉得无从下手,也有的产品本身计划着要去做数据系统,但当前产品完善阶段的数据分析诉求又比较迫切,害怕单点的数据收集会打乱整体的数据系统建设。

其实数据分析永远都是以目标为导向的,分析的目的是什么,进而确定需要用哪些数据来分析,数据怎么来,最后就知道去哪里收集了。完善的数据抓取系统只不过是抓取的数据量比较大、比较多而已,真正要让数据发挥价值,都不是数据本身驱动的,而是分析目标驱动的。那么一个完整的数据收集流程是怎样的呢?

确定数据分析的目标

没有目标的数据分析才真的是无从下手。有了明确的目标导向后,数据收集的范围和着手点就比较明确了。现实工作当中,一般都是遇到了问题,需要去解决问题的时候,想出来的解决方案就可以成为数据分析的目标。

比如当下订单的下单量虽然多,但是支付转化率比较低,大部分订单都被用户取消掉了,这里就有一个问题:订单取消的占比太高。通常我们会有两种做法:

  • 一是联系那些取消订单的用户访谈一下取消的原因;
  • 二是通过产品本身记录的用户取消订单时选择的原因来分析。

这里的第二种做法就是数据分析的目标了,通过用户取消订单时选择的原因来分析取消订单的问题,从中找出问题的关键点,再针对性的出优化方案。

这里也会有一个前提,就是对业务流程的把控和梳理要比较清楚。假如对订单流程比较陌生的,可能就会从优化支付成功率的角度去分析,而不是从减少订单取消的角度去反向分析。产品经理要对自身所负责的业务比较敏感,才能发现问题。

分析需要收集哪些数据

明确了数据分析的目标之后,就需要确定采集哪些数据来分析。目标可以告诉我们范围,比如取消订单的操作场景下会涉及到哪些页面;进一步的要确认这些页面上有哪些表单数据、操作按钮、页面跳转是需要记录操作事件的。

一类是原先没有的操作事件,需要先行添加后才能记录数据的。比如订单取消的原因选择,如果原先产品设计的时候都是直接取消,那就需要先把取消订单时选择原因这个功能加上,并且筛选出一些可能会到导致用户取消的原因供用户选择,也提供自定义输入的选项。

一类是已有的操作事件,需要确认在什么条件下记录数据。比如订单取消的原因,在用户单次操作提交之前,选择各个原因之间的切换日志是不需要记录的,因为用户尚未提交,未决定是哪个原因;但如果是用户二次操作(修改/编辑、流转回来再次提交等)时变更了原因,这个切换日志是需要记录的,因为两次操作之间可能有某种外力导致用户改变了选择的初衷。

这个分析的过程一定要仔细,产品经理要从用户操作场景的角度去考虑,中间涉及到表单信息变更、按钮操作、页面停留和页面跳转、业务流转等等,都需要仔细去分析。分析的原则就是有用的数据才收集,尽量减少无用数据的收集,数据系统的建设也不是大而全就一定好。

考虑每个数据收集点的成本

数据埋点是有成本的,最直观的就是在性能上会带来比较大的影响,现在也有一些无埋点的采集技术,本人没有做过相应研究,这里只以需要埋点采集的来说明。一般我们从以下几个方面来考虑成本:

  1. 处理能力。增加埋点之后对原有页面、按钮的处理效率会有多大的影响,如果数据抓取的效率不够高,对业务造成影响的,是要综合评估的,特别是那些对反馈要求比较及时的地方。
  2. 响应时间。操作事件发生后到收集到数据的时间,主要考验埋点代码的执行效率,一般都会要求同步抓取,异步清理,数据下来以后再想办法去做额外的计算和处理。
  3. 资源投入。埋点对开发资源和测试资源的消耗,埋点比较复杂的,自然投入的资源就会比较多,要综合评估各种埋点方案,选择最优的。
  4. 数据质量。明确埋点收集数据的格式、含义、有效性约束等等,尽量确保收集下来的数据都是有利用价值的。

以上四个方面要综合考量,埋点的方案现在也比较多,选择一种最合适的。产品经理如果不太清楚的,可以让技术人员代为评估。

别忘记添加注释

增加了数据埋点之后,千万别忘记添加注释,最怕的就是后面接手代码的人把他认为多余的代码给去掉了,会导致数据收集不完整,因为数据收集需要持续比较长的一段时间才会有分析的价值。同样的代码一般都不会只有一个人在维护的。

另外就是方便后续的优化,当发现收集下来的数据与预期不符,需要优化埋点或者调整埋点位置的时候,有注释就轻松多了。

这一点主要是要提醒技术人员注意,产品经理要关注收集的过程,最好在测试的过程中就能发现埋点的问题,然后在上线前优化掉

考虑是否允许获取对应的数据

这一点主要是考虑到用户隐私权的问题,有些数据比较敏感,需要在产品的隐私权政策里面去约束和强调。为什么这点放在最后考虑呢,也是因为有些数据没抓取下来不知道,看过数据分析之后才知道是否会涉及到隐私权。产品经理一定要有这方面的意识,现在对于用户隐私权的管控越来越严了。

总结一下,区别于大数据系统的体系化搭建,这样的数据收集流程是相对小范围的,以优化或者解决问题为目的,产品经理在日常产品优化的工作过程中都可以应用。

特别要注意的一点是,WEB端和移动端的差异,在考虑方案的时候,移动端对性能、抓取的数据质量等各方面要求会更高一些,也是因为移动端的操作场景会更复杂,上拉、下滑、左滑、右滑等等,很多操作场景WEB端是没有的,需要区别对待。

#专栏作家#

华仔,微信公众号:zeropm,人人都是产品经理专栏作家。历任阿里巴巴、1号店、盛大网络资深产品经理,现任美平米电商产品产品总监,合著有《运营前线》、《产品前线》、《互联网产品之美》,译著有《人人点赞:让APP瞬间疯转的绝妙文案》。11年产品经理工作经验,专注于在线教育和电商产品方向。

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

题图来自 Pexels,基于 CC0 协议

打赏也是一种认可
5人打赏
评论
有话不说憋着难受!