《数据埋点，⼀次讲个够》系列⽂章的第三篇，讨论埋点业务的流程规范，主要讨论： 1. 埋点业务过程中涉及的⾓⾊及其职责；
2. ⼀条完整的埋点 workflow 长什么样⼦？
⼀、⾓⾊与职责
⼀个完整的埋点业务流程会涉及业务⽅、埋点研发测试团队、数据团队： 业务⽅：产⽣埋点需求，通常是业务线的营运⼈员、产品经理、数据分析师，他们根据业务，提埋点需求，埋点完成之后做数据分析，他们主要的⼯作是输⼊原始需求、埋点上线后消费数据。 埋点研发测试团队：负责埋点开发、测试、上线。
数据团队：负责定义埋点模型，接收埋点数据上报，存储数据、处理数据、展⽰数据。
不难看出，⼀个具体的埋点业务参与的各⽅需要⼤量协同配合。企业应该有⼀个与埋点业务流相对应的组织架构，来保证埋点采集的质量和效率。根据多年的埋点⼯作经验，有三个⾓⾊对埋点⼯作的开展有 ⾮常关键的作⽤。
1. 需要设置⼀个⾓⾊来统⼀规划整体的埋点⼯作，负责组织协同各个业务线，制定埋点流程和规范，并推⼴规范的落地与执⾏，确保各
业务线的数据接⼊符合规范，保障数据质量，我所在的团队由数据产品经理来负责。
2. 对于公司具体业务线的埋点，需要有⼀个业务负责⼈，负责该业务线的埋点需求梳理、埋点设计、数据上线应⽤推⼴、⽇常使⽤⽀持
和培训，这个⾓⾊，⼀般由业务线的数分、有数据 sense 的产品、或者有业务 sense 的研发担任。
3. 关键的⾓⾊是具体业务线的埋点技术负责⼈，⼀般来说每条业务线会有多种客户端的产品，埋点的开发可能会涉及 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 也能发布帖⼦。这样就清楚了，这是合理的，埋点数据上报没有问题。」
业务⽅：「好吧，如果是这样的话，我希望能够区分通过不同⼊⼝发布帖⼦的⽤户数。」
数分：「额，你之前提需求的时候也没说，当前的埋点做不到，要区分的话，只有加埋点字段，要等下个版本才能上线，并且只有在新版本中才能区分。」
业务⽅：「好吧，也只能这样了。」
数分：「你看⼀下，新的埋点字段，没问题的话研发就这样开发了。」
我和qq的故事这是数据团队和业务团队之间时常出现的场景。究其原因是掌握更多业务知识的业务⽅没有向数分提
供完整的信息（当然数据分析也没有进⼀步询问，业务怎么说怎么做），数据分析设计的埋点没有覆盖完整的流程，导致埋点不可⽤。
为了避免这样的问题发⽣，在埋点需求提交阶段，要求业务⽅对业务流程给出详细的说明，包括业务功能要引导⽤户达成什么⽬标，业务完成的路径如何，最好能提供⽤户体验地图。
总之，要求业务⽅⾃⼰先能把业务路径梳理清楚，提供尽可能多的业务背景。
2）提交需求
我们要求业务⽅发正式的需求邮件，下⾯的截图是我们团队在⽤的模板。
模板要求的信息和业务⽅要做的业务梳理是⾼度相关的，业务⽅须严格按照线下邮件流程进⾏提交，在邮件中说明要埋点的产品、端的类型、所属业务、业务路径、统计指标、维度、期望上线⽇期等信息。
收到邮件后，数据团队在两个⼯作⽇内对接业务⽅沟通需求细节。
2. 需求评审
需求评审环节由数据团队主导，通常是负责该条业务线的数据分析师。⼜分为三步：⼀是设计埋点，⼆是组织埋点需求评审会议，三是埋点注册。
1）埋点设计
数分在收到埋点需求邮件之后，仔细阅读需求，业务⽅沟通需求细节，基于业务路径设计埋点，尽量做到对业务流程全⾯覆盖。
埋点设计的结果是输出埋点 DRD，关于如何设计埋点，在系列上⼀篇⽂章中已经有很多描述，请点击阅读。
2）埋点需求评审
数分组织埋点研发测试团队、业务⽅进⾏埋点需求评审，评审需要确认以下要点：
2014sci影响因子
1. 埋点研发测试团队确认需求可⾏性
2. 业务⽅确认埋点设计⽅案符合业务需求
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议