如何建立埋点规范？
《数据埋点，一次讲个够》系列文章的第三篇，讨论埋点业务的流程规范，主要讨论：
- 埋点业务过程中涉及的角色及其职责；
- 一条完整的埋点 workflow 长什么样子？
一、角色与职责
一个完整的埋点业务流程会涉及业务方、埋点研发测试团队、数据团队：
- 业务方：产生埋点需求，通常是业务线的营运人员、产品经理、数据分析师，他们根据业务，提埋点需求，埋点完成之后做数据分析，他们主要的工作是输入原始需求、埋点上线后消费数据。
- 埋点研发测试团队：负责埋点开发、测试、上线。
- 数据团队：负责定义埋点模型，接收埋点数据上报，存储数据、处理数据、展示数据。
不难看出，一个具体的埋点业务参与的各方需要大量协同配合。企业应该有一个与埋点业务流相对应的组织架构，来保证埋点采集的质量和效率。根据多年的埋点工作经验，有三个角色对埋点工作的开展有非常关键的作用。
- 需要设置一个角色来统一规划整体的埋点工作，负责组织协同各个业务线，制定埋点流程和规范，并推广规范的落地与执行，确保各业务线的数据接入符合规范，保障数据质量，我所在的团队由数据产品经理来负责。
- 对于公司具体业务线的埋点，需要有一个业务负责人，负责该业务线的埋点需求梳理、埋点设计、数据上线应用推广、日常使用支持和培训，这个角色，一般由业务线的数分、有数据 sense 的产品、或者有业务 sense 的研发担任。
- 关键的角色是具体业务线的埋点技术负责人，一般来说每条业务线会有多种客户端的产品，埋点的开发可能会涉及 Android 端、iOS 端、微信小程序端、服务端，需要有一个技术接口人统筹埋点的开发工作，这个角色可以由前端开发负责人担任。
二、埋点业务流程
上面这张流程图贯穿了埋点的全过程，将上面提到的多种不同的角色串联协同起来，保证埋点采集的高质量、高效率，主要环节如下：
- 埋点需求提交：该环节由业务线需求方发起。通常是业务线的营运、产品、推广，或者是数分，他们根据业务数据分析需要，提出埋点需求。业务方需要发出正式的需求邮件给埋点研发测试团队、数据团队。
- 需求评审：埋点需求评审由数据团队主导，埋点研发测试团队参与，业务方确认。数据团队根据业务方需求进行埋点方案设计，输出 DRD，组织需求评审。在需求评审会上，埋点研发测试团队确认需求可行性，业务方确认事件设计方案符合业务需求。如一次评审没有达成一致，将多次组织需求 review，直到三个团队达成一致。
- 埋点开发：在埋点开发之前，业务方需要在线注册埋点信息，信息的内容须和最终评审通过的 DRD 保持一致。埋点研发团队必须以线上注册的埋点信息为准进行埋点开发。
- 埋点测试&验收&部署上线：埋点数据测试由测试人员完成，测试完成后由数据团队、业务 方验收后，由研发人员部署上线。
- 埋点应用（数据分析）：埋点上线后，业务方可通过数据提取、用户行为分析平台、用户画像标签系统等方式消费埋点数据。
理想的情况下，一个埋点上线要经历上述五个步骤。
而在实际中，很多团队在处理埋点业务时没有形成内部的流程规范，带来的后果是埋点数据质量差，数据的价值难以发挥。
比如：要统计某个行为的触发人数时发现没有埋点，数分在提取数据时发现有很多相似的字段不知道该用哪个，研发说某个埋点已经上线了可数据库里怎么也查不到数据，某个埋点起初上线的时候是正常的但从某个时候开始就没有数据上报了。
要解决这些问题，需要把埋点当做一条独立的研发任务来看待，而不是产品开发过程中顺便做一下的任务。
还有一点需要强调的是，流程的制定是很简单的，画一个图，发一个文，但如果流程规范只是流于形式，无法真正的落到实际的环节中去，一切努力也只是白费。
因此，我们还需要进一步对流程规范中每一个环节的输入输出做更详细的要求。
1. 埋点需求提交
1）提需求并不容易
埋点需求通常是业务方的营运人员、产品经理、数据分析师根据业务数据分析需要， 提出埋点需求。提需求并不是一件显而易见的事情，也需要学习。
Thea 之前所在的团队，在埋点需求提交环节，只要求业务方描述清楚要在哪些维度下看哪些指标，数分会梳理指标、维度完成埋点设计。
这样的流程对提需求的业务人员来说是非常友好的，他们不需要去说明为什么要看这个指标、在这些维度下分析指标对业务的价值，甚至在很多时候业务人员并不清楚业务路径的全貌，他们只关注路径上的某个环节上的指标，提上来的需求都是「局部的」、「临时的」、「一次性」的。
基于这样的需求设计出来的埋点也同样是「局部的」「临时的」「一次性」的，后续随着业务路径的调整，哪怕是小小的微调，也会导致埋点不可用要重新设计。
比较抽象，来一个具体的例子，用户在社区中发帖子。
当前，用户在社区中发帖子有两个入口，入口 A、入口 B，点击发送帖子后，会进入编辑帖子的内容页面，内容页面编辑好之后，点击发布就可以发布帖子。
业务方希望分析发帖子的漏斗，但由于业务方只知道入口 A，不知道入口 B 的存在，于是提出的漏斗是：点击入口 A 的用户数 > 进入编辑页面的用户数 > 点击发布并成功发布帖子的用户数。
基于此数分设计了两个事件「进入编辑帖子页」、「发布帖子」两个事件（因为数分认为编辑帖子页面只有唯一入口 A，基本上点击 入口 A 的人数 = 访问帖子编辑页面的人数）。
在埋点上线后的某一天，业务方说埋点数据有问题，来找数分核对数据，发生了如下对话。
- 业务方：「发布帖子的埋点数据有问题。」
- 数分：「什么问题？看起来没毛病啊，昨天有 10000 个人进入了编辑帖子的页面，有 5000 个人成功发布了帖子。」
- 业务方：「可以入口 A 所在的页面一的浏览人数只有 2000 人，怎么可能有 10000 多人点了入口 A 呢？这不符合逻辑，是埋点上报出错了吧？」
- 数分：「怎么可能？我来看看入口 A 页面一的访问人数。」
…
- 数分：「这不科学啊，难道发布帖子的入口不止 A？」
- 业务方：「我了解到的，只有入口 A。」
- 数分：「那我们去找社区的产品经理沟通确认下。」
…
- 数分：「果然，还有一个入口 B 也能发布帖子。这样就清楚了，这是合理的，埋点数据上报没有问题。」
- 业务方：「好吧，如果是这样的话，我希望能够区分通过不同入口发布帖子的用户数。」
- 数分：「额，你之前提需求的时候也没说，当前的埋点做不到，要区分的话，只有加埋点字段，要等下个版本才能上线，并且只有在新版本中才能区分。」
- 业务方：「好吧，也只能这样了。」
- 数分：「你看一下，新的埋点字段，没问题的话研发就这样开发了。」
这是数据团队和业务团队之间时常出现的场景。究其原因是掌握更多业务知识的业务方没有向数分提供完整的信息（当然数据分析也没有进一步询问，业务怎么说怎么做），数据分析设计的埋点没有覆盖完整的流程，导致埋点不可用。
为了避免这样的问题发生，在埋点需求提交阶段，要求业务方对业务流程给出详细的说明，包括业务功能要引导用户达成什么目标，业务完成的路径如何，最好能提供用户体验地图。
总之，要求业务方自己先能把业务路径梳理清楚，提供尽可能多的业务背景。
2）提交需求
我们要求业务⽅发正式的需求邮件，下面的截图是我们团队在用的模板。
模板要求的信息和业务方要做的业务梳理是高度相关的，业务方须严格按照线下邮件流程进⾏提交，在邮件中说明要埋点的产品、端的类型、所属业务、业务路径、统计指标、维度、期望上线日期等信息。
收到邮件后，数据团队在两个工作日内对接业务方沟通需求细节。
2. 需求评审
需求评审环节由数据团队主导，通常是负责该条业务线的数据分析师。又分为三步：一是设计埋点，二是组织埋点需求评审会议，三是埋点注册。
1）埋点设计
数分在收到埋点需求邮件之后，仔细阅读需求，找业务⽅沟通需求细节，基于业务路径设计埋点，尽量做到对业务流程全面覆盖。
埋点设计的结果是输出埋点 DRD，关于如何设计埋点，在系列上一篇文章中已经有很多描述，请点击阅读。
2）埋点需求评审
数分组织埋点研发测试团队、业务方进行埋点需求评审，评审需要确认以下要点：
- 埋点研发测试团队确认需求可行性
- 业务方确认埋点设计方案符合业务需求
如一次评审没有达成一致，将多次组织需求 review，直到三个团队达成一致。需求评审完成之后，后续的开发埋点严格按照文档进⾏，如有需求调整需要通过数分变更，并由数分通知相关方。
3）注册埋点
埋点注册要做的是将埋点 DRD 中的信息录入到线上的系统，这么做的目的和埋点管理有关，整个埋点生命周期：新增、回数、迭代、下线都在线管理，这样可以保证埋点不会越用越乱。
这块的内容会在下一篇再来讨论，这里先不展开。
3. 埋点开发
完成埋点注册之后，研发就可以开始 coding 了。研发团队可以自研埋点 SDK，自己实现全埋点、代码埋点、可视化埋点这些采集方式，也可以采用开源的埋点SDK，这样可以节省很大的工作量。
下面的表格是比较了市面上主流用户行为数据分析公司的埋点方式。
可以看出，如果想要节省开发人力选择一款开源的埋点 SDK，神策埋点几乎可以说是唯一的选择。
但这个唯一的选择也是相当不错的，神策埋点采用的是事件模型，SDK 支持的端非常全面，支持前端、后端、服务端埋点，还支持数据库数据导入，Thea 目前就职的公司就采用了神策埋点 SDK。
4. 埋点测试&验收&上线
埋点数据测试由测试人员完成，测试通过后由研发部署上线，上线之后业务方应对埋点数据进行验收。这里的重点工作是测试埋点，埋点验证需要完成以下任务：
- 校验触发时机下前端/服务端埋点数据是否正常报出
- 校验数据库里是否收到上报的埋点数据
- 对事件和属性的完整性及数据类型进⾏校验
埋点的测试需要覆盖主流机型，验收完成后，由测试⼈员发测试报告，研发人员部署上线。
5. 埋点应用（数据分析）
最后一个步骤，基于埋点数据做数据分析，需要有一个前端的分析工具支持，这里要展开的话会是庞大的篇幅，以后有机会我们再来讨论用户行为分析工具。
这是《数据埋点，一次讲个够》系列文章的第三篇，这一系列的文章会和大家系统地分享我对埋点体系建设的实践与思考，讨论问题：
- 如何让业务线的产品/运营更高效地提埋点需求？
- 如何更快的响应业务需求，输出 DRD？
- 如何设计更简洁、更灵活、拓展性更强的埋点模型？
- 如何协调好参与埋点工作的各方，快速产出高质量的埋点？
- 如何有效地管理成千上万个已线上、未上线、需要下线的埋点？
Thea，微信公众号：Thea的若干好奇；从事大数据产品工作六年，设计、管理埋点已有三年，在大厂做过商业化大数据产品，也在几十亿美金估值的创业公司参与过数据中台的建设。
经手过上万个埋点，经历过从 0 到 1 自建埋点体系，也使用过第三方的埋点服务。喜欢研究各种产品，不止限于数据产品相关的。相信优雅的工具有很大的能量，可以减少工作和生活的摩擦。
本文作者@Thea
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
