“埋点”到底要不要?——源自数据采集的痛苦、幻想与失望

admin 2019-10-06 19:14

  3周带你玩转Excel!在行第一行家手把手带学+作业实战+答疑辅导,升职加薪快人一步,了解一下

  随着移动互联网时代的兴起和数据量的大规模爆发,越来越多的互联网企业开始重视数据的质量。在我创业的这一年里,接触了 200 多家创业型公司,发现如今的企业对数据的需求已经不仅仅局限于简单的 PV、UV,而是更加重视用户使用行为数据的相关分析。

  做数据的同学都知道,在数据分析的道路上,数据采集是重中之重。数据采集的质量直接决定了你的分析是否准确。而随着企业对数据的要求越来越高,埋点技术也被推到了“风口浪尖”。所谓,埋的好是高手,埋不好反倒伤了自己。而在数据采集的道路上大家经常会遇到各种各样的问题,今天我们就来分析一下埋点是否需要。

  但是,对于现在一些涉及订单交易类型的产品,仅仅宏观的简单统计数据已经不能满足用户的需求了,他们更加关注一些深度的关键指标分析,例如:用户渠道转化、新增、留存、度交叉分析等。这个时候才发现第三方统计工具很难满足对数据的需求,而出现这样的问题并不是因为工具的分析能力薄弱,而是因为这类工具对于数据采集的不完整。 通过这种方式 SDK 只能够采集到一些基本的用户行为数据,比如设备的基本信息,用户执行的基本操作等。但是服务端和数据库中的数据并没有采集,一些提交操作,比如提交订单对应的成本价格、折扣情况等信息也没有采集,这就导致后续的分析成了“巧妇难为无米之炊”。

  但不足之处有两点:一是业务数据库在设计之初就是为了满足正常的业务运转,给机器读写访问的。为了提升性能,会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表,这些表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时间搞懂了,隔天工程师又告诉你因为性能问题拆表了,你就崩溃了。另一个不足之处是业务数据表的设计是针对高并发低延迟的小操作,而数据分析常常是针对大数据进行批量操作的,这样就导致性能很差。

  这种方式相较于第二种,完成了数据的解耦,使业务数据和统计分析数据相互分离。然而,这种方式的问题是“目的不纯”。Web 日志往往是工程师为了方便 Debug 顺便搞搞,这样的日志对于业务层面的分析,常常“缺斤少两”。并且从打印日志到处理日志再到输出结果,整个过程很容易出错,我在百度就花了几年的时间解决这一问题。

  聊完采集方法,再来说说关于埋点的管理。我曾经接触了一家做了七八年的老牌互联网公司,他们的数据采集有 400 多个点。每次数据产品经理提出数据采集的需求后,工程师就会按照要求增加埋点,然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常,可等产品上线之后,才发现埋的不对,再进行升级发版操作,整个过程效率极低。我们发现,一个公司发展到了一定程度,没有专人去负责埋点管理工作,数据采集就完全没有准确性可据采集就完全没有准确性可言。甚至有时产品上线之后,才发现数据采集的工作没有做,也就是漏埋了。

  在 2010 年,我的团队曾经做了一个叫 ClickMonkey 的产品,只要页面上嵌入 SDK,就可以采集页面上所有的点击行为,然后就可以绘制出用户点击的热力图,这种方式对于一些探索式的调研还是比较有用的。到了2013 年,国外有家数据分析公司 Heap Analytics,把这种方式更近一步,将 App 的操作尽量多的采集下来,然后通过界面配置的方式对关键行为进行定义,这样便完成了所谓的“无埋点”数据采集。使用这种方案,必须在产品中嵌入 SDK,等于做了一个统一的埋点,所以“无埋点”的叫法实际上是“全埋点”的代名词。

  最后,我们再聊一聊数据采集中遇到的非技术性问题。一般来说,公司到了 A 轮以后,都会有专门的数据团队或者兼职数据人员,对公司的一些业务指标负责。即使为了拿到这些基本的业务指标,一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了,天下武功唯快不破。于是所有事情都要给产品迭代升级让路,快的都没有时间做数据采集了。殊不知没有数据指标的支撑,又怎么衡量这个功能升级是不是合理的呢?互联网产品并不是功能越多就越好,产品是否经得起用户考验,还是要基于数据说话的,然后学习新知识,用于下一轮的迭代。

  数据采集和数据分析。可不能只看到数据分析而忽略了数据采集。事实上我个人在百度做数据的几年里,最大的心得就是数据这个事情要做好,最重要的是数据源,数据源收集得好,就成功了一大半。数据采集的基本原则是全和细。全就是把多种数据源都进行采集,而不只是客户端的用户数据。细就是强调度,把事件发生的一系列维度信息,比如订单运费、成本价格等,尽量多的记录下来,方便后续交叉分析。

  对于埋点混乱的问题,前面提到的数据架构师的角色,要对这块的管理负责。如果前面完成对 Event 的梳理,这里的埋点就会清晰很多。另外还要推荐尽量从后端进行埋点,这样便无需多客户端埋点了。当然,如果有行为只在客户端发生,还是要在客户端进行埋点的。对于业务复杂的情况,只有负责人还不够。目前我们神策分析针对这个问题,推出了埋点管理功能,对于每个采集点的数据收集情况,都能够做到全盘监控,并且可以针对一些无效采集点进行禁用。总之是希望把这个问题尽量好的解决掉。

  对于数据团队和工程团队的配合问题,我这里是想说给创业公司的创始人听的。两个平行部门间的推动,是很难的。数据的事情一定要自上而下的推动,也就是创始人一定要重视数据,把数据需求的优先级提升,这样在项目排期时,能够把数据的需求同时做了。我们知道两军对战,情报收集工作的重要性。做产品也是一样,数据收集工作的重要性不言而喻。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。


最新评论
返回顶部