课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我曾经接触了一家做了七八年的老牌互联网公司,他们的数据采集有 400 多个点。每次数据产品经理提出数据采集的需求后,工程师就会按照要求增加埋点,然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常,可等产品上线之后,才发现埋的不对,再进行升级发版操作,整个过程效率极低。我们发现,一个公司发展到了一定程度,没有专人去负责埋点管理工作,数据采集就完全没有准确性可据采集就完全没有准确性可言。甚至有时产品上线之后,才发现数据采集的工作没有做,也就是漏埋了。
于是数据团队又开始幻想,既然埋点这么容易出问题,有没有可能不埋点?这就像寻找可以祈求风调雨顺的神灵。
在 2010 年,我的团队曾经做了一个叫 ClickMonkey 的产品,只要页面上嵌入 SDK,就可以采集页面上所有的点击行为,然后就可以绘制出用户点击的热力图,这种方式对于一些探索式的调研还是比较有用的。到了2013 年,国外有家数据分析公司 Heap Analytics,把这种方式更近一步,将 App 的操作尽量多的采集下来,然后通过界面配置的方式对关键行为进行定义,这样便完成了所谓的“无埋点”数据采集。使用这种方案,必须在产品中嵌入 SDK,等于做了一个统一的埋点,所以“无埋点”的叫法实际上是“全埋点”的代名词。
另外,这种方式同样也只能采集前端数据,后端服务器和数据库中的数据,依旧是无可奈何的。并且,即便进行前端数据采集,也无法深入到更细粒度。比如提交订单操作,订单运费、成本价格之类的维度信息,都丢失掉了,只剩下“提交”这一个行为类型。
对于非技术人员,容易被这种方式的名称和直接优势所吸引,但很快又会发现许多深度数据分析需求无法直接满足,进而有种被忽悠的感觉,会感到失望。其实不止是非技术人员,即使是技术人员,也都会让我解释一下“可视化埋点”的原理,说明“无埋点”真是个有迷惑性又不甚清晰的概念,难以细究。
这里说一下关键点:一是事先在产品上埋一个 SDK,二是通过可视化的方式,生成配置信息,也就是事件名称之类的定义,三是将采集的数据按照配置重命名,进而就能做分析了。
数据团队和业务工程团队的配合问题
最后,我们再聊一聊数据采集中遇到的非技术性问题。一般来说,公司到了 A 轮以后,都会有专门的数据团队或者兼职数据人员,对公司的一些业务指标负责。即使为了拿到这些基本的业务指标,一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了,天下武功唯快不破。于是所有事情都要给产品迭代升级让路,快的都没有时间做数据采集了。殊不知没有数据指标的支撑,又怎么衡量这个功能升级是不是合理的呢?互联网产品并不是功能越多就越好,产品是否经得起用户考验,还是要基于数据说话的,然后学习新知识,用于下一轮的迭代。
数据团队和业务工程团队是平级的团队,而数据团队看起来总是给业务工程团队增加麻烦事儿,似乎也不能直接提升工程团队的 KPI,所以就导致需求不被重视,总是被更高优先级的事情挤掉,数据的事情难有进展。