埋点体系：一文讲懂埋点设计
引言
前文基于埋点的常见问题，讲述了如何基于埋点需求的流程标准化来推进埋点体系的建设。
接下来本文将从埋点设计过程中的标准和规范来解决埋点不能用、不好用的问题。
01、如何描述一个埋点事件
判定埋点体系建设的好坏可以从完整性、准确性、易用性三个方面衡量，如何在埋点设计过程中，描述好一个埋点事件是保证完整性的思路。
在描述埋点过程中可以参考5W1H原则，围绕Who、When、Where、 What、How 等维度进行埋点事件的描述，描述清楚谁在什么时间什么地点什么场景干了一件什么事情以及怎么干的。
Who， 即参与这个事件的用户是都有谁
按照参与方而言可以分为主动发起方以及被动接受方，如抖音场景下A用户观看了B用户视频，陌陌社交场景下A用户搭讪了B用户）。
按照标识类型而言可以分为用户标识、设备标识等，两者都是为了标识用户、区分用户。
When， 即行为发生时间
在实际场景而言，事件行为的发生事件是由代码实现自动上报。
特殊说明，某些场景下，事件上报时间与行为发生事件可能存在差异，典型的如下单事件，触发下单行为请求接口事件（行为发生事件）与下单请求接口创建订单的时间可能存在不一致情况。
Where， 通常指事件发生时的位置及环境状态
在实际场景而言，事件行为的发生事件是由代码实现自动采集及上报。
用户行为发生时的位置信息如IP、国家、市、县等，行为发生时的前端设备环境状态信息如应用版本、设备制造商、设备型号、操作系统、操作系统版本、屏幕高度、屏幕宽度、网络类型等。
特殊说明，上述前端设备的环境信息，对于服务端埋点而言，需要根据具体的埋点使用需求场景而言进行判定和梳理，确认是否需要基于接口上传这些前端属性，避免影响后续分析。
What， 通常指代事件具体是什么
基于埋点事件类型的不同，会有不同的指代形式。
页面浏览事件，代指页面名称，标识页面所属的具体页面，一方面解决页面浏览事件过多整合问题，另一方面维护的页面名称提升找埋点的效率，提升埋点易用性；
点击及曝光事件，指代具体点击及曝光行为的主体标识，点击事件如点击下单时的订单id，曝光事件如快手列表所曝光的某个视频的视频id等。相信我在使用埋点时发现未记录行为的主体标识，导致无法关联后台业务数据扩维的问题多让人头疼。
- How， 即用户发生事件行为的方式
此处是埋点上报时的重点，记录与事件行为强相关的业务属性，不同的事件需要记录的信息不同，在实际过程中也是最容易遗漏的地方。
现在已经知道埋点设计过程中如何更好的描述埋点，接下来就开始具体讲述如何进行埋点设计。
02、如何进行埋点设计，埋点设计的流程是怎样
当需求方提交需求后，产品经理或数据分析师就进入了埋点设计阶段，需要通过需求调研、明确分析目标、业务拆解、埋点设计及要素设计等，搞清楚在哪些地方埋什么样的点，最终输出埋点需求文档（DRD）。
图片3内，埋点设计前的阶段（需求调研、明确分析目标、业务拆解），可以称为埋点规划环节，此环节主要产出物主要分为指标体系以及业务拆解后的页面、模块、操作行为路径等内容。 下面将对各环节进行概述的同时，讲述一些执行的方法。
1）、需求调研
对接需求方，了解需求背景及目标，需求涉及的业务现状等。 具体执行的方式可以通过业务侧埋点需求文档的描述、与业务方的1v1需求沟通、业务侧的PRD文档等方式进行。
2）、明确分析目标
此阶段是基于需求以及需求调研的情况，确定需求的目标，也就是明确需求及埋点将被用户分析哪些指标。
具体实践上，对于指标的梳理，在行业内有较为成熟的 OSM (Objective-Strategy-Measurement) 指标体系梳理方法论，后续在指标体系系列文章内详细介绍，此处不再详述。
3）、业务拆解
业务拆解的具体实现步骤，第一个步骤是要了解产品结构，也就是先要了解分析的范围是什么，例如需要知道对哪些页面或者哪些功能有分析需求；第二步，就是要针对这些锁定的范围，去明确我们要分析用户的行为有哪些；第三步，要把这些行为，落实到具体的分析维度上。
- 产品结构
明确页面及功能的范围， 典型的页面如活动页、内容页，典型的功能如搜索、登录、注册、会员、付费、签到等。
- 确定分析行为
针对产品的页面及功能，分析有那些行为。 如打开小红书内容页，会存在浏览行为、分享行为、评论行为等。
- 明确分析的维度
针对分析的行为，存在哪些分析的视角和维度。 典型的如抖音的内容详情页，有页面分类、浏览的内容id、内容时长、浏览时长、浏览内容的入口来源，内容发布者用户id、观看用户id等。
4)、埋点设计
基于上述的业务拆解后，我们已经明确的整个需求的背景，具体如涉及的页面及模块、分析的行为、行为涉及的分析视角等内容后，就可以进行初步的事件及埋点参数设计，输出埋点DRD初稿。
事件设计，确定在那些页面、那些模块对那些用户做埋点，明确事件名称等。同时还需要注意对埋点事件进行命名，埋点事件的命名应规范统一、见名知意、全局唯一。
埋点事件的命名，可参考的方案有：
- 事件行为英文直译，如注册用户，reg_user。
- 参考行业通用案例SPM(super position model 超级位置模型)，结合实践简化后的事件命名规范为：业务线+页面+模块控件+埋点事件类型。例如，应用商店- 首页-顶部banner-曝光。
参数设计，埋点参数用于对埋点事件进行描述，一般分为：公参和自定义参数。参数命名可使用属性对应的英文便于理解，不要同一个意思的参数有多个中英文命名。
- 公参
指所有埋点都需要的参数所抽象出来的公共属性。 一般包括，通用属性：如事件发生时间、会话标识id等；设备属性：如用户标识符、机型、安卓版本、网络状态；来源属性：如页面来源等。此部分参数一般会封装进sdk。
| 字段名称 | 类型 | 说明 |
|---|---|---|
| distinct_id | 字符串 | 用户ID |
| time | 日期 | 时间 |
| app_version | 字符串 | 应用的版本 |
| ip | 字符串 | IP |
| country | 字符串 | 国家 |
| city | 字符串 | 城市 |
| province | 字符串 | 省份 |
| lat | 字符串 | 维度 |
| lng | 字符串 | 经度 |
| platform | 字符串 | 手机平台 |
| manufacturer | 字符串 | 设备制造商 |
| model | 字符串 | 设备型号 |
| os | 字符串 | 操作系统 |
| os_version | 字符串 | 操作系统版本 |
| screen_height | 数值 | 屏幕高度 |
| screen_width | 数值 | 屏幕宽度 |
| wifi | BOOL | 是否使用wifi |
| carrier | 字符串 | 运营商名称 |
| network_type | 字符串 | 网络类型 |
| device_id | 字符串 | 设备ID |
- 自定义参数
特定埋点场景需单独定义上报的参数，该部分由具体事件进行设计，通常此类事件进一步可以分为用户属性、事件属性、对象属性三类。
| 参数类型 | 参数字类型 | 举例 |
|---|---|---|
| 用户参数 | 用户标识ID | 用户ID、设备ID、主播ID |
| 用户相关属性 | 用户财富等级、注册日期、注册天数、用户性别、用户年龄 | |
| 事件参数 | 来源 | 来源页面、来源入口 |
| 操作方式 | 支付方式、注册方式 | |
| 操作结果 | 注册成功、支付成功、消息发送成功、拨打成功 | |
| 操作时长 | 停留时长、观看时长 | |
| 对象参数 | 对象特征 | 商品名称、商品单价 |
| 对象标签 | 动态分类、商品分类 |
5)、埋点设计的关键要素
采集方式设计，现有互联网公司埋点采集方式主要是全埋点，代码埋点-前端，代码埋点-后端三种。
在具体的操作形式上，大体上分为两种形式：
- 自定义代码埋点
互联网公司在埋点建设初期，全面的梳理及设计，完成埋点的上线后，后续只需要根据业务的发展迭代完善即可。
- 全埋点+代码埋点
很多互联网大厂业务复杂，如果全部进行代码埋点工作量过大，此时会采用两种方式的结合。
针对APP 启动、APP 退出、页面浏览、点击事件等通用采集事件，使用全埋点记录，满足基本的需求。针对全埋点出现的参数不全的情况，再结合具体场景，完善具体的个性化参数，进行自定义代码埋点。
埋点触发时机及条件设计，在埋点设计过程中，除了确定埋点的事件和参数外，还需要定义埋点的触发条件和时机，明确什么情况下触发数据的采集和上报。
- 触发条件
指在交互行为中，达到何种条件触发相应的埋点事件。
触发条件不同，埋点数据也不同。典型的如曝光埋点的触发条件通过“曝光对象漏出百分比、重复展示是否重复计算”两个维度进行定义。
- 触发时机
触发时机是指在何时触发相应的埋点事件，可分为前端触发上报、前端获取后端结果后上报、后端触发上报、后端获取前端属性后上报四种。
以商品曝光为例，有业务规定曝光时上报；也有业务规定曝光结束上报，结束上报这种可增加曝光时长参数。
03、埋点案例实战
接下来，以经典的电商购物流程举例，讲解埋点实践。
- 需求调研-业务诉求
电商购物流程中-各渠道新用户的核心流程转化情况
- 业务拆解-页面、功能、行为
核心用户行为链路：启动 app > 浏览首页 > 浏览商品详情页 > 加入购物车 > 提交订单 > 支付订单
- 明确分析指标
核心指标：各渠道新增用户数、GMV、各流程转化率
维度：渠道、注册方式、支付方式等
- 埋点设计
基于业务拆解构建埋点，主要包括的事件有启动app事件、商品详情页浏览事件、加购事件、提交订单事件、订单支付事件等。
- 埋点要素设计
明确埋点采集方式、埋点触发时机和条件等信息，即可产出初版埋点设计文档，待各方评审。
04、埋点常见问题
1）、针对相似场景，埋点设计时是合并一个事件还是分不同的事件
针对相似场景下，埋点是否整合，主要考虑两点影响要素，事件所需属性参数差异是否大、分析使用场景上是各自独立还是进行整体分析。
2）、主被动事件的处理
在线上行为中，很多需要记录的埋点事件非用户主动触发，为被动触发， 例如平台头像认证审核、发放优惠券、被其他人关注、被其他人发送消息等此类情况不存在主动事件，主动触发行为的不是用户，用户是行为的接受者，被动受到影响。
对于此类情况需要做好主体及被动接受者的埋点参数区分，避免影响分析结果。
3）、曝光事件的处理
埋点事件主要分为页面浏览事件、区域曝光事件、点击事件等三类，针对区域曝光事件的触发事件往往需要特殊注意。
- 曝光可见比例
区域被曝光展示范围是多少，才算一次有效曝光 ，通常有两种方案，元素曝光即可触发曝光埋点事件或曝光完全可见才能触发曝光埋点事件。
- 有效停留时长
当曝光元素被曝光后且满足有效停留时长才算有效曝光， 通常单位是秒。
- 重复曝光
已曝光元素在页面隐藏起来，然后再满足曝光条件再次显示在页面时是否可以继续触发曝光埋点事件，也就是是否算作一次曝光。
通常一次内容请求不管曝光多少次都算作一次曝光 （比如上下滑动屏幕，只要不刷新发生新请求，算一次曝光）。
4）、埋点参数上报时，对于用户相关事件参数，如何确定是否上报?
- 多重身份用户的设计
在企业应用体系，用户往往可能存在多种角色，如抖音的用户与主播，淘宝的用户与卖家等。要做好用户属性的区分，对不同身份用户的属性进行不同的参数设置。
- 非缓慢变化的用户属性
在实际场景中，针对用户的属性存在一些变化频繁的参数，要做好考量是否需要冗余上报 ，如社交场景的用户财富等级等，因为行为发生时的属性信息与统计分析时的时点信息是不一致的。
总结
本文注重介绍了埋点设计的重要性，从多个方面讲述了如何进行埋点设计。具体包括：
- 如何参考5W1H准则进行埋点设计，描述一个埋点事件
- 具体到埋点设计过程中的流程是怎样
- 埋点设计过程中所需要考虑的各项关键因素
- 以经典的电商购物流程举例进行埋点事件举例
- 埋点过程中常见的一些问题及解决方案
