埋点是数据分析的基础，一套好的埋点体系，可以支撑后续的数据清洗、数据储存、数据产品、数据分析等，可以使整个数据应用事半功倍，极大提高数据使用效率。那么埋点具体应该怎么做，有什么注意事项呢？某知名大厂具有丰富埋点经验的数据产品经理来为我们逐一揭晓。
一
埋点是什么？
埋点是一种用户行为数据化的记录，基于业务或者产品需求，对用户在产品内产生行为的每一个事件对应的页面、位置、属性等植入相关代码，并通过采集工具上报统计，采集的数据可以用来分析网站/APP的使用情况，用户的使用习惯等等，延伸出用户画像、用户偏好、转化路径等一系列数据产品。
通常的记录维度为who、when、what、where、how，即用户通过某种方式，在何时何地做了何事。举个例子ID：1001，上午十点，在峡谷击杀了一个boss（bossID：abc）。
如上举例，数据分析师或者数据产品，通常需要对产品的用户行为（How：read）进行收集，设计出·对应的埋点体系，产出一份严谨、体系化，且能支撑后续数据分析需求的埋点文档，那么怎么设计出一份规范的埋点文档呢？
埋点文档如何设计？
首先，梳理出产品的功能结构及业务流程，将核心流程梳理出来，确定关键指标，并细化各流程的影响因素，同时想清楚上下游的接入口是什么，避免埋点的重复，提高埋点复用性。
其次，规划出数据分析的框架，基于产品功能的路径转化和重要指标链路，设计出可供记录的埋点框架，使埋点契合分析框架的逻辑，避免冗余。
同时，埋点是用来记录用户的行为，埋点文档需要提供给前、后端研发进行埋点开发，所以文档中的信息尽量描述清楚，并且与开发拉会议，要求对埋点的理解对齐一致。
文档信息具体包括:
从以上举例中可以看出，埋点文档除了公共字段（Who、When、What、Where）外，主要记录关于How的设计，主要包括：
1.埋点、埋点含义、触发场景
埋点文档中必须写出埋点上报时机，同时描述准确；
规定攻击怪物成功时上报，而不是战斗阶段；击杀的怪物记录的是当前血量而不是满血血量，因为考虑怪物可能是残血。
2.参数、参数名称、参数值类型
参数里记录的是针对埋点行为，所包含的信息，埋点行为不同，对应的信息也不同，所以不能作为公共字段记录在数据表中，会以json形式，记录在字段中，分析时需要使用具体的信息，可通过函数解析出来（get_json_object）。
json记录的数据，分为key和value，如：role_type（key）：1（value），所以上述举例的整体json如下，可以用：
3.备注信息
备注信息的意义就是解释说明，例如文档中只记录了物品和怪物的id，具体的名称没有记录，是因为日志中存储中文易出现乱码，仅记录id即可达到分析需求，并且减少数据量。
同时，埋点文档中，除了第一页sheet表中展示埋点文档外，其后需要附加写出含多个枚举值参数的编码表，方便数据人员进行分析对照，数据查询。
埋点文档设计完成后，即可提交至研发同学，讲解埋点文档。产品的大部分核心数据都是基于埋点完成，例如、转化分析、流失跳出分析、核心功能分析等。其重要性不言而喻，那么我们如何保证埋点的准确性呢？
如何做埋点验收？
埋点验收并不一定是要在开发完成，提交安装包之后才开始验收，在前期、中期、后期尽量使用一些策略来多方保障埋点质量。
1.埋点文档评审
埋点文档设计完成后，数据组内需要进行评审，对埋点和参数逐一检验，包含：
合理性：是否符合用户行为路径；完整性：是否覆盖产品的所有场景，可以支撑后续的数据应用；正确性：埋点文档中，除功能的特性埋点，还有一定的公共埋点、公共参数，查看是否与BI报表开发时的规范一致，如果不一致，BI报表不会产生数据。
2.埋点开发阶段
埋点开发阶段，与研发团队保持密切沟通，确保和研发的理解保持一致，使其了解每个点的意义以及后续的应用计划。针对重要埋点，重要的参数，研发需提供对应的源码，确保每个枚举值都录入代码中。
例如：用户关于货币获得，会有多重路径，如果研发将其中两种路径漏写，后续分析中，会造成数据结果的缺失。
3.埋点验收
阶段埋点完成，安装包提交之后，数据同学会配合QA同学，一起做埋点验收，需注意以下几个方面:
转化漏斗是否正常：例如广告链路中，从广告展现-曝光-点击-关闭，这条链路的pv是呈漏斗逐渐减少，如果不是，那么需要定位埋点问题。上报顺序是否正常：新手引导中，id顺序为1-2-3-4，可追踪单一用户id，按时间戳查看上报顺序是否符合规范埋点上报是否对应规范中的触发场景
实际业务中的埋点验收，是一个复杂繁琐的工作，每个项目对应不同的规范，建议建立一个《埋点验收清单list》，记录需要验收的部分，指派到责任人，逐一签名查验，防止错漏。
