《Data Embedding，一言为定》系列文章第三篇，讨论埋葬业务的流程规范，主要讨论：
跟踪业务流程中涉及的角色和职责；完整的跟踪工作流程是什么样的？ 一、角色和职责
一个完整的嵌入式业务流程将涉及业务方、嵌入式研发测试团队和数据团队：
不难看出，一个具体的埋地业务涉及的各方都需要大量的协调配合。企业应有与跟踪点业务流程相对应的组织架构，保证跟踪点采集的质量和效率。根据多年的跟踪工作经验，在跟踪工作的发展中，有三个角色扮演着非常关键的角色。
要设置一个角色，统一规划整体跟踪工作，负责组织协调各业务条线，制定跟踪程序和规范，推动规范的落实和落实，保障数据访问对于每个业务线，为了遵守规范，保证数据质量，我所在的团队负责数据产品经理。对于公司具体业务线的埋点，需要有业务负责人，负责梳理业务线的埋点需求、埋点设计、数据上线应用推广、日常使用支持和培训这个角色一般是由业务线的数量决定的。它负责产品的研发，具有数据感或商业感的产品。关键角色是具体业务线的技术负责人。一般来说，每个业务线都会有各种各样的客户产品。嵌入点的开发可能涉及Android、iOS、微信小程序、服务器。需要有一个技术接口人来协调埋点的开发工作，这个角色可以由前端开发负责人担任。 二、购买业务流程
以上流程图贯穿了埋点的全过程，将各个角色串联起来，保证埋点采集的高质量和高效率。主要链接如下：
理想情况下，埋点通过以上五个步骤上线。
在实践中，很多团队在处理跟踪业务时没有形成内部流程规范，导致跟踪数据质量差，难以实现数据价值。
例如：当你想统计某个行为触发的人数时，发现没有埋点。在提取数据的时候，score发现有很多相似的字段。我不知道该用哪一个。 R&D说已经启动了某个埋点。但是，在数据库中找不到任何数据。某埋点刚开始在线时，是正常的数据埋点需求怎么写，但是过了一段时间就没有数据上报了。
要解决这些问题，需要把埋点作为一项独立的研发任务，而不是在产品开发过程中顺便完成的任务。
需要强调的是，流程的制定很简单，画图发文，但如果流程规范只是形式，并不能真正落入实际环节。 ，所有的努力都是徒劳的。
因此，我们还需要对流程规范中各个环节的输入输出做出更详细的要求。
1.埋地需求提交
1）提交需求不容易
埋点需求通常是业务方的操作人员、产品经理、数据分析师，根据业务数据分析的需要，提出埋点需求。提高需求并不是一件显而易见的事情，也是需要学习的。
Thea之前的团队只要求业务方在提交跟踪点需求的过程中，明确描述在哪些维度看哪些指标。
这样的流程对提出需求的业务人员非常友好。他们不需要解释为什么要看这个指标，分析指标在这些维度下对业务的价值，甚至在很多情况下业务人都不知道业务路径的全貌。他们只关注路径上某个环节上的指标，提出的要求都是“部分的”、“临时的”、“一次性的”。
根据这样的要求设计的埋点也是“局部的”、“临时的”和“一次性的”。随着后续业务路径的调整，即使是很小的微调也会埋点不可用，需要重新设计。
比较抽象，举个具体的例子，一个用户在社区发帖。
目前社区内有两个条目供用户发帖，条目A和条目B。点击发送帖子后，会进入编辑帖子的内容页面，编辑完内容页面后，点击发布即可发布帖子.
业务方想分析发帖的漏斗，但由于业务方只知道入口A的存在，不知道入口B的存在，所以建议的漏斗是：点击入口的用户数A> 进入编辑页面的用户数 > 点击发布并成功发布帖子的用户数。
基于这个分数，设计了“进入编辑帖子页面”和“发布帖子”两个事件（因为分数认为编辑帖子页面只有一个条目A，基本上是点击的人数entry A = 访问帖子编辑页面的人数）。
追踪点上线一天后，业务方说追踪点数据有问题，来到评分处查看数据，出现如下对话。
…
…
这是数据团队和业务团队之间的常见场景。原因是业务知识比较多的业务方没有提供完整的信息给分数（当然数据分析没有进一步问，业务说什么，怎么做），数据分析的埋点设计没有涵盖完整的流程数据埋点需求怎么写，导致数据被埋没。点不可用。
为了避免此类问题，要求业务方在埋点需求提交阶段，对业务流程进行详细描述，包括业务功能要引导用户实现什么目标，路径是什么为业务完成，并且最好提供一张用户体验图。
总之，业务方需要梳理业务路径，提供尽可能多的业务背景。
2）提交要求
我们要求业务方发送正式的请求电子邮件。下面的截图是我们团队正在使用的模板。
模板需要的信息和业务方 要做的业务排序是高度相关的。业务方必须严格按照线下邮件流程提交，并在邮件中说明待埋产品、终端类型、所属业务、业务路径、统计指标、维度、预期投放日期。和其他信息。
数据团队收到邮件后，会在两个工作日内联系业务方沟通需求详情。
2.需求审核
需求审查会议由数据团队领导，通常是负责业务线的数据分析师。分为三个步骤：一是设计跟踪点，二是组织跟踪点需求评审会，三是跟踪点注册。
1）埋点设计
在收到嵌入点需求的邮件后，Score points仔细阅读需求，与业务方沟通需求细节，并根据业务路径设计嵌入点，尽可能充分涵盖业务流程。
埋点设计的结果就是输出埋点DRD。该系列上一篇文章中关于如何设计埋点有很多描述，请点击阅读。
2）跟踪需求审核
几个点组织研发测试团队和业务方对跟踪需求进行审核，审核需要确认以下几点：
嵌入式点的研发测试团队确认需求的可行性。业务方确认嵌入点设计方案满足业务需求。
如果一次审核没有达成一致，需求将被多次审核，直到三个团队达成一致。需求审核完成后，将严格按照文档进行后续开发和嵌入。如有需求调整，需按积分变更，积分会通知相关方。
3）注册嵌入
Embedding Registration需要做的就是将DRD中的信息录入到线上系统，这样做的目的和埋点管理相关，跟踪点的整个生命周期：新增、次数、迭代，线下管理全部在线管理，可以保证跟踪点在使用过程中不会变得混乱。
