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

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

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

确定数据分析的目标

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

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

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

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

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

分析需要收集哪些数据

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

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

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

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

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

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

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

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

别忘记添加注释

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

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

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

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

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

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

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

#专栏作家#

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

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

题图来自 Pexels，基于 CC0 协议