埋点系列-代码埋点SDK架构与原理

小迪导读：本文讲解代码埋点的采集SDK的架构和原理。对产品，数据产品，数据技术，数据分析感兴趣的都是本文的目标读者，文章内容是作者结合自身工作经验总结出来的，如有描述不准确的地方，欢迎读者朋友们评论交流。

本文大约4000字，阅读本文大概需要15分钟。

1.

代码埋点与全埋点的区别

▍1.1 代码埋点

代码埋点，顾名思义，就是每个埋点都需要开发写代码。代码埋点是侵入式的，需要工程师在每个需要埋点的位置上打点。

优点：每个埋点都是需要开发，因此每个埋点都可以带很多业务信息（也就是数据分析里面的维度），数据可靠性高，接收到的埋点数据价值巨大，主流大公司都会选择代码埋点这种方式；

缺点：工作量巨大，埋点代码版本管理困难。

▍1.2 全埋点

全埋点，又称为无埋点。应用中只要集成了全埋点SDK，全埋点SDK会对应用中的数据做全量采集。

优点：只要接入全埋点SDK，即可实现全量采集，集成后几乎没有开发工作量；

缺点：全量采集只能采集统一预置的变量，业务变量不会带在埋点数据中，这就让全埋点数据的价值大打折扣，基本就只能用看埋点数据（只看用户行为数据，不能关联分析），不能用数据（画像，推荐，算法）。

他们不是替代关系，是互补关系，用来满足不同场景的需求。代码埋点，上线了后发现，埋漏了，怎么办，看全埋点的数据，虽然没有那么多维度，但有总比没有强。全埋点因为全量采集，还可以非常方便的看用户行为路径，APP内流量走势等等。

我认为，在重视数据的公司里，代码埋点是不可以缺少的，全埋点是锦上添花。以下篇幅中，都是围绕代码埋点SDK展开讲解的。

2.

评估代码埋点SDK优劣的标准是什么？

从公司战略看，是传统企业要做数字化转型也好，创业公司要成为数据驱动的精细化运营也好，用户行为数据采集只是数据战略中一小部分。因此埋点SDK应该尽可能设计的简单、易用，做到数据容易采集，采集到的数据好用。让采集数据成为公司数据驱动的助力而不是阻力。

首先应该关心代码埋点SDK的用户，用户用的爽，用户舒心，就可以认为SDK做的好。用户是谁，他们关心什么？

采集SDK的用户有些谁：前端和客户端开发、服务端开发，数据测试，大数据团队。

开发埋点的人（h5，小程序，iOS，Android的开发）：

简单易接入，开箱即用，提供非常简单的SDK接入方法，并且有规范清晰的SDK接入文档，帮助任何一个开发自助式地进行快速接入，哪怕是新人，也可以在10分钟内上手使用；

现在一个应用可能会接入多个SDK，这就要求SDK需要做到极致的稳定，对业务逻辑和功能没有任何影响，接入后，不能出现crash，不能出现性能问题。加上埋点后，不能影响功能逻辑，埋点的发送不影响用户体验（用户无感知）最好数据是异步发送，埋点发送失败导致的问题不会让APP崩溃；

尽可能减少开发工作量，预置变量要足够丰富；

SDK的多端一致性，经常有埋点需求是跨h5，iOS和Android都要埋，需要三端埋点的实现逻辑保持一致；

测试埋点的人（数据测试）

非常容易的区分出来dev，qa，pro环境数据，且提供好用的测试方法

接收埋点数据人（大数据团队）

埋点的数据模型是简单的，可扩展的

同一个用户可以全程被标记出来

一个代码埋点SDK，全部满足上面这些用户需求，就可以打95分了，也可以在实际业务中应用了。

3.

代码埋点SDK的架构

▍3.1  SDK整体架构

数据采集是否完整、是否准确、是否及时、能否关联打通，都直接影响公司整个数据平台的应用效果。因此，代码埋点SDK 需要良好的架构来保证数据的采集。

这部分从SDK整体设计出发，分别讲解SDK中的重点模块

▍3.2 SDK采集数据的流程

对于SDK而言，数据采集是在用户行为被触发时，把用户行为按照事件模型的数据格式，发送给服务器。下面以APP的数据上报流程图说明SDK的采集数据的过程。

▍3.3 初始化模块

初始化配置参数：各种配置参数的初始化，比如服务器接收地址，数据发送策略配置等等；

初始化缓存队列：只有当SDK初始化完成，采集到的数据才会通过网络发送到服务器。在这之前，数据会缓存到队列中。

▍3.4  数据采集模块

代码埋点，在SDK初始化后，SDK提供了采集的相关接口。开发调用SDK提供的采集接口，将要采集的事件名称，变量字段等先保存在本地，然后按照一定的策略将数据发送到目标数据服务器中。（或者直接发送）

代码埋点采集SDK提供的可以能力有：

精准控制埋点位置；

灵活定义事件和变量，支持采集丰富的业务数据作为变量；

此外代码埋点会提供丰富的预置变量，所有埋点都会自动带上预置变量的数据，通常包含以下字段：

▍3.5  数据存储模块

数据存储模块是为了对埋点数据做缓存，常见有以下几种存储方式：

队列：如果是异步引入SDK，通常会SDK尚未加载，就需要采集数据，这种情况，就需要先把数据在队列中缓存，SDK初始化完成后，按照先进先出顺序发送数据；

localstorage：页面采集的数据会存入APP的localstorage中，然后按钮发送策略发送（定时或者定量），数据发送失败时，localstorage不会删除数据，会再次发送，这样就有效避免了数据丢失；

cookie：通常会在cookie中存储一些用户标识；

▍3.6  数据发送模块

数据发送模块负责将缓存的数据准确的发送到服务端。

实时发送：把缓存在队列中数据按进入队列的顺序，一条一条的读取然后发送，发送后删除；

定时批量：数据在队列中存放一定时间后（可配置，比如6s），将所有数据发送出去，发送成功，删除数据，发送失败，跟下一批一起发送；

定量批量：数据在队列中存放数量后（可配置，比如6条），将所有数据发送出去，发送成功，删除数据，发送失败，跟下一批一起发送；

讲完代码埋点SDK整体架构后，再讲一下需要重点关注的几个部分：

4.

事件模型

▍4.1 事件模型的数据结构

事件模型本质是用一个标准化的语言去描述用户的行为，也就是将具象，丰富变化的的用户动作，抽象为一个数据模型；

其实事件模型很好理解，我们可以用生活中的例子类比理解，你怎么给别人描述你在生活中的行为？例如说会这么说，我昨天晚上20点20在家小区门口的快递驿站取快递，这是一个典型的描述行为的话术。将这个描述行为的方法使用在应用中用户行为的追踪，就是埋点中事件模型。

事件模型，4W1H，即：一个用户在某个时间点（when），某个地方（where），以某种方式（how）完成了某个具体的动作（what）。

一般会包含哪些类型的事件：

页面浏览

按钮点击

弹窗展示

模块曝光

这些组合起来就就能覆盖用户在应用中用户行为的99%

▍4.2 预置变量

在描述事件时，有些信息是通用的，每次都需要携带的，这种信息我们可以在SDK中一次性封装好，这样就不用每次埋点都要做重复工作，在事件模型中，我们将这些预置变量都放在一个JSON中，即default_variable这个字段。

▍4.3 事件变量

同样在描述事件时，有些信息，是个性化的，也就是视具体业务不同，需要携带的信息也不同，例如商品详情页需要携带商品信息，社区feed曝光需要携带帖子信息，这不就不可避免，每次进行代码埋点时都要开发携带具体的业务信息。在事件模型中，因为字段不确定，因此将业务信息放在一个JSON中，不管业务变量是什么都塞进去。

5.

如何有效降低数据漏报率？

▍5.1 H5的数据通过APP发送

因为用户端，用户千奇百怪的操作，以及各种不可提前预判的特殊状况，要求埋点百分之百一个不漏，是不现实，行业里，APP漏报率在1%左右，H5的漏报率在5%左右。

APP可以对缓存和上报做策略，因此可以漏报率比H5低很多。

APP漏报率1%，h5漏报率5%，想要最大程度避免漏报，大家都能想到的一个方法就是：针对hybrid app，我们可以把里面的h5页面埋点数据，先发送到APP SDK中，经过APP的缓存和上报策略，就可以把hybrid app中h5页面埋点数据漏报率从5%降到1%。

如何做呢，主要考虑两点：

h5拿不到很多预置变量的信息拿不到，h5数据发送到APP SDK后，APP SDK需要对h5采集不到的做补全；

用户标识统一：在用户登录之前，用户标识是匿名id，h5生成匿名id是用cookie，app生成匿名id是用AndroidId或者IDFA，因此需要统一；

▍5.1 APP做缓存和发送策略

这部分在SDK的数据发送模块已经描述，就不赘述了，只简单讲一种具体的策略：

时间间隔：每隔一定时间（默认 6 秒）发送一次数据；

存储数据条数：存储数据达到一定条数（默认 6 条）时发送一次数据；

进入后台：当APP进入后台时发送一次数据。

上述三个发送条件满足任意一个即可发送数据。

如果数据发送不成功，会将发送的数据保存起来，满足发送条件后，与之后的数据一起尝试发送。这样，可以减少网络请求、节省服务器资源，并且有效地降低一些数据发送过程中的丢失问题。

6.

用户id-mapping问题

现实世界中，我们用身份证来准确识别一个人。网络世界中，我们应该用什么来标识用户呢。常见的方法都有一些问题：

设备标识：一个人有多个设备，或者一个设备被多人使用，都会导致标识的不准确；

账号：只有用户登录，才知道用户是谁，访问行为和登录行为关联不上

这就需要有一个非常系统体系的方法去标识用户（在展开讲字数就控制不住了，后续专门更新id-mapping问题的文章，记得关注我）

以上就是我对于代码埋点采集SDK的一些理解，希望能对你有所帮助。欢迎评论讨论，一起进步。