本文是Android无埋点系列的开篇——-埋点技术概览，主要介绍Android下的埋点的技术方案

注：本文同步发布于微信公众号：stringwu的互联网杂谈Android无埋点技术概览
本文是Android无埋点系列的开篇——-埋点技术概览

1 背景

埋点是数据产品经理（分析师）基于业务需求，对用户在应用内产生的页面和位置植入相关代码，并通过采集工具上报统计数据。这些埋点数据是推动产品优化和运营的重要参考。而按照埋点采集数据类型不同，可以把埋点采集的数据分为以下几类：

• 点击埋点：用户点击了某一个icon；
• 页面埋点：用户进入应用的某个具体页面；
• 曝光埋点：某个模块（区域）被用户看到的次数；

点击和页面埋点都有明确的触发时间（事件），而曝光埋点则没有明确的触发时间点，一般认为Android中View被渲染出来就认为是一个曝光。很多情况下View被渲染并不代表它是可被用户看到的。

1 Android 埋点技术概览

不同业务（公司）在在进行埋点方案选型时，会根据业务形态去选择最适合自己的方案，一般都离不开这几点：

• 埋点的工作量要小，有更改时最好可以不发客户端版本就生效；
• 埋点的质量要高，能保证数据的准确性；
• 埋点携带的业务数据要尽可能精确，方便后续的数据分析；

1.1 埋点简介

埋点又叫数据埋点，是数据采集领域（尤其是用户行为数据采集领域）的术语，是指在应用中特定流程收集一些信息（用户行为或事件），如用户点击某个icon次数，用户浏览某个页面的时长等等。埋点采集到的数据是数据分析人员用来分析应用的使用状况和为优化产品的重要依据。

1.2 埋点技术

随着技术的进步和发展，互联网各家公司从不同角度，提出了多种技术方案，这些方案可以归类为：

• 代码埋点
• 可视化埋点
• 无埋点
  下面简要介绍一下这几种埋点技术方案。

2 代码埋点

代码埋点，是最早出现的一种技术，也是最基础的一种技术，开发人员按照产品（运营）的埋点文档，在用户行为满足一定条件时（如点击某个icon），调用数据上报的接口上报该行为数据。该技术方案特点：

• 控制精准，可以自由选择上报时机和上报数据，并且可以根据不同的场景定制不同的上报数据字段；
• 埋点方案的修改依赖于终端发版，上线周期长；
  代表方案是国内的友盟，极光等第三方数据统计服务商

3 可视化埋点

可视化埋点是指通过可视化工具选择需要收集的埋点数据，下发配置给客户端，客户端进行配置的解析并采集对应节点的数据。一般是客户端APP在不同的页面截图发送给服务器，由服务器根据该截图，生成需要采集的节点的配置信息，该技术方案特点：

• 埋点的开发量小，数据的发送量级可控，可以直接线上下发配置进行动态埋点；
• 技术方案实现复杂，并且覆盖功能有限，没有办法定制上报的数据字段;
• 数据上报是基于配置的，上报只有从拿到配置时刻开始，没有办法解决数据回溯问题；
  代表方案是国内的GrowingIO,相关的核心技术方案见：开源的Mixpanel
  

备注：图片来源于GrowIO官网

4 Android 无埋点

无埋点并不是不需要埋点，而是指将App内产生的所有的、满足某些条件的行为，全部自动采集并上报到数据后台。在计算时对数据进行筛选，选出可用的数据，该技术方案特点：

• 优点：埋点的开发量小，数据上报全面；
• 缺点：数据量大，上报的数据里可能有大量的没有价值的数据。传统的无埋点技术上报字段有限，并且没有办法定制上报字段；
  代表方案是国内的神策数据,GrowingIO也提供有类似的解决方案

4.1 无埋点背景

Android中的无埋点一般是通过全局监听或AOP技术来实现的。Android传统意义上实现无埋点的两大核心技术：

• View的唯一ID;
• 无埋点实现（代理监听或gradle插件在编译时插桩);

本文不再详细讲解无埋点的两大核心技术，有兴趣的小伙伴可以参考网易团队的无埋点实践文章网易HubbleData之Android无埋点实践

但传统的无埋点有三个致命的缺点：

• 埋点字段有限，没有办法携带精确的业务字段;
• 数据量太大，后台存储压力很大；
• View的唯一ID会随着页面的变化而变化，多个版本的数据需要在后台进行数据映射

这几个缺点也是很多公司在选择埋点的解决方案时没有选择无埋点的原因，这里有没有办法去进行一个改进的设计呢？

无埋点系列下一篇文章：《Android无埋点系列之伪无埋点框架》将会讲到如何基于无埋点的技术，去设计并实现一个满足业务常规需求的埋点框架；

5 参考

• 埋点简介
• Mixpanel
• 网易无埋点
• GrowIO
• 神策数据