无痕埋点统计，现有方案调研

版权声明：

本公众号发布的所有文章，均属于原创，版权归本公众号所有。

未经允许，不得转载。

一、前言

对于一个线上的产品，我们会通过一些数据指标来监控我们的产品的情况。而市面上有各种统计平台，友盟和百度统计，都是比较常用的。我们线上项目现在依然还在使用友盟来做到打点统计。

但是这些统计平台，有一个缺陷就是需要手动以代码的形式预埋点，也就是说在发版之前，就确定要需要的统计点，然后以代码的形式，硬编码到项目对应的位置，在发版之后，才会生效并且上报对应的数据。

这样就带来一个很大的问题，如果发版本之前，无法预见我们需要的统计点，或者有遗漏，我们只能通过发布新版本，或者热更新的方式来补充这个数据统计点。而这，会导致数据的不准确或者调整起来不够灵活。

所以，无埋点方案就孕育而生，有没有办法做到无埋点就解决数据统计的问题？

二、市面上常见的方案

对于市面上常见的统计方案，美团点评的文章已经帮我们总结的很好了。

为了解决前端埋点的准确性、及时性、开发效率等问题，业内各家公司从不同角度，提出了多种技术方案，这些方案大体上可以归为三类：

1. 第一类是代码埋点，即在需要埋点的节点调用接口直接上传埋点数据，友盟、百度统计等第三方数据统计服务商大都采用这种方案；

2. 第二类是可视化埋点，即通过可视化工具配置采集节点，在前端自动解析配置并上报埋点数据，从而实现所谓的“无痕埋点”， 代表方案是已经开源的Mixpanel；

3. 第三类是“无埋点”，它并不是真正的不需要埋点，而是前端自动采集全部事件并上报埋点数据，在后端数据计算时过滤出有用数据，代表方案是国内的GrowingIO。

1、代码埋点

代码埋点的最大缺点就是需要有预见性，需要在发布版本之前，就判断出我们需要的数据。这种预见性，只能在流程上人为的把控，有几点建议可以参考一下：

1. 产品在出产品文档的时候跟随一篇对应产品的统计文档，开发按照这个文档严格执行，将需要的数据都上报。

2. 在发布灰度升级的时候，检测对应的统计点，是否符合预期。如不符合，及时调整后再发布市场。

但是这样的方案缺陷也很大，可能会引出其他的问题，例如产品功能的迭代，可能一个地方的修改会影响到其他地方的统计之类，或者有突发情况需要了解一些侧面数据。

这就很考验产品经理出的统计需求文档时候的经验和预见性，当然开发人员在开发这个功能的时候，也可以提出改进意见，一句话，意识很重要。

2、可视化埋点

可视化埋点，看了下这个开源项目，维护的还很勤，但是如果按照这个方案修改的话，对于一个现有项目，改动还是挺大的，没太深入研究。

有兴趣的可以看看介绍视频，当然，可能需要科学上网的方式观看：

https://www.youtube.com/watch?v=KcpOa93eSVs

3、全量上报，服务解析

第三类这种无埋点的方案，它实际上是采集了所有的事件，并且全部上报，最终在服务端，根据用户需要的统计点，分析出对应的数据进行展示。

上面推荐的 GrowingIO ，大概了解一下，实际上它并不是免费的，接入的时候可以提供一个免费的试用账户给开发者，但是如果真实上架的 App ，是需要付费使用的。

但是官网上并没有报价，可以通过客服咨询问价，我现在了解到的，基础价格是 6W/年，包含起步的 3W 最高日活，高于 3W 日活后，阶梯增长收费，每涨 1W日活，多加 2W 块。不过据说这个价格可以谈，有兴趣的可以继续了解一下。

这种收费的服务，一般而言不会是我们的首选。

三、美团的方案

美团点评对客户端埋点的要求：

1. 数据的准确性和及时性。

2. 埋点的效率，要能适应版本迭代做到快速埋点。

3. 动态部署和修复埋点的能力。

所以他们独立开发了一套自己的无埋点的方案。会将常用的 UI 控件，全部自定义一遍，重写事件的响应方法，在这些事件的响应内填写埋点的代码，在需要上报的时候，动态上报即可。

这样实际上，改动只需要通过一个接口下发我们需要的埋点控件的 id、以及上报的埋点统计的 Key 即可，当然实现起来会比这个跟复杂一些。

这里只需要知道美团点评的方案，就是重写 UI 控件，然后拦截其事件，符合要求的，发送统计数据到统计系统中。

但是这样的一个方案，虽然可以解决问题，但是又需要面临另外一个问题，移植的成本非常的高。

所以美团想到的了两个方案：

1. 参考 v7 支持库的思路，通过 AppCompatDelegate 代理自动替换 UI 控件。

2. 编写一个 Gradle 插件，在运行的时候，动态修改其控件的父类，达到移植的效果。

方案一，的问题在于，只能替换你 App 内直接使用的 UI 控件，对于第三方库中重写的 UI 控件，这样的方案是不行的，所以才演变出需要方案二。

而方案二实际上是在编译期间做的改动，所以也不会影响运行效率，只是可能会耽误一点编译的时间，这点效率问题，其实我们是可以接受的。

四、总结

今天就先说到这里，之后会继续详细讲解以上介绍的两种方案的技术实现细节，需要关注的点和会遇到的坑。

那么我们就敬请期待吧！