code小生,一个专注 Android 领域的技术平台
公众号回复 Android 加入我的安卓技术群
作者:凌空御风
链接:https://www.jianshu.com/p/abdaf64ad553
声明:本文已获凌空御风
授权发表,转发等请联系原作者授权
概念
埋点,是对网页、APP或后台等应用程序进行数据采集的一种行为。通过埋点,可以采集用户在应用中的行为,用于分析和优化产品的体验,也可以为产品运营提供数据支撑。其中比较常见的指标比如PV、UV、DAU、时长、新增、页面点击等,收集的数据一般为:
行为数据:时间、地点、用户、交互的操作等
质量数据:App运行情况、浏览器加载情况、错误异常等
环境数据:手机型号、操作系统版本、运营商、网络环境、设备信息等
运营数据:PV、UV、点击量、日活、留存、渠道来源等
安全数据: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已经开源了。
数据采集的过程
一个典型的数据平台,对于数据的处理一般包括以下几个步骤:
采集步骤
![640?wx_fmt=other](https://i-blog.csdnimg.cn/blog_migrate/006d83b62a5f54f8fdf2d643936f4167.jpeg)
除了以上还应有两个部分:确定需采集的数据、数据校验。
其中第一步是最核心的部分,数据准确性、丰富性、实时性,直接影响数据平台的最终效果。
1. 准确性:就是要保证埋点的正确,埋点事件是满足产品和数据需求的,统计的口径应该是和各方讨论确定好的,这是最重要的。因为若是埋点错误了,一是相当于此次埋点是无效的,做了无用功,对于代码埋点只能等待下次迭代才能重新加上;二是也可能对之前的埋点数据造成影响。所以保证埋点的准确性是至关重要的。
2. 丰富性:埋点是用于数据分析的,埋点元素要足够丰富能满足各种条件的数据分析。比如设备信息、手机型号、操作系统、渠道、运营商、网络环境、地理位置信息、埋点事件信息等。
3. 实时性:尽量保证埋点数据的实时上传,但是如果每一条数据就上报一次的话,上报接口的请求量会特别大。所以一般的策略是:APP启动时上报、退出上报、满足一定条数上报、时间间隔及提供立即上报接口。
另外,数据的传输过程也有一些需要注意的:
批量上传:数据一般都是多条数据批量上传的。
压缩:为减少上传的大小,一般采用GZIP进行压缩。
加密:为保证数据的安全,一般会采用加密策略。
容错:数据若是上传失败,要保存于数据库中,避免丢失。
数据校验的方式:
研发人员可以通过日志校验。
客户端页面显示,将产生的埋点数据悬浮显示;后端页面显示(抓包中转、后端接口实时刷新)。
assert断言字段结构
前两步是涉及到客户端,后续一般在服务端处理,不做介绍。
我们项目埋点的演变
目前大多数项目还是采用的代码埋点,因为代码埋点能够比较准确的统计用户行为,而且如果埋点合理相较全埋点和可视化较为简单方便。目前我们所用的埋点方案也是经过多次迭代改进的。
早期的埋点
我们早期的埋点相对比较简单,一般集成统计SDK(友盟、talkingdata等),按照相应SDK初始化,加入页面的统计埋点。遇到一些复杂的业务,使用SDK的自定义埋点即可(比如友盟的计数和计算事件)。
这种方式的好处是,简单方便,维护成本低,不需要自己定义统计的数据格式、上传报文等,SDK中都封装好了直接用即可。对一些小型不太负责的APP,个人觉得已经足够了。
缺点是数据不透明,作为集成方无法获得上传报文。
peacock中的埋点统计(DMP)
中华万年历中广告的统计,一般只统计广告的view、click、loading、start等次数,现已废弃。
启动活跃上报(现已废弃)、基于事件的日志报文及规则。
自定义事件上报
上述的统计策略配合第三方SDK,基本能够满足我们目前的业务需求。但不够完善,一是没有独立的SDK处理这部分逻辑(和peacock耦合),二是报文格式不统一(事件型和自定义型上传报文和接口不一致),三是上报和存储策略待优化(之前数据存储于内存,满足一定条件后上报,不成功则存储于数据库,这样会有数据丢失风险)
Analytics SDK(参考自神策SDK源码)
基于新的采集协议,重构埋点文档,使埋点更完善方便。
优点
独立的SDK,业务逻辑清晰,方便集成。
报文格式和上报接口统一,更简单。
上报字段更丰富,扩展防作弊字段。
加入一些自动化的统计,包括APP启动、退出及相应时长统计,页面PV及时长、各种控件点击事件等。
优化上报策略,保证数据的及时性。(启动、退出、异常退出、自定义上报条数、自定义上报时间间隔、立即上报等)
支持H5的埋点统计。
各种配置更灵活,上报地址、满足上报条数、两次上报时间间隔等
全埋点
原理上主要分为两种方式:
静态Hook: AspectJ实现AOP,编译期修改代码
动态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的埋点参考链接。https://www.sensorsdata.cn/manual/app_h5.html
独立SDK地址参见git地址
https://github.com/547453396/Analytics_sdk
分享技术我是认真的