有赞埋点实践

一、前言

大数据应用一般会有采集、加工、存储、计算及可视化这几个环节。其中采集作为源头，在确保全面、准确、及时的前提下，最终加工出来的指标结果才是有价值的。而埋点作为一种重要的采集手段，可以将用户行为信息转化为数据资产，为产品分析、业务决策、广告推荐等提供可靠的流量数据支持。在业务需求少的情况下，可以运用一些简单的方法快速采集用户行为。但如果业务线、终端众多，数据需求多样，就需要设计好埋点模型和采集规范，工具化、平台化、流程化的管理来保证埋点的质量。

二、事件模型

首次需要思考的是，如何描述和记录用户的一次行为。这里我们使用的事件模型，即：

• who 访客标识、设备指纹、登录ID
  

• when 事件发生时间、上报时间
  

• where 设备环境、网络环境、业务环境等
  

• what 事件标识、事件参数
  

我们设计了可以承载以上信息的日志模型，并保持必要的可扩展性，将数据映射到 schema 的各个字段中，一次行为便完整的记录下来。

三、采集方式

数据模型设计好后，接下来要考虑的是如何将客户端内的用户行为数据采集到服务端，这里主要依赖于客户端提供的监听能力。目前有赞支持两种采集方式：

3.1 无痕埋点（或全埋点）

利用浏览器或 APP 自带的监听方式，对用户的浏览页面、点击等行为进行收集，可以收集到的信息主要有：

• 页面的url、APP的包名等

• 点击元素的xpath路径、title或约定的dom元素

无痕埋点的优势有：

• 前端接入成本低，不需要额外开发

• 用户动作收集完整，不会漏失

但同时也会存在以下问题：

• 有用、没用的数据都会收集

• 无法采集到特殊的行为动作、业务参数

• 采集到的信息需要进行二次标注，才可以被用户识别

• 当按钮的位置不固定、名称存在重复或页面重构时，无法做到准确的标识

无痕埋点在有赞一般用来做粗粒度的快速业务探索。

3.2 代码埋点

代码埋点是指依赖前端同学，自定义监听和收集处理。代码埋点的优势有：

• 事件标识明确

• 业务参数丰富

• 事件的触发方式可以灵活自定义

• 分析更方便、精确

随之而来的是以下问题：

• 前端代码的开发、管理成本

• 只能收集到事件上线之后的数据

在业务需求复杂，无痕埋点收集到的信息无法支持分析时，就需要进行代码埋点。

四、埋点 sdk

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

• 访客标识管理

• 会话管理

• 环境参数默认收集

• 参数的生命周期管理

• 默认事件的收集

• 跨端的sdk通信（如app嵌套h5页面）

• 内部业务的特殊处理逻辑

• 日志的格式化、合并、生命周期管理

• 日志的上报机制

前端同学通过 sdk 提供的接口进行开发，只需要关注：

• SDK的初始化配置

• 事件怎么标识

• 事件需要哪些参数

• 事件如何触发

五、日志中间层

数据收集上来后，原始日志还处于非常精简的状态，需要进一步加工成日志中间层，主要有以下几个环节：

• 批量上报的日志拆分

• 日志模型的格式化处理

• 信息的二次加工和维度扩展 如IP、http_agent的解析等
  

• 异常流量的清洗

• 会话信息的补充 如落地页、二跳页、停留时长的计算
  

• 按业务拆分日志流和日志表

实时流中间层是以 JSON 格式存储在 kafka 中，并且提供对应的 JavaBean 类，方便实时任务开发解析处理，并且也可以与 streamSql 相结合使用。

离线中间层是存储在同一个表中，字段与实时流格式保持一致，以日期和业务作为分区条件，并会自动创建所有业务的视图表，方便中间层的统一调整以及数仓的权限管理。

到这个阶段，有了通用的日志模型和sdk，埋点工作可以标准化的开展起来。但随着承接的业务越来越多，更多的问题在等待着我们。

六、位置追踪规范

在精细化运营及算法推荐等应用场景下，需要非常精确掌握行为发生的位置场所。如果每个业务都自定义一套标识方式，那么每次分析工作都需要重新开发，无法复用逻辑，这将极大的浪费开发资源，因此需要制定出统一的位置规范。

我们将位置分成了四个粒度：

• 业务

• 页面域（包括页面类型和页面id）

• 组件域（如图中红色部分，包括组件类型和组件序号）

• 展位域（如图中绿色部分，包括展位标识和展位序号）

业务 + 页面域 + 组件域 + 展位域 + 页面随机码，可以唯一确定一个访问的位置。基于位置分解出来的维度组合，可以很方便的分析出各个粒度的访问、曝光、点击数据。

类似的还有算法追踪规范，在此不作展开。

七、埋点管理平台

有赞的早期阶段，所有业务的埋点方案都是记录在 wiki 中。随着业务线和项目的快速增加，wiki 记录的弊端也逐渐暴露出来：

• 登记格式无法统一，关键信息容易缺失

• 事件查找不便，分析同学不知道已有哪些事件

• 迭代更新事件无法合并，同时存在多份信息

• 开发进度、测试进度无法监控

• 埋点质量问题无法快速对接

基于开发中碰到的各类问题，愈发的让我们意识到平台建设的必要性，主要涉及以下几点能力：

• 埋点元数据的管理及开放能力

• 埋点流程的管理能力

当有了埋点元数据，可以延伸出来更多的操作空间，如：

• 埋点的自动测试

• 埋点的自助分析

• 埋点的开发提示

• 埋点的质量监控

7.1 埋点元数据管理

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

• 业务：由业务类型（微商城、零售等）和SDK类型（js/小程序/android/ios/java）唯一确定。

• 页面、组件、展位、事件等属于且仅属于一个业务。页面：具有相同页面结构的一类网页或者移动端页面。

• 组件：页面内的区块，也包括跨页面的可复用区块。

• 展位：组件内最细粒度的坑位，有三种位置标识，即递增（顺序排列）、固定（特定的位置）和正则标识（复杂布局）。

• 事件：埋点基本单元，对应用户的一个动作，比如进入页面、点击按钮、商品曝光等，每个事件还可以定义独有的参数。按其归属，可以分为全局事件、页面事件和组件事件。

7.2 项目流程管理

当一个新项目启动时，会有对应的一批埋点需求，为了方便 PM 管理与追踪进度，以及日后的质量反馈，需要有项目级的管理功能来支持。

埋点项目可以涉及多个业务，由 PM/前端/数据/BI/测试等共同参与，并跟踪从立项到评审、设计、开发、联调、上线等各个阶段。埋点项目组织了埋点需求相关的页面、组件、展位和事件。

7.3 埋点测试

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

1. 测试用户输入项目和用户标识，在线测试模块会将用户标识存储到redis中

2. 校验任务消费实时日志，并定时同步埋点元数据和用户标识集合，以此校验日志并收集到埋点平台中

3. 将收集到的实时日志返回给用户

4. 项目已测试的事件进行汇总，生成概览数据

日志检测项

• 日志格式是否标准

• 通用业务参数是否收集完整

• 业务、页面、组件、事件是否登记

• 事件参数是否缺失，格式是否符合要求

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

测试结果

使用不同图标来标识检测状态，并且给出本轮测试的汇总数据。

项目测试概览

汇总项目中所有事件的测试状态，并给出失败事件的明细日志。

用户标识

为了方便测试同学快速找到自己的用户标识，平台提供了 pc 链接、手机扫码、手机号等快捷查找方式。

7.4 质量监控

测试的覆盖面不全，或者系统日常的开发迭代，都有可能会导致线上埋点的质量问题。早期常常会出现这样的场景：

开发同学误修改一段代码，导致线上埋点事件丢失，很长一段时间后，运营同学发现某个指标波动异常，逐层查询，最终定位问题，但这期间的数据已无法恢复。

为了避免这种情况一而再，再而三的发生，就需要对线上的流量日志实时监控起来，并且第一时间反馈到相关负责人。

详细内容将在下篇埋点分享中介绍

7.5 埋点分析

早期埋点上线后，分析同学会根据埋点元数据，通过写 sql 或代码的方式，处理实时流和离线表来查询出想要的指标。其中有不少数据需求都是比较通用的场景：

查询某个事件按一定维度pv/uv的指标或接口，分析多个行为的转化漏斗，某类渠道的归因分析

这部分可以通过通用分析模型自动处理，从而提升分析效率。

详细内容将在下篇埋点分享中介绍

八、埋点开发流程

早期埋点的设计与对接工作都是由数据组同学来支持，随着业务规模的不断扩大，已经逐渐成为开发的瓶颈。

依托于埋点平台提供出来的能力和工具，我们规范了埋点项目的开发流程，改由 PM 做为流程的负责人，协调各方资源，并把控各阶段的进度。

开发流程如上图：

1. PM在PRD中明确数据需求，给出指标的定义、获取指标的方式等。

2. PM确认开发资源及排期（前端、分析同学）

3. 相关同学设计并在平台上登记埋点方案，设计完成后前端、分析同学对埋点方案进行评估 前端同学根据埋点方案进行开发

4. 开发完成后，前端和PM对埋点进行测试，确保上线前所有事件均测试通过

5. 分析同学提前准确代码，埋点上线后第一时间产出相关指标

6. 若相关同学接收到埋点平台报警时，需要及时处理问题并反馈影响通过流程和赋能，数据组可以节省出人力，投入到其它需要发挥数据价值的地方。

核心业务流程中的埋点仍由数据组介入管理，需要严格保证其质量。

九、埋点底层框架

日志流转主要环节如上图：

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

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

3、JAVA 端埋点通过异步请求将日志上报到 nsq 中，再通过 flume 实时同步到 kafka 原始日志中

4、flink 实时 ETl 任务将原始日志加工成标准中间层格式，并继续落地到 kafka

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

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

十、未来展望

目前埋点平台支撑了有赞微商城、零售、美业、精选、分销、有赞云、内部系统等十几条业务线，平均每月 20+新项目的项目，在支持已有流量需求的同时，我们也在思考如何进一步提升开发效率和发挥数据价值：

• 更加友好的平台引导，让不懂埋点的小白用户能快速上手

• 前端开发效率提升，sdk与前端框架结合，可视化、配置化埋点

• 降低sdk上报的丢失率

• 全端的用户日志快捷查找，提升测试和排查问题效率

• 更智能的质量管理，快速定位和解决埋点问题

• 实时日志中间层与业务域的维度扩展

• 无痕埋点的页面自动归类标识

• 分析效率提升，与指标库打通，以及更易用的转化和归因模型来快速定位问题

• 支持算法ABTest实验分析