代码埋点、可视化埋点、无埋点几种数据埋点方案的分析报告

目录

数据采集的核心问题

一、埋点是什么

二、为什么要埋点

三、埋点有哪些方式

四、各埋点方式优劣对比

五、其他

---

在这篇文章里面，我们会对数据采集的一些基本概念进行阐述，然后，会针对目前市面上新增的一些前端埋点技术，如可视化埋点与“无埋点”的技术细节做一个具体的介绍，并且阐述一些自己对于这些技术的理解和认识。

数据采集的核心问题

一个典型的数据平台，对于数据的处理，是由如下的5个步骤组成的： 

其中，我们认为，第一个步骤，也即数据采集是最核心的问题。数据采集是否丰富，采集的数据是否准确，采集是否及时，都直接影响整个数据平台的应用的效果。

虽然我们知道前端埋点的一些问题。例如，需要等待网络情况良好才能发送数据，需要积攒一定的量才发送数据，需要在本地暂存而本地暂存空间有限等一系列在数据传输性和数据可靠性上的一些问题。但是，前端埋点毕竟有一些后端采集数据所无法替代的地方，例如，分析前端界面设计是否合理，分析一些在与后端没有交互的前端行为等，还是必须采用前端埋点方案的。前端埋点作为一个比较成熟并且被广泛采用的数据接入手段。因此，在这里，我们觉得有必要详细介绍一下目前市面上主流的前端埋点方案的技术细节，并且结合我们的产品，来阐述我们对于这些埋点方案的一些看法。

一、埋点是什么

定时、定点地在目标应用/网站上采集数据，将数据以日志的方式上报至服务器的过程。

二、为什么要埋点

企业方获得用户在产品上的使用数据，分析后利于产品优化迭代。

三、埋点有哪些方式

3.1 代码埋点

代码埋点出现的时间很早了，在 Google Analytics 年代，就已经出现了类似的方案了。目前，国内的主要第三方数据分析服务商，如百度统计、友盟、TalkingData 等都提供了这一方案。

它的技术原理也很简单，在APP或者界面初始化的时候，初始化第三方数据分析服务商的SDK，然后在某个事件发生时就调用SDK里面相应的数据发送接口发送数据。例如，我们想统计APP里面某个按钮的点击次数，则在APP的某个按钮被点击时，可以在这个按钮对应的 OnClick 函数里面调用SDK提供的数据发送接口来发送数据。

下面，我们看友盟提供的两个例子。

第一个例子是在使用者的某个 Android APP 里面，统计某个由 Activity 构成的页面的访问次数，下面是友盟官方给出的例子：

public void onResume() {  
    super.onResume();
    MobclickAgent.onPageStart("SplashScreen"); //统计页面(仅有Activity的应用中SDK自动调用，不需要单独写。"SplashScreen"为页面名称，可自定义)
    MobclickAgent.onResume(this);          //统计时长
}


public void onPause() {  
    super.onPause();
    MobclickAgent.onPageEnd("SplashScreen"); // （仅有Activity的应用中SDK自动调用，不需要单独写）保证 onPageEnd 在onPause 之前调用,因为 onPause 中会保存信息。"SplashScreen"为页面名称，可自定义
    MobclickAgent.onPause(this);
}

这个例子其实非常简单，就是在 Activity 控件相应的触发器函数里面，调用友盟提供的接口统计数据即可。

第二个例子稍微复杂点，它不再是统计页面访问这样一个默认的事件，而是统计一个自定义事件。例如，一个电商APP，在用户点击“购买”按钮时，想统计“购买”这个自定义事件的相应信息，那么，可以使用下面的代码：

HashMap map = new HashMap();  
map.put("type","book");  
map.put("quantity","3");  
MobclickAgent.onEvent(mContext, "purchase", map);  

必须说明的是，友盟归根结底还是一个统计工具，并没有提供完整的多维分析功能，姑且不算数据传输的时效性以及对自定义属性上的各种限制，仅仅是为了统计某个数值，友盟还要单独区分出“计数事件”和“计算事件”，这一点上，就有一定的局限性

从上面这两个例子可以看出，代码埋点的优点是一方面使用者控制精准，可以非常精确地选择什么时候发送数据；同时使用者可以比较方便地设置自定义属性、自定义事件，传递比较丰富的数据到服务端。

当然，代码埋点也有一些劣势。首先，埋点代价比较大，每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且限定了必须是技术人员才能完成；其次是更新的代价比较大，每一次更新埋点方案，都必须改代码，然后通过各个应用市场进行分发，并且总会有相当多数量的用户不喜欢更新APP，这样埋点代码也就得不到更新了；最后，就是所有前端埋点方案都会面临的数据传输时效性和可靠性的问题了，这个问题就只能通过在后端收集数据来解决了。

3.2 可视化埋点

从前端埋点到可视化埋点其实是一个非常顺理成章的演进。既然埋点代价大，每一个埋点都需要写代码，那么，就参考 Visual Studio 等一系列现代 IDE 的做法，用可视化交互手段来代替写代码即可；既然每次埋点更新都需要等待APP的更新，那么，就参考现在很多手游的做法，把核心代码和配置、资源分开，在APP启动的时候通过网络更新配置和资源即可。

正是出于这种自然而然的做法，在国外，以 Mixpanel 为首的数据分析服务商，都相继提供了可视化埋点的方案，Mixpanel将之称作为 codeless。而国内的 TalkingData、诸葛IO 等也都提供了类似的技术手段。 顺带一提，Sensors Analytics 在1.3版本的更新中，也已经给使用者提供可视化埋点方案，以降低使用者的数据接入成本。

特别需要强调的是，Mixpanel 非常无私地开源了它们的iOS 和 Android 端的 SDK 的源代码，我们在开发中也参考了它们的贡献，并且也贡献了一些 bug 的提交，非常感谢 Mixpanel 对整个领域的贡献。

3.2.1 Android 平台的可视化埋点

下图是演示一个简单的 iOS SDK 使用 Mixpanel 的 codeless 埋点功能： 

从这个界面可以看出，使用起来还是非常简单的，点击某个支持的控件类型的实例，这个例子中是右上角的刷新按钮，然后在弹出的窗口中，设置点击这个按钮是发送 “Refresh” 事件。然后点击 Deploy 按钮，把这个配置下发下去。那么，所有安装有嵌入了 Mixpanel 的 SDK 的这个 APP ，则都会在 APP 启动时或者定时获取相应的配置。以后，真实的用户使用时，点击这个按钮，就会真正地发送 “Refresh” 事件到后端了。

3.3 “无埋点”

与可视化埋点一样，“无埋点”这个方案也出来的比较早，Heap作为一个第三方数据分析服务商，在2013年就已经推出了“无埋点”这个技术方案。而如果不局限于第三方，百度在2009年就已经有了“点击猴子”这个技术，用无埋点的方案分析一个页面各个元素的点击情况；在2011年，百度质量部也推出了一项内部服务，用以录制安卓 App 的全部操作，并且进行回放，以便找出 App 崩溃的原因；而豌豆荚大约也在2013年左右，在自己的 App 内部，添加了对所有控件的操作情况的记录。第三方数据分析服务GrowingIO 在2015年，也推出了类似于 Heap 的服务。

下图是一个使用 Heap 的例子： 

从界面上看，和可视化埋点很像。而从实际的实现上看，二者的区别就是可视化埋点先通过界面配置哪些控件的操作数据需要收集；“无埋点”则是先尽可能收集所有的控件的操作数据，然后再通过界面配置哪些数据需要在系统里面进行分析。

“无埋点”相比可视化埋点的优点，一方面是解决了数据“回溯”的问题，例如，在某一天，突然想增加某个控件的点击的分析，如果是可视化埋点方案，则只能从这一时刻向后收集数据，而如果是“无埋点”，则从部署 SDK 的时候数据就一直都在收集了；另一方面，“无埋点”方案也可以自动获取很多启发性的信息，例如，“无埋点”可以告诉使用者这个界面上每个控件分别被点击的概率是多大，哪些控件值得做更进一步的分析等等。

当然，与可视化埋点一样，“无埋点”依然没有解决覆盖的功能优先，不能灵活地自定义属性，传输时效性和数据可靠性欠佳这几个缺点。甚至由于所有的控件事件都全部搜集，反而会给服务器和网络传输带来更大的负载。

四、各埋点方式优劣对比

各种不同采集方案的数据获取能力的对比

在前面，我们已经介绍了代码埋点、可视化埋点、“无埋点”三种前端埋点方案，而也强调了我们一直推荐在后端采集数据。因此，在这里，我们觉得有必要比较一些可视化埋点、代码埋点与后端采集数据三种方案在数据获取能力上的差异，“无埋点”的数据获取能力与可视化埋点基本相当，在这里不再单独罗列。

(1) 代码埋点

原理：在应用App或界面初始化时，初始化埋点的SDK，在触发某个节点(如事件/页面)时调用SDK相应的方法，通过接口发送数据。通常为了减少用户上报数据时消耗过多流量，常见有两种解决方案：

(一) 进行数据映射(简化数据，不传具体参数值，而是根据MAP-KEY映射关系)，如应用端发送(0/0、1/)数据，由服务端将根据约定文档映射为(首页/模块一、第二个点击事件)；

(二) 非即时发送数据，将多条数据压缩打包，等待网络状况良好、或定时(5min)发送至服务端。

优点：

个性化自定义，能够根据企业自身业务特性自定义属性、事件，定制化获取数据。

缺点：

(一) 人力成本高，埋点工程涉及到由运营-产品-前端-服务端-后台一系列所有数据团队，不同系统/版本不易管理，所有方法均需人工注入，数据收集后需由服务端进行分析；

(二) 版本更新前后，容易发生数据紊乱(若发生重要负责人离职，无相关文档沉淀，则可能造成“前功尽弃”的情况)；

(三) 起步难，前期为简单计数；需要企业长期且稳定地完善、不断根据业务更新。

(2) 可视化埋点(又称为框架化埋点)

原理：将核心代码与资源、配置分开，当应用App启动时从服务端更新配置和资源(plist)，应用获知后，根据配置和部署信息相上报数据内容。

优点：

解决了代码埋点人力成本和更新代价大的问题，只要在版本内有相应SDK，即不存在老版本迭代后无埋点问题；且对于不懂代码的产品运营，可通过后台可视化界面进行配置操作，并且生效。

缺点：

(一) 无法做到自定义获取数据，可视化埋点覆盖的功能有限；

(二) 企业针对SDK开发难度相比代码埋点大，使用第三方SDK资源则有共同通病，下文说明。

(3) 无埋点(全埋点)

原理：在App中嵌入SDK，做统一的“全埋点”，将应用App中尽可能多的数据采集下来，通过界面配置的方式对关键行为进行定义，对定义的数据进行分析。

实现方式：

在应用中嵌入SDK，通过可视化方式(即上文可视化埋点方式)，针对对象进行定义，服务端对定义的数据进行分析，后台加以展现。

优点：

提供了埋点的“后悔药”(数据回溯问题)，只要部署了SDK，数据便开始采集；可以自动获取很多启发性的信息，可以通过热力图向用户展示各个控件、事件点击的概率更大；便于使用者发现页面僵尸按钮等等。

缺点：

(一) 缺点与可视化埋点相同，未解决个性化自定义获取数据的问题，缺乏数据获取的灵活性；

(二) 企业针对SDK开发难度较大，一般由数据分析企业研发提供，使用第三方提供的埋点方案，有如下缺陷：

1、数据源丢失，应用上报的数据上传至第三方服务端，可能造成企业泄密或用户的关键数据丢失；

2、供应商数据丢包问题，无法根据应用特性进行改善。

五、其他

(1) 当前流行的第三方数据产品体验

(一) Umeng，阿里旗下的数据分析产品，通用性功能均有覆盖，在部分特定页面上有缺失，定制化弱，适合初创起步的企业应用。

(二) Google Analytics，个人使用体验较好，对个人网页、应用所需的数据埋点都能满足，对数据结果展示较为喜欢，缺点是需查看；

(三) 神策数据。位于上海的神策公司，可根据企业部署特定服务器，针对个性化定制，并且有对应业务员、开发工程师进行企业一对一对接，服务体验较为良好；但数据分析后台非工作范围内，未详细体验、研究过；

(四) 诸葛io，国内领先、先行的数据分析公司，2013年是国内首家最早推出无埋点方案，但有运营朋友说丢包较为严重，未确认翔实与否。

其他较为知名的数据产品：TalkingData、Mixpanel未使用过，希望有大神分享，或之后使用后补充。

最后的叮嘱，数据埋点团队一定要留好数据埋点的规范定义文档，若发生团队埋点相关负责人离职，就会形成大坑。

Ps：其他思考问题整理如下：

(1) 为什么上报的数据颗粒级最好是“原子”最小化上报而非关系链上报？

虽然关系链上报对于还原用户的真实操作非常方便，服务端根据用户访问的时间序列，将事件串联，一步步分析，对于关系跳转挖掘很是方便；但对于快速迭代的应用产品，一旦产品相关逻辑变动，则所有业务分析(服务端)、逻辑关系(前端)须重写，对于前端-服务端都将是巨大的人力投入，以及新老版本的数据关系链冲突问题。

(2) 需要有专门负责人长期且稳定对代码埋点方式进行“买单”

一旦数据进行埋点，且产品运营形成数据量化结果、以数据驱动决策的习惯后，则必须进行持续维护。因为数据埋点研发团队，需花费较高的人力资源；测试点位时，要求完整覆盖性测试，确保无遗漏。

参考连接：

1、https://www.jianshu.com/p/58063f964820

2、https://www.sensorsdata.cn/blog/shu-ju-jie-ru-yu-mai-dian/