关于作者：我是水大人，资深潜水员，一个基于开发、面向分析、走向全栈的饱经摧残的数据新手，爱折腾不爱玩，爱总结爱思考的老兵，错了改改了又错的惯犯。
0x00 前言
上一篇我们初识了埋点，介绍什么是埋点、埋点的用途和埋点分类，那是不是马上就可以开始设计埋点了，答案是否定的。在埋点设计之前还有很多工作要做。通过本篇的阅读，你将对埋点之前的准备工作和埋点的流程有更加清晰的认识，本篇按顺序介绍如下:
- 了解产品
- 梳理旧需求
- 梳理旧埋点
- 熟悉埋点流程
0x01 了解产品
所谓磨刀不误砍柴工，埋点设计是和产品密切相关的，对产品熟悉可以极大的加快埋点设计的进度。了解产品可以从以下方面入手
- 了解产品的交互
自己亲自下载安装下负责的应用，随意的操作点击，将产品提供的功能服务都尝试一遍，初步划分出产品的几大模块，建立初步的感知。
- 梳理产品的信息流结构
在感知的基础上，将产品的提供的功能抽象出几个实体，然后画出这些实体是如何随着用户的操作进行流动的，西什么样的形式展现的，提供了哪些交互入口。
- 了解产品的未来规划
多个产品经理沟通下，询问下产品目前的定位，近期的计划，和未来的规划，这些信息可能暂时对你的帮助不大，但当你设计埋点的时候，这些信息贵潜意识的影响你的设计方法，以更好的兼容未来产品的改变。
0x02 梳理旧需求
埋点的很大一部分用途是为了做报表呈现当前产品的大盘状态，比如整体的新增、活跃、留存、回流，以及各个功能模块的使用情况。通过对旧需求的梳理，你能明白产品关注哪些指标，是从哪些角度进行分解的，有哪些度量方式此外尝试着将这些指标梳理成体系，比如哪些是技术指标，哪些是业务指标，哪些是故障指标等，对需求的梳理也是同样的逻辑。
0x03 梳理旧埋点
根据作者的了解，绝大部分的公司都没有埋点管理系统，大多都是以excel的方式进行管理，虽然excel管理也不是不可行，埋点的形式天然就具有表格的样式，问题在于埋点人员对埋点管理的认识参差不齐，所以埋点文档百花齐放，纷繁复杂，混乱不堪是常见的。但旧埋点的梳理是必不可少的，试着多向以前的埋点人员了解下，建立app上的交互和埋点文档中事件的对应关系，对快速展开埋点工作大有裨益。
0x04 熟悉埋点流程
要做好一件事，必须知道其具体流程，埋点虽然听起来简单，其实也是一个系统性的工程，需要各方共同参与。以当前主流的前端代码埋点为例，埋点牵涉到产品经理、数据产品经理、数据开发、业务开发、数据测试五个角色，在一些企业的设置中可能并没有数据产品的角色，其角色就会有数据开发来兼任，此外很多的数据测试也是由业务测试来兼职的。但不管角色的多少还是兼职，埋点所遵循的流程改动并不大。埋点开发的通用流程如下图所示：
角色职责
- 产品经理：输出策划文档、统计需求(一般是以报表需求的形式呈现，也是数据产品埋点转换的重要参考)
- 数据产品经理：负责进行埋点转化，对埋点的完整性负责，其一般有两个转化参考点,一是策划文档，根据相应的改动增加相应的曝光、点击等埋点事件，另一个参考就是报表需求文档，通过完善已有的埋点(常见的有增加参数、增加参数值等)或者增加新的埋点来支撑报表需求。
- 数据开发：根据产品输出的埋点转化文档，进行埋点设计，具体体现为埋点参数名、参数值、上报时机等，对埋点的准确性负责。业务开发：根据数据开发输出的埋点设计文档，根据响应的触发时机，将事件相关的设计的附属信息按指定的格式进行上报，对埋点植入的正确性负责、对采集数据的完整性负责（漏掉一些上报时机是很常见的事）。数据测试：根据业务开发的上报，通过测试用例抓包的方式验证数据的上报是否和埋点设计的一致，验证一致后发起埋点验收报告。
注意
- 产品提出统计需求的时候，需要用到哪些数据最好能先和开发沟通一下，是否能获取到，可以极大的减少在埋点需求和设计评审时讨论开发能否实现的耗时。
- 数据测试发起埋点验收报告的时候，上报数据要经过筛选，只核验本次埋点设计改动的地方，并见埋点设计的改动和上班数据的对应关系标注出来，可以极大的加快数据验收的进度。（数据验收目前还有很多的挑战，比如我参数值的层级组合等，只能做简单的自动化）
0x05 总结
本文对埋点之前的准备工作和埋点开发的流程做了简要的介绍，需要强调的是埋点是一个系统工程，需要参与各方高效的协同，这也是提高埋点质量的前提。
