从“埋点技术已死?”开始说起

大数据时代的到来意味着数据量的爆炸，也意味着收集数据的难度将大幅增加。为了将海量的数据收集起来，埋点技术应运而生。然而随着大数据的发展和深入，用户的要求越来越高，埋点技术开始变得力不从心。

近期，一些公司开始以“无埋点技术”为卖点，开始到处宣传无埋点比埋点好，那么到底事实如何了？

埋点技术的时代

埋点技术通过在代码的关键部位植入统计代码，追踪用户的点击行为;或者植入多段代码，追踪用户的连续行为;并通过建立模型等方法，得出用户操作行为;最终作为建立产品数据系统的一个环节准确的收集数据。

那么为什么通过埋代码就可以准确的收集数据呢?

原因有三：

首先，每个操作的界面都有其独立的标示性，具有无重复性，利用此可以统计访问、访客等;
其次，每个界面的事件针对当前页面都是独立的、唯一的，相互之间具有独立性，对此进行埋代码后可以统计事件行为;
最后，在任一界面都会有一个或者多个事件，每个事件会有不同的参数，每个事件参数都具有完整性，在埋点后通过建模可以得出准确的数据，最终目的是为未来产品优化方向做指导的。

这是笔者在以前公司时候，写的前端代码：

<%= 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 端的应用，这可能不是问题。但是对于移动端的应用，这就意味着更多的移动数据成本和耗电，此外还有相关的隐私风险。

想阅读更多技术文章，请访问听云技术博客，访问听云官方网站感受更多应用性能优化魔力。