数据埋点

什么是埋点

埋点是数据采集的一种重要方式，主要记录和收集用户在终端的操作行为。

其基本原理是在app|H5|pc上布置采集数据的SDK代码，当用户的行为满足某种条件后，比如进入某个界面，点击某个button，会自动触发记录和存储，然后这些数据会被实时或延迟传递到终端服务器，或者通过后端采集用户使用服务过程中的请求数据。（前端：客户端埋点，在客户端上写代码SDK；后端：服务器埋点，在服务器上写代码）。

埋点的用途

终端提供商在收集到埋点数据后，通过大数据处理，数据统计，分析，挖掘等加工处理，就可以获得产品的一些基本指标，比如活跃，留存，新增等大盘数据。

如今埋点发挥越来越重要的作用：

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

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

驱动安全：风险识别

埋点的分类

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

目前，大家主要采用前端埋点技术。

前端埋点

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

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

代码埋点

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

优点：

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

缺点：

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

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

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

可视化埋点

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

（有埋点需求，直接操作即可生效！不需要等版本上线才能发布埋点）。

无埋点

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

优点：

收集数据全面，无漏报。

缺点：

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

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

前端埋点的注意事项：

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

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

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

后端埋点

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

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

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

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

注意：

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

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

前后端埋点对比

埋点管理系统

为什么要做买点管理系统

就埋点本身而言，并没有什么技术挑战，但涉及的环节特别多，包括埋点需求提交、埋点设计（定义采集字段、格式、采集时机、上报策略）、埋点开发上线、无用埋点下线等等，这些环节都需要一个有效的流程串联起来，但因为整个流程需要多个团队协作，如业务团队、数据团队、埋点研发团队（又包括后端埋点，不同端的前端埋点，如 iOS 端、Android 端、Web 端、微信小程序端等）。各团队按照规范各司其职、相互配合，如果这些都要靠人「自觉」的协作，那要付出巨大的沟通成本。在实际的工作中，人的「自觉」几乎是不可能的，因为每个角色处在不同的环节上，只会去寻找「局部最优」。所以，我们希望让「系统」来做协调的工作，通过将流程线上化到系统中去，各个团队都到系统中去处理自己负责的事项，使得各环节的输入输出更加的标准化、自动化，以此减少不必要的沟通，提高效率。

全生命周期埋点管理

完善的埋点管理应该覆盖埋点的整个生命周期，包括埋点需求阶段、埋点实施阶段、埋点使用阶段（数据分析），以及埋点下线回收。

使用埋点管理系统上线埋点应该经历如下流程：

埋点管理系统参与了埋点的所有环节，各个团队/角色通过埋点管理系统完成以下工作：

• 业务团队（有埋点需求的团队）：
  • 注册埋点：埋点方案评审之后，满⾜业务需求的埋点信息被确认，包括埋点名称、属性名称、属性数据类型、属性含义、采集时机等。业务团队埋点负责人需要登录埋点管理系统注册埋点，完善相关信息，后续将以此为依据进行研发工作；
  • 埋点属性管理-自定义属性：自定义属性相对于通用属性，是某个事件下特有的属性，由业务方根据埋点方案在系统中维护；
  • 埋点信息查看/编辑：埋点上线之后，需要查看埋点信息来进行数据分析，另外，埋点信息有变化时还需要进行编辑更新；
  • 埋点回数状态查询：埋点上线之后，业务团队需要验证最初需求计划埋点以及属性是否都已上报了数据；
  • 埋点回收：过期的无用埋点需要进行下线操作。
• 数据团队：
  • 埋点属性管理-通用属性：通用属性是指产品/业务层面的公共属性，为避免相同属性出现不同定义，数据团队需要进行统一的定义和管理；
  • 监控埋点数据上报：在埋点上报之后，数据团队需要时时了解数据上报的情况，监控异常。
• 埋点研发测试团队：
  • 埋点信息查询：查询埋点信息，按照需求方录入埋点信息进行开发测试；
  • 监控埋点数据上报：在埋点上报之后，研发团队需要时时了解数据上报的情况，如出现异常情况，需要及时介入解决。