这是一篇存货，作于两年前，当时入职一家没有自动化埋点方案、没有全埋点APK的公司，历史埋点流程混乱，数据采集质量不理想，于是从流程和规范上，做了一遍梳理明确。
01、埋点工作的基本流程图
埋点本身也是产品需求的一部分，梳理明确工作流程，是产品工作的首要任务：
02 流程说明
一、接收业务需求：
该阶段收集业务方（产品、运营）对于该版本的统计需求，以一款体育视频APK应用为例，他们会给出如下文档：
这个阶段，我们要整理这些需求，并依赖自己对产品逻辑的理解，初步判断每一个需求需要采集的基础数据，对需求不明确的地方，要与业务方确认，最完美的方式，是与业务方确认清楚每一个需求指代的用户交互场景；比如该需求中的需求1，实际的用户使用场景是：用户在赛事页或者热点页对某个推荐位的点击。需求方想看的数据就是这个场景发生的次数和触发这个场景的人数；那么我们就应该去捕捉这两个页面每个推荐位的点击操作，针对该交互进行埋点，采集点击所在的页面、点击的推荐位、点击的推荐位指代的内容信息；
二、转化数据需求：
1.该阶段是基于上一个阶段，确认每一条业务需求的对应场景后，作为数据产品，要初步定义每个需求最终的实现形式，也就是最终报表或者数据输出的样式，实际可以自己画一下类似这样的表格：
2.自己check或者与业务方确认，该报表是否能满足最初的需求；
3.根据最终数据输出的样式，进一步确认每一个需求需要采集的数据；
三、抽象实现方式：
1.这个阶段，针对每一个需求，可以草拟一些要采集的字段，然后想象实现这些需求，基于这些字段信息的sql怎么写，明确实现思路，为后期的报表实现提前整理思路，以便少给数据开发同学埋坑；比如针对消息推送功能，即使没有看到prd，我们能够想象，我们需要一个字段来定义该交互，可能是event_key = ‘popup_notice’，不同的消息后端应该会给前端传消息id，字段可能是message_id，值取决于具体的接口传值；deviceid是基础字段，不用我们说也会有，那么想象到要统计每个消息被用户看到的人数，实现的代码应该是：
四、输出埋点需求：
1.这个阶段开始撰写埋点文档，需要参考四类信息：
a.产品输出的PRD，确定每一个页面的产品交互逻辑；
b.UI图，与PRD的作用相同，但逻辑和交互形态比PRD更接近最终版；
c.每个页面的相关接口文档，帮助我们快速判断哪些数据可以通过接口采集，哪些数据要通过前端判断或者计算采集；从原则上来说，一般尽量直接从接口拿，不要让前端做过多的判断和计算，那些没事喜欢让前端做计算的数据产品经理，最后都转岗了。如果不得不让前端计算，尽量把锅往产品经理和业务方身上甩，数据产品要站开发一边，理解技术原理和开发流程，才是生存和成长之道；
d.PRD和UI图有出入？接口文档看不懂？如果对需求不确定的地方，要及时跟负责该页面的开发沟通，大概描述一下需求，让前端帮忙判断是否可做。
2.这个阶段按照规定格式撰写埋点文档0.5版本，具体格式可参见：
3.撰写埋点文档的时候，除了要满足业务方提出的需求，要尽量考虑到自己作为一个数据分析师时，可能的分析内容和维度，以确定更多的采集内容；
4.埋点的基本原则是：全交互埋点，重点交互做事件属性采集；
五、埋点需求评审：
1.沟通项目拉会：
a.向前端简单阐述本次埋点需求的内容：涉及哪些页面，新增埋点多少个，更新埋点多少个，自己在设计时考虑到的一些要注意的问题；
b.因为每个版本埋点动辄几十上百个，没有必要在会议上一条一条过，而且开发当时也做不出靠谱的判断，直接将文档通过邮件发送给相关开发即可；
c.约定评审结束时间，在这个时间点之前，开发对埋点进行评审，并反馈到数据产品，双方针对需求进行讨论修改；
2.这个阶段我们可能碰到如下问题：
a.要的数据接口没有：与后端产品沟通，先确认该数据在服务端是否有存，再确认是否能在接口新增字段把数据给到前端；
b.要的数据只能够计算，且很困难：此时自己对对应的数据需求的紧急和重要程度心理要有数，在此基础上理解前端实现的困难点，并尝试给出解决方案。如果确实没有靠谱的解决方案，review是否有其他的数据和报表呈现能够解决业务方想要解决的问题，并调整采集策略。若再无解，回过头与业务方沟通修改需求或者砍需求；
3.反复沟通，确认每个埋点的大体可实现框架；
六、完成需求评审：
根据评审结论，输出埋点文档0.8版本（开发就按着这个版本去实现）。
七、修正需求和文档：
1.埋点进入开发阶段，虽然经过了第一轮的评审，但在实际的开发过程中，还是会遇到各种各样的问题，导致埋点无法按照需求实现；
2.我们在埋点需求评审阶段遇到的问题，会小范围的在此时还是遇到，处理方式相同。但因为需求已经经过了一轮评审，在这个阶段，除非埋点已经实际影响到性能和项目进度，否则原则上不对需求进行妥协；
3.中间基本每天都有可能与开发就某个需求调整做出讨论，每天要整理修改过的需求，同步通过写作工具通知项目组，如果只是个别需求的定义明确，不需要发邮件周知，只要相关开发知晓即可；如果涉及到需求变更，需要邮件周知项目组，告之需求变更的原因和内容；
a.所谓“对个别需求的定义明确”：是指文档上自己写得不明确，导致开发不理解，但实际实现上没有难度的需求。该类修改只是对原有需求进行明确说明，不涉及需求变更；
b.所谓“需求变更”：包括了新增埋点、新增字段、删除字段、变更字段等等对原先需求有变动的修改；
最后，埋点工作，这里本质上只是提供了一种方法和思路，工具不同、公司不同、项目不同，大家采用的方法都会多少有些差异。
