数据产品内功 - 埋点

前言

埋点在互联网公司较为常见，这事情说大可大，说小可小。传统行业一般不会重视线上的流量数据，毕竟也无太多场景，但笔者所看到的公司基本就没把埋点埋清楚过，主要问题聚焦在埋点流程混乱，埋点框架混乱，需求定义不清楚，外边讲埋点的文章不少，但很多人把埋点讲的过于复杂，其实一般公司的数据应用中，数据规模有限的情况下，还远达不到如此细节的数据搜集。本章从最基本的内容讲起，手把手教帮你建立起从 0→1 的体系化认知，本文只讨论数据质量最高的自定义埋点，代码埋点（通过研发自有的 SDK 进行事件嵌套）。

埋点本身就是把“[设备/谁]在[时间]对[对象]做[动作]”这个数据作为一条明细报上来，结构化入库。

埋点究竟在埋什么

埋点的价值

从最基础的 APP 的活跃数据、网站的 PV、UV 数据，到需要进一步加工的漏斗、行为路径图，到需要挖掘的智能路径，分析师对于用户行为的分析，都需要埋点基础数据的支持。

埋点 &行为

首先如何定义一个人的行为？行为是指“谁”在什么“时间”对什么“对象”做了什么“动作”，也会说这代表了一个“事件”。我们通常说的埋点指的是埋点技术，埋点技术是指通过在对应的位置加上监控代码采集 sdk，来监控用户在对应位置的操作行为，主要用于监控用户在对应的项目中产生的事件。为了让采集过程规范，简化，通常会使用数据采集 SDK，采集 SDK 可以自研，也可以采购。常见采集 sdk 有神策，GrowingIO，诸葛 IO，

谁

设备：手机，电脑，主要用与对网页，app 的特定唯一标示

用户：用户用户在何种介质中登录，只要用户登录，就采集。用户标示主要贯穿用户在登录状态的行为

浏览器：用户访问 web 页面时，存储在浏览器 cookie 中的信息，用户清楚浏览器缓存后会变化。主要用户外部的 web 页面标示。

微信：这里主要是小程序，分为 openid，与 unionid，具体可参加微信的官方文档

时间

“谁”产生行为的时间，服务器接受时间，前端上报时间，手机当前时间

对象

一个行为的对象，目标，一般是一个按钮，或者页面

app 对象：比如打开了淘宝，打开了知乎，打开了 B 站

页面对象：页面相关的对象，比如进入了 app 首页，曝光了闪屏页，一个页面对象一定属于一个 app 对象，一个 app 对象可能会有多个页面对象

按钮相关的对象，包括按钮，输入框，如点击了“注册”按钮等。一个按钮对象一定属于一个页面内对象；一个页面对象可以有多个按钮对象

动作

“谁”对“对象”产生的行为类型 ，包含点击，曝光，滑动，长按等

app 级别动作：app 打开，app 打开时采集，监控用户打开行为，关闭 app 用户退出 app 时采集，若采集不到则在下次打开时采集。若退回后台 30 秒，再打开，则计算为一次新的打开

页面级别动作，页面展示动作，用户进入页面时采集，用于计算页面的 PV，UV。页面隐藏动作，用户退出页面时采集，用于计算页面的停留时长

按钮级别动作：按钮点击动作，用户点击按钮时采集，用户计算按钮的点击次数，点击用户数；按钮曝光动作量比较大，且实用性小，一般不采集

（当然其实还有“场景”这个要素，比如，wifi，5g 网络）

埋点本身就是把“[设备/谁]在[时间]对[对象]做[动作]”这些个数据作为一条明细报上来，结构化入库。其中[设备/谁]在[时间]会由埋点 SDK 自己生成，不必关心这三个要素，重点是在对[对象]做[动作]。

由此就会有如下步骤：

1、如何把用户行为都抽象在“[设备/谁]在[时间]对[对象]做[动作]”这个框架内，框架本身如何设计？

2、1 如果做好，如何执行？也就是如何让所有的业务侧角色在提需求的时候严格遵循上述的框架？

3、2 如果做好，不断新增的文档与人员岗位的流动，信息传递如何做好传承？

4、123 如果都做好，整套 SOP 流程机制如何提高效率，如何平衡好埋点数据应用高时效性与埋点流程的规范性？

如何埋好点

每个被埋点折磨过的数据产品才是真正的数据产品。埋点是数据驱动最最基本的内容，从最开始的埋点需求规划再到最后数据上报只要有一个环节有坑就会影响数据准确性，而数据准确性估计是每个数据人工作中必须要面对的难题。一旦出现流量类数据的埋点问题，解释成本就非常大。

做好埋点框架的设计

1、如何把用户行为都抽象在“[设备/谁]在[时间]对[对象]做[动作]”这个框架内？

这个框架有两个，一是埋点数据结构化入库的表结构，二是不断填充埋点内容的埋点文档。

其一，埋点数据结构化入库的表架构，这个根据实际情况可分为多张表和一张表。

其二，不断填充埋点内容的埋点文档，重点是在对[对象]做[动作]，也就是做好“事件设计”，如下的文档就是用以做事件管理的文档，各个业务线的产品经理通过如下的文档进行埋点事件的统一维护和传承

这里我们固定对象类型与事件类型固定好对应关系，业务产品经理只需要定义对象类型就行，sdk 会根据对象类型做不同的上报标记：

有了页面的打开，退出事件，页面的停留时长也可以算出来

埋点流程执行

2、1 如果做好，如何执行？也就是如何让所有的业务侧角色在提需求的时候严格遵循上述的框架？

用 SOP 来控制，埋点初期阶段，业务的产品经理的埋点变动需求要在数据产品过一道才可往下进行，随后进行埋点开发，埋点测试，最终进行数据应用的开发与测试，最终回归到业务应用上来。其中数据产品经理一般在研发侧的中后台，与业务侧的埋点数据需求对接有一定距离，且业务方本来就异常繁多，所以需要和业务配合好。前期数据产品经理确认好框架以后，建议以对接业务线具体的数据 BP 来进行埋点审核。

埋点传承

2 如果做好，不断新增的文档与人员岗位的流动，信息传递如何做好传承？

最基本的解决思路就是共建在线文档了，每次产品需求的退出，在经过 SOP 的标准动作执行完成以后，最终落地在相关的产品文档上，文档相关的内容就如问题 1 里的一样，这里纯粹就是如何使用好一个工具的问题。

埋点管理产品化

4、123 如果都做好，整套 SOP 流程机制如何提高效率，如何平衡好埋点数据应用高时效性与埋点流程的规范性？

埋点传承其实已经有了产品化的趋势，毕竟从埋点需求提出→埋点评审→埋点开发→埋点验证→上线的整个过程是极度标准化的，整个流程作为上下游可依赖的线性过程

整个线上的埋点管理过程就是将日常的线下维护工作搬至线上，主要有三个核心：

1、由传统的 EXCEL 或在线⽂档维护元数据和版本到统⼀平台

2、元数据管理和版本管理的质量由取决个⼈素养到统⼀规范

3 、让埋点的图文信息可视化对接，可零成本交接，数据产品避免出现 “埋点客服”

总结

埋点是个苦活累活，不仅要有需求管控能力、数据抽象能力，技术背景，还要有多部门协调能力和全局把控能力。埋点最核心的在于“做好埋点框架的设计”，一个通用的事件管理框架可以降低非常多的数仓解析成本，数据产品要做到以全局视角规划埋点并且具有可扩展性。本章从最基本的内容讲起，直接丢出可以用以参考和维护的事件管理文档，希望能给屏幕前的你提供些许帮助。