项目埋点的演进

概念

埋点，是对网页、APP或后台等应用程序进行数据采集的一种行为。通过埋点，可以采集用户在应用中的行为，用于分析和优化产品的体验，也可以为产品运营提供数据支撑。其中比较常见的指标比如PV、UV、DAU、时长、新增、页面点击等，收集的数据一般为：

1. 行为数据：时间、地点、用户、交互的操作等
2. 质量数据：App运行情况、浏览器加载情况、错误异常等
3. 环境数据：手机型号、操作系统版本、运营商、网络环境、设备信息等
4. 运营数据：PV、UV、点击量、日活、留存、渠道来源等
5. 安全数据：3D感应、蓝牙、传感器、电池电量、root信息等

采集行为数据时，一般会在APP中添加相应代码，当用户行为达到某种条件时，触发上报（这儿由于策略原因，可能是非实时上传到服务器的）。而这个“添加代码”的过程我们称之为“埋点”。一般埋点分为三种形式：

1. 代码埋点：是指在某个事件发生时调用数据收集接口进行数据上报。 例如研发按照产品/运营的需求或埋点文档，在Web页面或App的源码里添加行为上报的代码，当用户的行为满足某一个条件时，这些代码就会被执行，向服务器上报行为数据。这种方案是最基础的方案，每次增加或者修改数据上报的条件，都需要开发人员的参与，并且只能在下一个版本上线后才能看到效果。基本上所有的数据平台都提供了这类数据上报的SDK，将行为上报的后台服务器接口封装成了简单的客户端SDK接口。开发者可以通过嵌入这类SDK，在埋点的地方调用少量的代码就可以上报行为数据。

2. 全埋点：指的是将Web页面或App内产生的所有的、满足某个条件的行为，全部上报到后台服务器。 例如把一个App中所有的按钮点击都进行上报，然后由产品或运营去后台筛选所需要的行为数据。这种方案的优点非常明显，就是可以不用在新增或修改行为上报条件时，再找开发人员去修改埋点的代码。然而它的缺点也和优点一样明显，那就是上报的数据量比代码埋点大很多，里面可能很多是没有价值的数据。此外，这种方案更倾向于独立去看待用户的行为，而没有关注行为的上下文，给数据分析带来了一些难度。很多公司也提供了这类功能的SDK，通过静态或者动态的方式， “Hook”了原有的App代码 ，从而实现了行为的监测，在数据上报时通常是采用累积多条再上报的方案来合并请求。

3. 可视化埋点：是指通过可视化工具配置采集节点，在App或Web解析配置查找节点，监听节点产生的事件并上报。 例如产品在Web页面/App的界面上进行圈选，配置需要监测界面上哪一个元素，然后保存这个配置，当App启动时会从后台服务器获得产品/运营预先圈选好的配置，然后根据这份配置查找并监测App界面上的元素，当某一个元素满足条件时，就会上报行为数据到后台服务器。有了暴力的全埋点技术方案，很容易联想到按需埋点，可视化埋点就是一种按需配置埋点的方案。现在也有一些公司提供了这类SDK，圈选监测元素时，有的是提供一个Web管理界面，手机在安装并初始化了SDK之后，可以和管理界面连接，让用户在Web管理界面上配置需要监测的元素，有的是直接让用户在手机上圈选元素进行埋点。

优缺点

方式	优点	缺点
代码埋点	按需埋点、灵活精确。	需要开发人员参与成本高，添加或修改的只能在后续版本生效，业务入侵大。
全埋点	可回溯、对业务代码入侵较小。	上报数据量大、大部分都是无用的、筛选困难，方案对打包时间或性能有影响。
可视化埋点	按需埋点，无需研发人员配置，可追溯历史版本生效。	当界面结构发生改变时，圈选的元素可能生效；Android&iOS分平台。

现在已经有多家SDK支持上述的埋点方式中的一种或全部，如Mixpanel、Sensorsdata、TalkingData、GrowingIO、Umeng Analytics等，其中Mixpanel和Sensorsdata已经开源了。

数据采集的过程

一个典型的数据平台，对于数据的处理一般包括以下几个步骤：

采集步骤

除了以上还应有两个部分： 确定需采集的数据、数据校验。
其中第一步是最核心的部分，数据准确性、丰富性、实时性，直接影响数据平台的最终效果。

1. 准确性：就是要保证埋点的正确，埋点事件是满足产品和数据需求的，统计的口径应该是和各方讨论确定好的，这是最重要的。因为若是埋点错误了，一是相当于此次埋点是无效的，做了无用功，对于代码埋点只能等待下次迭代才能重新加上；二是也可能对之前的埋点数据造成影响。所以保证埋点的准确性是至关重要的。
2. 丰富性：埋点是用于数据分析的，埋点元素要足够丰富能满足各种条件的数据分析。比如设备信息、手机型号、操作系统、渠道、运营商、网络环境、地理位置信息、埋点事件信息等。
3. 实时性：尽量保证埋点数据的实时上传，但是如果每一条数据就上报一次的话，上报接口的请求量会特别大。所以一般的策略是：APP启动时上报、退出上报、满足一定条数上报、时间间隔及提供立即上报接口。

另外，数据的传输过程也有一些需要注意的：

1. 批量上传：数据一般都是多条数据批量上传的。
2. 压缩：为减少上传的大小，一般采用GZIP进行压缩。
3. 加密：为保证数据的安全，一般会采用加密策略。
4. 容错：数据若是上传失败，要保存于数据库中，避免丢失。

数据校验的方式：

1. 研发人员可以通过日志校验。
2. 客户端页面显示，将产生的埋点数据悬浮显示；后端页面显示（抓包中转、后端接口实时刷新）。
3. assert断言字段结构

前两步是涉及到客户端，后续一般在服务端处理，不做介绍。

我们项目埋点的演变

目前大多数项目还是采用的代码埋点，因为代码埋点能够比较准确的统计用户行为，而且如果埋点合理相较全埋点和可视化较为简单方便。目前我们所用的埋点方案也是经过多次迭代改进的。

早期的埋点

我们早期的埋点相对比较简单，一般集成统计SDK（友盟、talkingdata等），按照相应SDK初始化，加入页面的统计埋点。遇到一些复杂的业务，使用SDK的自定义埋点即可（比如友盟的计数和计算事件）。
这种方式的好处是，简单方便，维护成本低，不需要自己定义统计的数据格式、上传报文等，SDK中都封装好了直接用即可。对一些小型不太负责的APP，个人觉得已经足够了。
缺点是数据不透明，作为集成方无法获得上传报文。

peacock中的埋点统计（DMP）

1. 中华万年历中广告的统计，一般只统计广告的view、click、loading、start等次数，现已废弃。
2. 启动活跃上报(现已废弃)、基于事件的日志报文及规则。
3. 自定义事件上报

上述的统计策略配合第三方SDK，基本能够满足我们目前的业务需求。但不够完善，一是没有独立的SDK处理这部分逻辑（和peacock耦合），二是报文格式不统一（事件型和自定义型上传报文和接口不一致），三是上报和存储策略待优化（之前数据存储于内存，满足一定条件后上报，不成功则存储于数据库，这样会有数据丢失风险）

Analytics SDK（参考自神策SDK源码）

基于新的采集协议，重构埋点文档，使埋点更完善方便。

优点

1. 独立的SDK，业务逻辑清晰，方便集成。
2. 报文格式和上报接口统一，更简单。
3. 上报字段更丰富，扩展防作弊字段。
4. 加入一些自动化的统计，包括APP启动、退出及相应时长统计，页面PV及时长、各种控件点击事件等。
5. 优化上报策略，保证数据的及时性。（启动、退出、异常退出、自定义上报条数、自定义上报时间间隔、立即上报等）
6. 支持H5的埋点统计。
7. 各种配置更灵活，上报地址、满足上报条数、两次上报时间间隔等

全埋点

原理上主要分为两种方式：

1. 静态Hook： AspectJ实现AOP，编译期修改代码
2. 动态Hook： 运行时替换View.OnClickListener等事件回调（用到大量的反射，对性能有影响）

参考文档：

• Android埋点技术分析
• Aspect Oriented Programming in Android
• AOP 之 AspectJ 全面剖析 in Android

可视化埋点

原理：通过可视化的工具编辑配置可采集的view，APP获取并解析配置，找到view并hook事件上报数据。（当界面结构发生变化时，圈选的元素可能会失效）
Sensorsdata，包含了Android、iOS、js、JAVA等多个版本的SDK
Mixpanel，包含了Android、iOS、js、JAVA等多个版本的SDK
网易移动端数据收集和分析博客

打通APP和H5埋点

H5收集到数据后通过js方法回调到APP内，APP会加上基础参数和公共参数，然后上报数据。神策内打通APP和H5的埋点参考链接。

独立SDK地址参见git地址