埋点的诞生
在最初的互联网世界中,并没有埋点的概念。大家并不关心流量从哪里来，用户在网站上做了什么事，一切都是野蛮生长。
随着业务的增长，访问网站的人越来越多，用户的需求越来越复杂，运营人员就需要一些关键的数据作为参考。
一般来说，互联网公司到了 A 轮以后，都会有专门的数据团队或者兼职数据人员，对公司的一些业务指标负责。即使为了拿到这些基本的业务指标，一般也要工程团队去配合做一些数据采集工作。正所谓天下武功唯快不破，所有事情都要给产品迭代升级让路，快的都没有时间做数据采集了。
但是，没有数据指标的支撑，又怎么衡量这个功能升级是不是合理的呢？互联网产品并不是功能越多就越好，产品是否经得起用户考验，还是要基于数据说话的，然后学习新知识，用于下一轮的迭代。
于是，埋点诞生了！
第一层境界：代码埋点
最初的埋点是在代码的关键部位植入N行代码，追踪用户的行为,得到想要的数据。挖开产品本身,找到收集点.进行源源不断的传递数据。
简单的说：找节点,布代码,收数据。
随着业务的规模越来越大，运营人员发现,要收集的数据越来越多，需要埋的点也越来越多。
这时候，代码埋点的缺陷就暴露出来：
每次埋点部署比较慢，需要产品和开发反复沟通，如果埋点中出现问题，重新埋点的代价特别大。这两点问题的存在将整个数据收集周期拖长到半月甚至一个月，收集成本很高但效率却不高。如果算上大型测试，简直不能忍。于是有了第二层境界。
第二层境界： 框架式埋点
框架式埋点也称“可视化埋点”。
既然写代码代价大，每一个埋点都需要写代码，那么，我们可以用框架式交互手段来代替纯手工写代码嘛。
固化相应代码的做为SDK,方便直接调用.这是一个非常大的进步。
框架式埋点很好地解决了代码埋点的埋点代价大和更新代价大两个问题。
因此，对于框架式埋点这种方案，在上传事件时，就只能上传 SDK 自动收集的设备、地域、网络等默认属性，以及一些通过代码设置的全局公共属性了；最后，作为前端埋点的一种方案，框架式埋点也依然没有解决传输时效性和数据可靠性的问题。
由于互联网和移动互联网神一般的发展速度，互联网公司的数据规模得到了极大的扩张，大数据时代的到来意味着数据量的爆炸，也意味着收集数据的难度将大幅增加。
简单的封装SDK还是有很多问题，所以我们在想，有没有办法更简单一点。
第三层境界：无埋点
框架式埋点能够覆盖的功能有限，关键在于不是所有的控件操作都可以通过这种方案进行定制。
框架式埋点先通过界面配置哪些控件的操作数据需要收集；“无埋点”则是先尽可能收集所有的控件的操作数据，然后再通过界面配置哪些数据需要在系统里面进行分析。所谓无埋点技术，并非完全不用埋点，只是不需要工程师不断部署代码。客户加载了一段定义好的JS或SDK代码后，就可以在产品处半自动进行埋点，智能抓取关键用户行为，快速收集数据。
“无埋点”相比框架式埋点的优点：
一方面是解决了数据“回溯”的问题，例如，在某一天，突然想增加某个控件的点击的分析，如果是框架式埋点方案，则只能从这一时刻向后收集数据，而如果是“无埋点”，则从部署 SDK 的时候数据就一直都在收集了；另一方面，“无埋点”方案也可以自动获取很多启发性的信息，例如，“无埋点”可以告诉使用者这个界面上每个控件分别被点击的概率是多大，哪些控件值得做更进一步的分析等等。当然，与框架式埋点一样，“无埋点”依然有自己的问题，不能灵活地自定义属性，传输时效性和数据可靠性欠佳。甚至由于所有的控件事件都全部搜集，反而会给服务器和网络传输带来更大的负载。再加上神一般的安全性问题。好吧,我想静静。(我的数据全要向平台传输)
从流量另辟蹊径
这三重境界，是一个慢慢演变的过程。
无埋点并不是只能运用在业务功能上，其实也可以运用在业务风险控制领域。
不仅如此，我们在想，是不是可以找到另外一个数据更全，纬度最多，全量还原的数据采集方式呢？
其实，所有的信息交互都有一个根源：流量。
网络流量是最基本的业务信息。用户的每个动作都包含了一次请求和响应。网络流量中的信息链代表了每个用户在应用中的访问轨迹。而其中细节可明确展示出用户的每个动作类型通过流量采集发到本机的http/UDP网络流量,对流量进行重组，重组为http请求或其他标准日志格式，同时可以将满足特定特征的http日志进行进一步加工，解析为业务行为的标准信息。
如下一个简单的请求所示：
聪明如你，是否明白了这包含了你想要提取的什么信息吗？
展开想像。是不是最完整的信息都在流量里出现过？
所以，通过流量可以得到所有维度的数据，用户的行为、转化等等。流量同样也解决了数据“回溯”的问题：只要有流量的纪录，就可以解析信息，还可以完整保存所有相关节点的前后来往信息进行多纬度的分析。
笔者认为，相对与前面提到的几种埋点方案，“流量”将不再需要程序员进行代码的更新，这才是真正的无埋点技术。
0 留言