版权声明:此文章如需转载请联系听云College团队成员阮小乙,邮箱:ruanqy#tingyun.com
大数据时代的到来意味着数据量的爆炸,也意味着收集数据的难度将大幅增加。为了将海量的数据收集起来,埋点技术应运而生。然而随着大数据的发展和深入,用户的要求越来越高,埋点技术开始变得力不从心。
近期,一些公司开始以“无埋点技术”为卖点,开始到处宣传无埋点比埋点好,那么到底事实如何了?
埋点技术的时代
埋点技术通过在代码的关键部位植入统计代码,追踪用户的点击行为;或者植入多段代码,追踪用户的连续行为;并通过建立模型等方法,得出用户操作行为;最终作为建立产品数据系统的一个环节准确的收集数据。
那么为什么通过埋代码就可以准确的收集数据呢?
原因有三:
首先,每个操作的界面都有其独立的标示性,具有无重复性,利用此可以统计访问、访客等;
其次,每个界面的事件针对当前页面都是独立的、唯一的,相互之间具有独立性,对此进行埋代码后可以统计事件行为;
最后,在任一界面都会有一个或者多个事件,每个事件会有不同的参数,每个事件参数都具有完整性,在埋点后通过建模可以得出准确的数据,最终目的是为未来产品优化方向做指导的。
这是笔者在以前公司时候,写的前端代码:
<%= link_to "全部雇员#{corp.staffers_count}", employees_corp_path(corp.pretty_abbrev, from: 'corps_detail_all_employee'), class: 'more', onclick: "addGaTrackEvent('corps_detail','goto_all_employee','corps_detail_right')" %>
像这样addGaTrackEvent的onclick事件几乎遍布整个项目,而且因为浏览器的兼容问题,有时候还不得不采用这种简单粗暴的方式添加“埋点”
埋点技术的弊端
其实,从上面的代码就看出了这种“埋点技术”的弊端,
首先,IT人员在埋点的时候,必须先清楚要收集的是什么数据,这些数据用来做什么,在什么地方收集这些数据,而且往往会导致代码的丑陋。
其次,一旦数据有问题,想要纠正则需要重新进行埋点,使得之前的工作变成无用功。
最后,埋点增加了测试的难度,需要考虑业务其外的东西。
所谓无埋点技术,并非完全不用埋点,而是不用在设置代码前先行定义需要采集的事件或功能
大多对于可交互式的应用程序,例如Android应用,iOS应用,网站,Windows Phone应用,Windows的窗体程序、Java的窗体程序等等,其实在界面渲染时都有几点共性:
图形背后都有图形树,我们所看到的输入框、文本框、按钮等等其实都是view,而view的摆放其实也都是有对应的视图方式,例如线性布局、网格布局、表格布局、相对、绝对等等,然后view加布局就组成了我们要看到的界面,比如最简单的就是网站的DOM结构了,有层级关系,对于Android而言就是View视图的层级关系了,调用系统级API基本上都能获取这个树结果。
窗体都有生命周期,比如Android的Activity的生命周期
对于我们可视的这些界面元素,当他们显示出来、被点击了、被选中了、被滑动等等操作的时候,系统也都会有相应的接口给开发者通知他们去处理,所以也就是对于View而言可以绑定或者委托或者是监听他们的一些触发事件,比如刚刚提到的加载、点击、选中等操作。
讲到这里,应该很清楚了,应用程序在呈现程序界面的时候,其实有一套生命周期的准则在里面,控制了从界面元素创造到响应用户操作到销毁,同时也有一个图形树的准则在里面,控制了这些界面元素的显示层级和顺序,最后在用户交互(包括展现)各个界面元素的时候,会给开发者提供一系列的接口,让开发者去处理这些行为。
所以原理清楚了,后续无埋点其实也就能想到怎么做了,现在市面上主流有两种,一种是预先跟踪所有的渲染信息,一种是滞后跟踪的渲染信息。两种做法不太一样,后者要简单一些,前者要重一些,但是也有一些办法优化(不交互的元素肯定多于交互元素),各家也就都有自己的方法在里面。
无埋点技术的弊端:只看数据采集的方式,而不考虑数据的传输,存储,分析,可视化反馈,都是耍流氓。
因为你根本没办法定义“所有的信息”。抓取的信息越多,也就意味着浪费的流量也越多,存储和索引的成本也越高。
信息检索有一个最关键的概念是 precision/recall。无埋点是尽可能地提高 recall,而这个成本一部分是终端客户承受,另一部分是在 SaaS 服务的数据管线上增加压力。对于 PC 端的应用,这可能不是问题。但是对于移动端的应用,这就意味着更多的移动数据成本和耗电,此外还有相关的隐私风险。
推荐阅读
http://www.sensorsdata.cn/blog/shu-ju-jie-ru-yu-mai-dian/