《七天数据埋点之旅》第一天：初识埋点

关于作者：我是水大人，资深潜水员，一个基于开发、面向分析、走向全栈的饱经摧残的数据新手，爱折腾不爱玩，爱总结爱思考的老兵，错了改改了又错的惯犯。

 

0x00 前言

本篇为《七天数据埋点之旅》的第一篇，通过阅读本篇，你将获得以下三方面的知识：

1. 什么是埋点？

2. 埋点的用途？

3. 埋点的分类？

 

0x01 什么是埋点

数据埋点是数据采集的一种重要方式，主要用来记录和收集终端用户的操作行为，其基本原理是在App/H5/PC等终端部署采集的SDK代码，当用户的行为满足某种条件的时候，比如进入某个页面、点击某个按钮等，会自动触发记录和存储，然后这些数据会被收集并被传输到终端提供商，或者是通过后端采集用户使用服务过程中的请求数据。

一个典型的埋点采集处理流程如下图所示：

0x02 埋点的用途

终端提供商在收集到埋点数据之后，通过大数据处理、数据统计、数据分析、数据挖掘等加工处理，可以得到衡量产品状态的一些基本指标，比如活跃、留存、新增等大盘数据，从而洞察产品的状态。此外更重要的是随着数据挖掘等技术的兴起，埋点采集到的数据在以下方面的作用也越来越凸显：

• 驱动决策：ABtest、漏斗优化、用户增长、bug修复、精准营销、流失用户预警

• 驱动产品智能：智能推荐(千人千面)、场景化提示(私人助理)等

• 驱动安全：风险识别

 

0x03 埋点的分类

从位置上分为前端埋点和后端埋点，从形式上分为显性埋点和隐性埋点，从路径上又可以分为路径埋点和独立埋点，从需求上分为业务埋点和监测埋点。

由于埋点的主要操作过程是以终端的交互界面为基础，制定数据采集的方案，其它的埋点分类也只是从不同的角度来进行埋点设计。前端埋点是当前主要采用的埋点方式，下面主要对前端埋点进行阐述。

 

一、前端埋点

前端埋点是在用户端(APP、Web、客户端)等嵌入数据采集代码，比如友盟等均采用的是前端埋点，比如通过嵌入一段代码就就可以对网页数据的访问数据进行采集。相比于后端埋点，前端埋点能方便收集到用户在界面上的行为数据，比如用户点了哪个按钮、页面之间的跳转次序、停留时长等，这些数据是后面进行数据分析的主要来源。

 

前端埋点技术有以下三类：

 

代码埋点

代码埋点是直接将采集SDK集成在终端，然后不断在此基础上添加调整采集方案，是目前主流的埋点采集方案，其优缺点如下：

优点：

• 高度定制、控制精准、采集的数据丰富准确

缺点：

• 首先是每当有采集需求，需要开发人员不断添加采集代码，工作量大；

• 其次变更采集策略，需要发布新版本，代价巨大，存在滞后效应；

• 最后由于采集代码常驻终端，不断将采集的用户行为数据进行记录和上报，对于终端尤其是移动终端来说还有耗电、消耗数据流量等负载，此外在数据上报传输的过程中也存在丢失数据的风险。

 

可视化埋点

由于代码埋点需要终端开发人员来执行采集方案，对业务的功能开发侵入性较高。有的公司开发出了可视化埋点技术，只需要产品与运营人员通过GUI界面进行鼠标简单点击，就可以随时增加、取消、调整采集数据的位置和方式，此种埋点方式避开了终端开发人员的介入，由需求人员直接执行采集，减轻了需求传递过程中的信息损耗和误解，另外可视化埋点技术往往由服务端直接下发采集的配置文件，而不用跟随版本发布，从而加快了数据采集的流程。

 

具体实现方式参考：

 

具体实现是SDK定时做界面截图，在截图的同时从界面UI的根对象开始遍历所有的可视化子对象，得到其层级关系。根据截图和UI元素的可视化信息重新渲染页面，识别可埋点的控件。当产品人员在后台管理端的截屏画面上点击可埋点控件，设置事件关联方面的配置，服务器保存这些配置，客户端在获取到这些配置信息以后，按照新配置采集数据。

 

无埋点

无埋点与可视化埋点原理基本一致，区别在于无埋点是先遍历所有的控件和操作行为的组合情况，然后将这些组合情况交给埋点后台，由数据分析人员选择对哪些组合的埋点数据进行分析，其优缺点如下：

 

 

优点：

• 收集数据全面，无漏报

缺点：

• 采集数据量巨大，增加了终端流量消耗和服务器存储负担。

• 埋点的上报时机相对呆板，不能灵活的根据特定的场景进行特殊设置

 

前端埋点的注意事项：

• 页面和控件标示上报要从顶层进行合理的设计，层次感要明显

• 埋点数据的漏报和重复上报如何衡量

• 前端埋点不仅可以处理不需要和服务器交互的曝光和点击事件，也可以将与服务器交互的结果，比如关注成功、分享成功、优惠券领取成功等原属于后端埋点里的事件放在前端来上报。

 

二、后端埋点

 

后端埋点为了避免前端埋点的以下问题：

 

• 前端埋点需要对采集的数据压缩、暂存，为减少移动端的数据流量，除一些需要实时上报的重要事件不限制网络环境，其它事件一般只在wifi情况下上报，因此数据会有延迟，丢数据等弊端，而在后端采集数据，由于数据是在内网传输，数据传输的即时性强，丢失数据的风险小。

• 前端埋点采集程序由于需要常驻，监测实时和延迟埋点上报，不可避免的带来额外的耗电。

• 前端埋点若要新增或调整采集方案，需要开发人员修改客户端代码，然后发版之后才能解决，受发布周期的影响较大，而且通常用户的版本更新并不会及时，这将导致新方案不能及时覆盖所有用户。虽然现在部分埋点管理后台也支持热配置更新，但功能一般都很弱，只支持一些基础的埋点事件热更新部署，

 

注意：

• 很多时候并不把后端埋点独立出来，而是混合在前端埋点中，等用户和服务器端的交互返回结果之后，将结果进行上报。

• 对一下需要精确采集的数据，比如代金券发放等，实施的时候尽量采用后端埋点，除非后端无法采集到所需要的数据，前端埋点只是用来参考。此外也可以将业务数据库代金券领取数据同步到数据仓库中进行分析。

 

三、其它埋点

 

• 路径埋点和独立埋点

 

这部分的埋点根据业务对路径的追踪需求和SDK的开发能力，可为每个事件设计上下文的路径信息，路径信息的组成一般由页面、控件、行为三部分组成，而路径的深度也不宜太深，一般小于五层。

 

• 显性埋点和隐性埋点

 

显性和隐性是从用户有感和无感来区分的，有感事件是用户的主动事件，比如展示和点击事件；无感事件主要用来处理后台的数据请求和拉取，用以监控和服务器的数据交互是否正常等，无感事件中常用的是扫描采集，比如app启动之后，扫描各设置开关的状态信息进行上报等

 

• 业务埋点和监测埋点

 

业务埋点是从业务需求的角度而言，比如产品需要统计某个页面的曝光和点击，算法人员需要的推荐项点击率等；而监测埋点是从业务的流程上来讲的，一般是指隐性的（比如服务器交互的内容拉取情况、本地潜在信息的生成情况等），此外业务埋点中的关键部分也可以用作监测埋点。

 

0x04 参考资料

一些资料参考：

• 可视化埋点参考：https://github.com/mixpanel

• 无埋点参考：https://www.growingio.com/

• 产品经理如何做数据埋点：http://www.woshipm.com/data-analysis/1347283.html

 

常见的埋点平台参考：

• growing io： https://www.growingio.com/

• 神策： https://www.sensorsdata.cn/

• 诸葛ＩＯ： https://zhugeio.com/

• talking data: http://www.talkingdata.com/

• 友盟： https://developer.umeng.com

• 百度统计： https://mtj.baidu.com/web/welcome/login

• Google Analytics: https://analytics.google.com

• 数猎天下DataHunter：https://www.datahunter.cn/