数据埋点|主流的数据埋点采集方案（3）

第一节分享了几个常见场景的埋点，对埋点有了感性的认识；

求知鸟:数据埋点系列(1)

第二节梳理了数据领域的常用术语和黑话:

求知鸟：数据埋点|概念（2）

本讲座从官方文档中寻找信息，学习主流数据埋点采集方案。

0x01 基础埋点理论 SELECT date`日期`, count (DISTINCT uid) `商品点击UV` from table where date ='20180921' and event_id = 'a1234'

如果我们想分析商品的推荐策略，我们通常需要了解商品的曝光、点击、订单转换等数据。那么，我们在埋藏数据时应该注意什么呢？

首先，我认为埋点方案的三个方面是：触发条件的设置、映射关系的管理、收集和报告规则的处理。因此，在学习埋点方案时，应特别注意这三点的设计和处理。

本文讲述了数据埋点系列(1) 埋点报告策略:

1.曝光报告采用实际显示曝光报告策略。只有当事件本身的实际曝光显示在屏幕上时，才需要触发报告策略进行数据报告（曝光像素>0px）； 滑动：在页面内上下滑动时，不重复记录；刷新：刷新当前页面时，重复记录曝光；翻页：下拉到新一页后再返回到前一页，上下滑动不重复记录返回：事件点击到落地页后，从落地页返回（包括返回按钮返回、滑动返回、支付等行为后自动跳转返回），不重复记录录曝光；唤醒：a) 手机锁屏打开，直接显示事件所在页面，不重复记录曝光；b) 应用程序或浏览器在后台被唤醒，显示广告页面，不重复记录曝光；2.无特殊限制定义，埋点需根据坑颗粒端逐一报告，不进行重处理； 注：1.数据埋点中的点击事件在触发点击动作时报告埋点数据。触发条件明显，不易歧义，很少单独强调。2.我们在后续课程中单独介绍了其他类似的滑动、编辑、订单键和加载触发条件。

我们的触发条件设置直接影响数据的真实性。例如，如果我们看推荐模块的点击率，不同的触发条件会得出不同的结论。

以上图片显示，一些用户正在浏览App白 ** 域出现在手机屏幕上，真实显示灰 ** 域数据被加载，但没有出现在屏幕上。然后，当我们计算下一个模块的点击率时，我们会发现模块1和模块2需要使用自己的真实曝光UV分母不能用页面浏览UV作为分母，否则模块1和模块2的对比会非常不公平。

同时，任何触发条件设置、映射关系管理、收集和报告规则处理的条件因素都会影响数据的准确性。我们可以通过这三点来判断数据埋点方案的质量，例如，我经常提到无埋点方案的缺点：

平等的触发条件设置使更多的特殊埋点场景无法满足；混乱单一的映射管理，扩展性能差；参考链接：「学习小组第三周 3课」学习主流数据埋点采集方案 0x02 赞埋点实践

2.1 事件模型

首先要考虑的是如何描述和记录用户的行为。我们在这里使用的事件模型是：

who 访客标识、设备指纹、登录IDwhen 事件发生时间、报告时间where 设备环境、网络环境、商业环境等what 事件标志、事件参数

我们设计了日志模型，可以携带上述信息，并保持必要的可扩展性，并将数据映射到sche ** 在每个字段中，完全记录一次行为。

2.2 采集方式

设计完数据模型后，下一步要考虑的是如何将客户端中的用户行为数据收集到服务端，这主要取决于客户端提供的监控能力。

2.2.1 无痕埋点(或全埋点)

使用浏览器或APP自带监控方式，收集用户浏览页面、点击等行为，可收集的信息主要包括：

页面的url、APP点击元素，如包名xpath路径、title或约定的dom元素

无痕埋点的优点有：

前端接入成本低，不需要额外开发用户收集完整的动作，不会丢失

但也存在以下问题：

有用、无用的数据将无法收集到特殊行为、业务参数收集的信息需要二次标记，当按钮位置不固定、名称重复或页面重建时，用户可以识别无痕迹埋点的准确标记，一般用于快速业务探索粗粒度。

2.2.2 代码埋点

代码埋点是指依靠前端学生定制监控和收集处理。代码埋点的优点是：

具有丰富业务参数的事件触发方法可以灵活定制和分析

以下问题随之而来：

前端代码的开发和管理成本只能到的信息无法支持分析时，只能收集事件启动后的数据。

2.3 埋点sdk

为了简化前端学生的埋点开发，只需要关注业务本身，对埋点的一些协议进行必要的约束，有赞开发了多个终端（js/小程序/android/ios/java）的埋点sdk。sdk默认支持以下功能：

访客标识管理会话管理环境参数默认收集参数的生命周期管理默认事件的收集跨端的sdk通信（如app嵌套h5内部业务特殊处理逻辑日志的格式化、合并和生命周期管理日志的报告机制

前端学生通过sdk开发提供的界面，只需注意：

SDK如何识别初始配置事件需要什么参数事件？

2.4 日志中间层

收集数据后，原始日志仍处于非常简化的状态，需要进一步加工成日志的中间层，主要包括以下环节：

批量上报的日志拆分日志模型的格式化处理信息的二次加工和维度扩展 如IP、http_agent清洁会话信息的补充，如落地页、二跳页、停留时间的计算，按业务拆分日志流和日志表

实时流中间层为以JSON格式存储在kafka并提供相应的JavaBean类别，方便实时任务开发和分析处理，也可以与streamSql结合使用。离线中间层存储在同一表中，字段与实时流格式一致，以日期和业务为分区条件，自动创建所有业务的视图表，方便中间层的统一调整和数字仓库的权限管理。

2.5 位置跟踪规范

在精细操作和算法推荐等应用场景中，需要准确掌握行为的位置。如果每个业务都定制了一套识别方法，那么每个分析工作都需要重新开发，不能重用逻辑，这将极大地浪费开发资源，因此需要制定统一的位置规范。

将位置分为四个粒度：

业务页面(包括页面类型和页面类型)id）展位域(如图中红色部分，包括组件类型和组件序号)(如图中绿色部分，包括展位标志和展位序号)

业务 页面域 组件域 展位域 页面随机码，可以确定唯一的访问位置。根据位置分解的维度组合，可以轻松分析每个粒度的访问、曝光和点击数据。

2.6 埋点管理平台

在表扬的早期阶段，所有业务的埋点计划都被记录下来wiki中。随着业务线和项目的快速增长，wiki记录的缺点也逐渐暴露出来：

注册格式不能统一，关键信息容易缺乏事件搜索不便，分析学生不知道什么事件迭代更新事件不能合并，同时存在多个信息开发进度，测试进度不能监控埋点质量问题不能快速对接

基于开发中遇到的各种问题，我们越来越意识到平台建设的必要性，主要涉及以下能力：

埋点元数据管理和开放能力埋点流程管理能力

当有埋点元数据时，可以扩展更多的操作空间，如：

埋点的自动测试埋点的自助分析埋点的开发提示埋点的质量监控

2.6.1 埋点元数据管理

根据事件模型和位置跟踪规范，我们将元数据的组成分为 业务、 页面、 组件、 展位、 事件

业务:业务类型(微商城、零售等)SDK类型（js/小程序/android/ios/java）唯一的确定性。页面、组件、展位、事件等属于并仅属于一个业务。页面：一种具有相同页面结构的网页或移动终端页面。组件：页面中的块也包括跨页面的可重复使用块。展位：组件中最细粒度的坑有三个位置标志，即增加（顺序排列）、固定（特定位置）和正则标志（复杂布局）。事件：埋葬基本单元，对应用户的动作，如进入页面、点击按钮、商品曝光等，每个事件也可以定义独特的参数。根据其所有权，可分为全球事件、页面事件和组件事件。

2.6.2 项目流程管理

新项目启动时，会有相应的埋点需求，以方便PM管理和跟踪进度以及未来的质量反馈需要项目级管理功能的支持。埋地项目可涉及多个业务，由PM/前端/数据/数据///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////BI/共同参与测试，跟踪项目审批、设计、开发、联合调整、在线等阶段。埋点项目组织了与埋点需求相关的页面、组件、展位和事件。

2.6.4 埋点测试

上线前的埋点测试直接关系到数据质量。早期测试是使用包装抓取工具。肉眼判断每个事件不仅效率低下，而且容易判断错误或遗漏。因此，在元数据收集完成后，为了解决上述问题，我们设计了埋点在线测试功能。

测试用户输入项目和用户标识，在线测试模块将用户标识存储到redis中 检查任务消费实时日志，并定期同步埋点元数据和用户标识 ** ，将收集到的实时日志返回用户项目测试的事件进行校准日志并收集到埋点平台进行汇总，生成概览数据

日志检测项

日志格式是否标准通用业务参数是否收集完整业务、页面、组件、事件是否登记事件参数是否缺失，格式是否符合要求

检测等级分为Warning/Error等级，会有相应的错误信息。

2.6.5 质量监控

测试覆盖面不完整，或系统的日常开发迭代，都可能导致网上埋点的质量问题。这样的场景经常出现在早期:

开发学生误修改代码，导致在线埋藏事件丢失。长期以来，操作学生发现指标波动异常，逐层查询，最终定位问题，但在此期间的数据无法恢复。

为了避免这种情况，需要实时监控在线流量日志，并在第一时间反馈给相关负责人。

2.6.6 埋点分析

早期埋点上线后，分析学生会根据埋点元数据写作sql或者代码，处理实时流和离线表来查询所需的指标。许多数据需求是更常见的场景：

按一定维度查询事件pv/uv指标或界面，分析多种行为的转换漏斗，分析某种渠道的归因

2.6.7 埋点开发过程

早期埋点的设计和对接工作由数据组学生支持。随着业务规模的不断扩大，它逐渐成为发展的瓶颈。依托埋点平台提供的能力和工具，规范了埋点项目的开发过程PM作为流程负责人，协调各方资源，控制各阶段进度。

PM在PRD明确数据需求、定义指标、获取指标等。PM确认开发资源和时间表（前端和分析学生） 相关学生设计并在平台上注册埋地方案。设计完成后，前端和分析学生评估埋地方案 前端学生根据埋地方案开发 开发PM测试埋点，确保所有事件在线测试通过 分析学生提前准确的代码，如果相关学生收到埋点平台报警，需要及时处理问题并反馈影响

通过流程和授权，数据组可以节省人力，资于其他需要发挥数据价值的地方。

2.6.8 埋点开发过程

日志流通的主要环节如上图所示：

1、通过前端监控用户行为，收集http请求上报

2、NIO日志转发到高并发日志接收服务rsyslog再次通过服务器logstash转发到kafka 原始日志

3、J ** A端埋点通过异步请求报告日志nsq中，再通过flume实时同步到kafka 4在原始日志中flink实时ETl任务将原始日志加工成标准的中间层格式，并继续着陆kafka

5、kafka日志通过flume同步到hdfs，文件 按小时切割

6、hdfs通过日志文件spark小时任务转化为hive表

参考文献：赞埋点质量保证

0x03 其他埋点方案Google Analytics百度统计友盟 神策数据BAT ** ……

继续推荐以下信息：

1.使用手册进行神策分析：https:// ** .sensorsdata.cn/ ** nual/

2.友盟_文档中心：https://developer.umeng.com/docs