埋点是数据分析的基础，一套好的埋点体系，可以支撑后续的数据清洗、数据储存、数据产品、数据分析等，可以使整个数据应用事半功倍，极大提高数据使用效率。那么埋点具体应该怎么做，有什么注意事项呢？某知名大厂具有丰富埋点经验的数据产品经理来为我们逐一揭晓。
一
埋点是什么？
埋点是一种用户行为数据化的记录，基于业务或者产品需求，对用户在产品内产生行为的每一个事件对应的页面、位置、属性等植入相关代码，并通过采集工具上报统计，采集的数据可以用来分析网站/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》，记录需要验收的部分，指派到责任人，逐一签名查验，防止错漏。
微信扫一扫 