埋点——记一次埋点链路的实践

什么是埋点

埋点，顾名思义，在固定的地方埋下锚点。又称事件跟踪，英文名为Event Tracking.主要理解为在关键位置对特点的用户行为和事件进行捕捉、处理和推送的过程。是互联网数据采集分析的重要基石。

为什么要埋点

通常意义上网站落库的数据，都是网站产生的业务数据。如电商网站发布的商品信息、客户下单的订单信息等内容，运营如果有需要可以随时同步到数据仓库或者调取使用，但用户的行为一般不会以业务数据的形式在数据库里存储。因为用户行为具有以下特征：

用户的行为复杂多样：基础的页面访问、按钮点击，以及诸如鼠标动作、滑动屏幕等交互行为，如何定义哪些行为收集，哪些行为忽略十分考验产品设计，在初期设计业务系统时一般不做考虑。
用户的行为数据量大：用户在产品上的行为互动频繁，一个中型的公司往往一天就会产生亿级以上的日志数据
业务对用户的行为数据无直接依赖：产品的主业务功能和用户的行为数据显性关联不大，虽然它对指导如何对用户进行后续的个性化服务有很大作用，但不会产生即时的影响。

但当公司业务量发展壮大后，往往就会产生诸如以下需求：

运营上线了帮助用户答疑解惑的功能模块，但是，无法衡量其效果。
访问商品主要的人有多少，最终购买的人又有多少？
如何知道功能的优化有没有效果

基于以上种种原因，需要一个专门收集用户行为数据的埋点分析系统，此时就需要用到埋点操作。

我司的系统介绍

总体结构

无论如何设计系统，万变不离其宗，一个埋点分析系统总归脱离不了以下4个模块：

埋点采集SDK: 收集用户行为数据，并进行上报
数据存储：数据接受上报数据，筛选解析所需数据，初步清洗并落库
数据分析：将基础埋点数据转化为可理解的各种指标
数据可视化平台：根据各种维度，提供给用户丰富的数据可视化展示

埋点方式

埋点方式多种多样，按照埋点位置不同，可以分为前端（客户端）埋点与后端（服务器端）埋点，其中前端埋点包括：代码埋点、全埋点、可视化埋点。

	代码埋点	可视化埋点	全埋点
优势	按需采集；业务信息更完善；对数据的分析更聚焦	开发量少，解决了代码埋点的埋点代价大和更新代价大两个问题	和可视化埋点很像。而从实际的实现上看，二者的区别就是可视化埋点先通过界面配置哪些控件的操作数据需要收集；“无埋点”则是先尽可能收集所有的控件的操作数据，然后再通过界面配置哪些数据需要在系统里面进行分析。
劣势	开发人工工作量较多	可视化埋点能够覆盖的功能有限，目前并不是所有的控件操作都可以通过这种方案进行定制	数据准确性不高，上传数据多，消耗流量搞，数据维度单元（点击、加载、刷新）
采集说明	嵌入sdk，定义时间并添加好事件代码	嵌入sdk,可视化圈选定义时间	嵌入sdk
典型案例	友盟、有赞、TalkingData	Mixpanel、神策、诸葛IO	有赞，heap,GrowingIO
厂家	以业务价值为出发点的行为分析	用户在页面的行为与业务信息关联较少，页面量较多且页面元素较少，对行为数据数据的应用较为浅	无需采集事件，适用于活动页、着陆页、关键也；需设计体验衡量

考虑到前期希望只投入较少的开发资源，并且满足重点的用户行为数据采集，因此，最后决定采用代码侵入式埋点方案。

同时由于代码埋点接入成本较高，设计了一套可以实现自动化植入的组件，这点由前端同学负责，这里不再展开。

埋点模型

目前行业内大部分公司都是基于事件模型或者事件模型的变种，即完整描述 Who、When、Where、How 和 What 五大要素。

Who: 用户和设备的身份特征
When: 埋点触发的时间
How：埋点发生时，用户当前的状态或者什么样的事件
Where: 准确定位一个事件发生的位置。
What: 在事件发生位置上的内容信息，这里采集的内容由业务决定

同理，回归到我们公司，基于用户行为分析这个大目标，采集的数据都是围绕着两个主题，即：Event（事件/行为）和 User（用户）。

围绕“事件“我们采集了：事件的类型、发生时间、页面位置等信息，组成事件唯一标识。

围绕”用户“我们采集了：用户 IP、操作系统、浏览器信息、屏幕分辨率等，并生成用户唯一标识植入 Cookie 中。

  bdata: {}, //业务数据
  createTime: "1571038815128", // 创建时间
  evt: "browse", // 事件类型
  ipAddr: 122.226.174.195, //ip地址
  logType: 2, // 触发类型
  lver: 1.1.0, //版本
  mx: 0, // 页面位置坐标x
  my: 0, // 页面位置坐标y
  os: "Windows/7", // 操作系统
  pre: "https://www.xxx.cn/", // 来源地址
  scr: "1920x1360", // 屏幕分辨率
  url: "https://www.xxx.cn/", // 页面地址
  userId: "001", // 用户标识
  utmCnt: "a0004.2ef5001f.0001.0001.d814bf60ee5511e99397b37fe9083257", // 触发位置
  utmUrl: "a0004.2ef5001f.0001.0001", // 来源位置
  uuid: "d7fd8de0-ee55-11e9-9397-b37fe9083257", // 浏览器唯一标识

utm码解释：

A:站点/业务，一般以站点编码的形式记录，也可记录平台，如 iOS、小程序等
B:页面
C:页面区块，对页面进行大的区域划分编号
D:区块内点位：小区域内的位置编号
E:一次请求一个页面的唯一标识值，一个按特定规则生成的UniqueID，用来区分不同的Session或者点击的

utm在下面实践案例中会解释使用原理。

埋点管理

当公司还处于初创公司，规模很小时，使用 Excel 或者Word管理对埋点使用上影响不大。但是当公司业务快速发展，从一个产品变成多个产品，从几十个埋点变成几千个埋点，你能想象手动用文档管理的痛苦吗？所以随着公司发展，一个规范埋点的管理平台是必不可少的。

埋点管理平台负责管理埋点的元信息，通过权限控制，有效的抑制了埋点的无序，解决了埋点的录入和查找需求。

主要涉及以下几点能力：

埋点元数据的管理及开放能力
埋点流程的管理能力（暂无）

数据存储

目前基础埋点数据存储在阿里云的 LOG Service，能满足我们接入方便的需求，还满足我们大部分的查询需求：

提供日志的实时消费接口
查询手段丰富
能够添加实时索引

、

链路实践-服务窗埋点案例

背景

随着数据分析的精细化，除了需要知道用户在页面的哪个位置做了点击、哪个位置做了曝光，还需要把用户的浏览行为串成链路来分析。比如想要知道用户是如何到达一个特定的商品页面的，是通过首页的广告位，还是通过会场活动，抑或是首页／图墙／商铺／详情这样的浏览链路过来的，这就需要串联多条日志才能完成相关的分析工作。

那么如何把一条链路的用户行为整合成链路？以下就是对从服务窗主页确认支付的链路进行埋点，清洗整合链路的一次实践。

埋点链路

链路简图

埋点位置

主页-服务商品

服务商品详情页

确认下单页

这里流程可以分为四步，首先，用户进入政采云服务窗首页，并在左侧或者中间模块选择服务窗商品点击，然后，点击商品后进入商品详情页，其次，在详情页点击立即购买进入下单确认页，最后，在确认页中点击立即下单购买服务商品。这是在一个电商平台中用户操作行为中较为常见的一种流程，也是一个关键流程。

我们在上述的三个页面中会采集的数据有以下三种：

页面进入/离开自动埋点按钮点击埋点链接点击埋点

链路串联

回答之前在埋点模型中留下的疑问，即utmCnt和utmUrl字段有什么作用。

这两个字段是用来确认事件发生位置，串联用户行为的。在每条日志中都会携带这两个数据。举个例子，在页面操作中，最常见的一种方式就是链接的跳转。

我们公司模仿了阿里的spm超级模型原理：

使用这个位置模型的好处是显而易见的：

需要按页面类型统计PV，那么取a.b两个字段分组聚合就可以了。如果要统计具体页面模块的流量，那么统计到a.b.c字段就好了。要精确定位某一个推荐栏位的效果，就需要用到a.b.c.d四个字段。

同时，通过本页面abe（utm-cnt）和来源页的abe(utm-url)，就可以串成一条完整的用户行为链。

表结构

字段code	字段名称
operator_id	用户ID
utm_pre	来源地址
utm_cnt	当前地址
evt_type	自定义事件类型
log_type	页面事件
count	次数
server_id	服务商品id
pt	日期（天维度）

数据分析

单页面分析

从单个页面的角度来看，从基础埋点数据我们就可以得到很多维度的数据:

链路分析

无序漏斗：

进入服务商品之列表后，我们可以将进入页面的 UV 作为第 1 个数据
将点击服务商品打开商品详情页，点击人数作为第二个数据，以此类推，就此组成一个漏斗模型
我们可以计算出每个步骤相对于前一步的数量百分比，这就是一个无序的漏斗

假设部分用户可能从第三步直接进入，这时候就可能存在百分比超过 100% 的情况

有序漏斗：

步骤和无序漏斗类似，只是会以用户为维度进行筛选，只保留从第 1 步到最后一步的那些用户，并不把从中间进入的一些用户计算在内。这样就使得转化百分比必定小于等于 100%，也让数据更具有参考价值。

问题

页面回退行为的识别,比如从详情页回退到商品列表页面，再次打开另一个详情页,次数转化率怎么算？
当存在页面301/302 重定向的行为时，链路参数怎么处理？
订单成交链路时，用户先加了购物车，过后，再从购物车里下的订单，又怎么追踪原始成交链路？

思考

还有更多的类似问题，都是用户行为日志链路整合过程中需要解决的。虽然具体到每个小点，单从技术的角度来说，可能未必很难，但要完善，具备通用化，还有很长的一段路可走。这是一个会随着业务的发展，需要持续改进的工作。

后续action

搭建埋点测试系统，提供方便完善的自动化测试，为快速接入埋点提供支持。

微信公众号

文章同步发布，政采云技术团队公众号，欢迎关注