在数据采集上的痛苦、幻想与失望
桑文锋 知乎

在这一年来接触了我个人接触了 200 家创业公司,发现都在数据采集上遇到多多少少的问题,我把它们归结为三类:

1、不知道怎么采,包括采集什么数据以及用什么技术手段采集;
2、埋点混乱,出现埋错、漏埋这样的问题;
3、数据负责人员和业务工程团队配合有问题,很难推动业务工程团队配合,往往项目功能升级的优先级大于数据采集的优先级。

上面这三类问题让数据同学相当痛苦,进而有些幻想出现不用做数据采集的方案,结果做了些尝试后,进而是更大的失望。我这里对这三类问题的现状及应对之策做一下分析。

不知道怎么采

一般创业公司是数据采集上,可以分为三种方式:

第一种是直接使用友盟、百度统计这样的第三方统计工具,通过嵌入 App SDK 或 JS SDK,然后就可以看统计数据了。这种方式的好处是简单、免费,因此使用非常普及。对于看一些网站访问量、活跃用户量这样的宏观数据需求,基本能够满足。但是,现在一些订单相关的产品,越来越不满足于看这些宏观统计数据,还想做一些深度的用户渠道转化、留存、多维度交叉分析等操作,这个时候就会发现很难满足。这里的问题倒不是出在分析能力的薄弱,而是出现数据采集的不完整。

通过这种 SDK 只能够采集到一些基本的用户行为数据,比如设备的基本信息,用户执行的基本操作等。但是服务端、数据库中的数据并没有采集,对于一些提交操作,比如提交订单对应的成本价格、折扣情况等信息也没有采集,这样就导致后续的分析成了“巧妇难为无米之炊”。

通过客户端 SDK 还有一个问题就是经常觉得统计的不准,和自己的业务数据库数据对不上,出现丢数据的情况。这是前端数据采集的先天缺陷,因为网络异常,或者统计口径不一致,都会导致数据对不上。

第二种是直接使用业务数据库做统计分析。一般的互联网的产品,后端都是有业务数据库,里面存储了订单、用户注册信息等数据,基于这些数据,一些常用的统计分析都能够搞定了。这种方式天然的就能分析业务数据,并且是实时、准确的。但不足之处有两点:一是业务数据库在设计之初就是为了满足正常的业务运转,给机器读写访问的。为了提升性能,会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表,这些表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时间搞懂了,隔天工程师又告诉你因为性能问题拆表了,你就崩溃了。二是业务数据表的设计在于高并发低延迟的小操作,而数据分析常常是针对大数据进行批量操作,这样就导致性能很差。

第三种是通过 Web 日志进行统计分析。这种方式相比基于业务数据库的方式,完成了解耦,使业务运行和统计分析两个数据流相分离。这里的问题是打印日志往往是工程师顺便搞搞,完全是以 Debug 的需求来打印日志字段,但在业务分析上,往往发现缺斤少两。并且从打印日志到处理日志到输出统计结果,整个过程很容易出错,我在百度就花了几年的时间解决这一问题。

以上三种方式都多多少少解决了一部分数据采集的问题,但又都解决的不彻底。

埋点混乱

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

于是数据相关的同学甚至管理者都在幻想,既然埋点这么容易出问题,有没有不埋点就可以解决所有问题?这就像寻找可以祈求风调雨顺的神灵。在 2010 年时,百度 MP3 团队曾经做了一个叫 ClickMonkey 的产品,只要页面上嵌入 SDK,就可以采集下来页面上所有的点击行为,然后就可以绘制出用户点击的热力图,这种方式对于一些探索式的调研还是比较有用的。后来在 2013 年,国外有家数据分析公司叫 Heap Analytics,把这种方式更近一步,将 App 的操作尽量多的采集下来,然后通过界面配置的方式对关键行为进行定义,这样就可以不用工程师的配合就可以完成数据采集操作了,这是其中的一个优点。这里要说明的是,要使用这种方案,必须在产品里实现嵌入 SDK,等于做了一个统一的埋点,所以“无埋点”这种叫法本身就不严谨。我更愿意把这种方式叫做“全埋点”。

这种方式只能是进行前端的数据采集,后端服务器和数据库中的数据,依旧是无可奈何的。即使进行前端的数据采集,也不能够进行细粒度的数据采集。比如对于提交订单操作,订单的运费、成本价格之类的维度信息,等于都丢失掉了,只剩下提交这么一个行为类型。

对于非技术人员,容易被这种方式的名称和直接优势所吸引,但很快又会发现许多深度数据分析需求无法直接满足,进而有种被忽悠的感觉,会感到失望。其实不止是非技术人员,即使是技术人员,也都会让我解释一下“可视化埋点”的原理,当我讲解之后,一般都会恍然大悟。这里说一下关键点:一是事先在产品上埋一个 SDK,二是通过可视化的方式,生成配置信息,也就是事件名称之类的定义,三是将采集的数据按照配置重命名,进而就能做分析了。

数据团队和业务工程团队的配合问题

公司到了 A 轮以后,一般都会有专门的数据团队或者兼职数据人员,会对公司的一些业务指标负责。即使为了拿到这些基本的业务指标,一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了,天下武功唯快不破。于是所有事情都要给产品迭代升级让路,快的都没有时间做数据采集。须知没有数据指标,又怎么衡量这个功能升级是不是对的呢?互联网产品并不是加更多的功能就好,还是要基于数据做验证,然后学习新知识,用于下一轮的迭代。

数据团队和业务工程团队是平级的团队,而数据团队看起来总是给业务工程团队增加麻烦事儿,似乎也不能直接提升工程团队的 KPI,所以就导致配合起来特别费劲。数据团队的需求总是被更高优先级的事情挤掉,导致数据的事情迟迟没有进展。

解决之道

前面分析了以上三类问题,我们来看一下应对之道。

对于不知道数据怎么采的问题,首先从意识上要重视数据采集工作。数据的事情归结起来就两点:数据采集和数据分析。可不能只看到数据分析但没看到数据采集。事实上我个人在百度做数据的几年里,最大的心得就是数据这个事情要做好,最重要的就是数据源,数据源整好了,那就成功了一半。数据采集的基本原则是全和细。全就是要把多种数据源都要进行采集,而不只是客户端的用户数据。细就是强调多维度,把事件发生的一系列维度信息,比如订单运费、成本价格等,尽量多的记录下来,方便后续交叉分析。

其次,要有一个数据架构师,对数据采集工作负责,每次增加或变更数据采集点,都经过审核管理,不是顺便搞搞的事,要系统化。最后,我这里要推荐 Event 数据模型,针对用户行为数据,简化成一张宽表,将用户的操作归结为一系列的事件。

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

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

最后,期望越来越多的创始人,从拍脑袋做决策逐步向数据驱动决策做出转变。

CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢