采集 什么是全埋点？什么样的数据适合你？

　　采集 什么是全埋点？什么样的数据适合你？

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

　　1.代码埋点和全埋点的区别

　　▍1.1 代码埋点

　　代码埋点，顾名思义，每一个埋点都需要开发和编写。代码埋点是侵入性的，需要工程师为每个需要埋点的位置做点。

　　▍1.2 所有埋点

　　全埋点，又称无埋点。只要在应用中集成了全埋点SDK，全埋点SDK会做应用采集中的所有数据。

　　它们不是替代关系，而是互补关系，以满足不同场景的需求。代码被埋了，上线后才发现被埋了。我应该怎么办？看一下全埋点的数据。虽然没有那么多维度，但总比没有好。因为采集数量充足，在APP中查看用户行为路径、流量趋势等也很方便。

　　我认为在重视数据的公司中，代码嵌入是必不可少的，全嵌入是锦上添花。下面几页主要讲解代码嵌入SDK。

　　2.评估SDK优劣的标准是什么？

　　从企业战略来看，无论是传统企业需要进行数字化转型，还是创业公司需要成为数据驱动的精细化运营，用户行为数据采集只是其中的一小部分数据策略。因此，嵌入式SDK应设计得尽可能简单易用，做到数据易采集，采集接收到的数据易使用。让采集数据成为公司数据驱动的助推器而非阻力。

　　首先，您应该关注嵌入代码的 SDK 的用户。如果用户对代码感到满意，并且用户也感到满意，则可以认为该 SDK 做得很好。用户是谁？他们关心什么？

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

　　埋点开发者（h5、小程序、iOS、Android开发）：

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

　　接收埋藏数据的人（大数据团队）

　　一个代码嵌入SDK，满足以上用户需求，可以打95分，也可以在实际业务中应用。

　　3.代码埋点SDK架构

　　▍3.1 SDK整体架构

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

　　从SDK的整体设计开始，这部分将分别讲解SDK中的关键模块

　　1.代码埋点和全埋点的区别

　　▍1.1 代码埋点

　　代码埋点，顾名思义，每一个埋点都需要开发和编写。代码埋点是侵入性的，需要工程师为每个需要埋点的位置做点。

　　▍1.2 所有埋点

　　全埋点，又称无埋点。只要在应用中集成了全埋点SDK，全埋点SDK会做应用采集中的所有数据。

　　它们不是替代关系，而是互补关系，以满足不同场景的需求。代码被埋了，上线后才发现被埋了。我应该怎么办？看一下全埋点的数据。虽然没有那么多维度，但总比没有好。因为采集数量充足，在APP中查看用户行为路径、流量趋势等也很方便。

　　我认为在重视数据的公司中，代码嵌入是必不可少的，全嵌入是锦上添花。下面几页主要讲解代码嵌入SDK。

　　2.评估SDK优劣的标准是什么？

　　从企业战略来看，无论是传统企业需要进行数字化转型，还是创业公司需要成为数据驱动的精细化运营，用户行为数据采集只是其中的一小部分数据策略。因此，嵌入式SDK应设计得尽可能简单易用，做到数据易采集，采集接收到的数据易使用。让采集数据成为公司数据驱动的助推器而非阻力。

　　首先，您应该关注嵌入代码的 SDK 的用户。如果用户对代码感到满意，并且用户也感到满意，则可以认为该 SDK 做得很好。用户是谁？他们关心什么？

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

　　埋点开发者（h5、小程序、iOS、Android开发）：

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

　　接收埋藏数据的人（大数据团队）

　　一个代码嵌入SDK，满足以上用户需求，可以打95分，也可以在实际业务中应用。

　　3.代码埋点SDK架构

　　▍3.1 SDK整体架构

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

　　从SDK的整体设计开始，这部分将分别讲解SDK中的关键模块

　　

　　

　　▍3.2 SDK采集数据流

　　对于SDK来说，数据采集是在用户行为被触发时，根据事件模型的数据格式将用户行为发送到服务器。下面结合APP数据上报流程图说明SDK采集data流程。

　　

　　

　　▍3.3 初始化模块

　　▍3.4 data采集module

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

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

　　

　　

　　▍3.5 数据存储模块

　　数据存储模块是对埋点数据进行缓存，常见的存储方式有以下几种：

　　▍3.6 数据发送模块

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

　　说完代码嵌入SDK的整体结构，我们来说说需要重点关注的几个部分：

　　4. 事件模型

　　▍4.1 事件模型数据结构

　　

　　

　　

　　

　　事件模型的本质是用标准化的语言来描述用户行为，即将具体的、丰富多样的用户行为抽象为一个数据模型；

　　实际上，事件模型很容易理解。我们可以用生活中的例子来类比来理解。你如何向别人描述你在生活中的行为？比如，我会说，我昨晚20:20在我家门口的快递站取了快递。这是描述行为的典型方式。在应用中使用这种描述行为的方法跟踪用户行为就是嵌入点中的事件模型。

　　事件模型 4W1H 意味着：用户在特定时间点（何时）、某处（何处）以特定方式（如何）完成特定操作（什么）。

　　一般包括哪些类型的事件：

　　这些组合可以覆盖用户在应用中99%的用户行为

　　▍4.2 预设变量

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

　　▍4.3 事件变量

　　同样，在描述事件时，有些信息是个性化的，即根据具体业务不同，需要携带的信息也不同。比如商品详情页需要携带商品信息，社区Feed曝光需要携带帖子信息。不是这种情况。每次埋藏代码时，都不可避免地需要开发和携带特定的业务信息。在事件模型中，因为字段是不确定的，所以不管业务变量是什么，业务信息都放在一个JSON中。

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

　　▍5.1 H5数据通过APP发送

　　由于用户终端的怪异操作，用户，以及各种无法提前预知的特殊情况，要求100%的埋点不漏点是不现实的。行业内APP误报率在1%左右，H5漏报率在5%左右。

　　APP可以制定缓存和上报策略，漏报率远低于H5。

　　APP漏报率为1%，h5漏报率为5%。为了最大程度的避免漏报，大家可以想到一个方法：对于混合应用，我们可以在h5页面里面嵌入一些数据。发送到APP SDK后，经过APP的缓存和上报策略，混合APP中h5页面嵌入点数据的误报率可以从5%降低到1%。

　　怎么做，主要考虑两点：

　　▍5.2 APP作为缓存和发送策略

　　这部分在SDK的数据发送模块中已经介绍过了，不再赘述，简单说一下具体的策略：

　　满足以上三个发送条件中的任何一个都可以发送数据。

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

　　6. 用户 ID 映射问题

　　在现实世界中，我们使用*敏*感*词*来准确识别一个人。在网络世界中，我们应该用什么来识别用户？常用方法存在一些问题：

　　这需要一个非常系统的方法来识别用户（扩展中不能控制字数，文章稍后更新id-mapping问题，记得关注我）