嵌入是数据分析的基础。好的嵌入系统可以支持后续的数据清洗、数据存储、数据产品、数据分析等。，可以让整个数据应用事半功倍，大大提高数据使用效率。那么应该怎么做才能把斑埋掉，需要注意些什么呢？一位知名工厂有丰富嵌入经验的数据产品经理来为我们一一揭秘。
一个
埋葬点是什么？
埋点是用户行为的一种数据记录。根据业务或产品需求，将相关代码嵌入页面、位置、属性等。对应产品中用户行为的每一个事件，并且收集到的数据可以通过收集工具上报统计。收集的数据可用于分析网站/应用的使用情况、用户的使用习惯等。，并且可以扩展用户画像、用户偏好、转化路径等一系列数据产品。
通常的记录维度是谁，什么时候，什么事情，在哪里，怎么做的，也就是用户以某种方式，什么时候，在哪里做了什么。比如游戏ID: 1001早上十点在峡谷打死了一个boss (boss ID: ABC)。
比如一个数据分析师或者数据产品，通常需要收集产品的用户行为(How:read)，设计相应的嵌入系统，制作出一个严谨系统的嵌入文档，能够支撑后续数据分析的需求。那么如何设计一个标准化的嵌入文档呢？如何设计埋藏式文档？
首先梳理产品的功能结构和业务流程，梳理核心流程，确定关键指标，细化每个流程的影响因素。同时搞清楚上下游接入口是什么，避免埋点重复，提高埋点复用性。
其次，规划数据分析的框架，基于产品功能和重要指标环节的路径转换，设计可记录的埋点框架，使埋点契合分析框架的逻辑，避免冗余。
同时，嵌入点是用来记录用户行为的，嵌入点文档需要提供给前端和后端RD进行嵌入点开发，所以文档中的信息要尽量描述清楚，要和开发会议要求的对嵌入点的理解对齐。
信息具体包括:
从上面的例子可以看出，除了公共字段(谁、什么时候、什么、哪里)，埋藏式文档主要记录的是How的设计，主要包括:1.埋藏点，埋藏点的含义和触发场景
埋点报告时间必须写在埋点文件中，描述准确；
规定攻击怪物要在成功时报告，不能在战斗阶段报告；
被杀死的怪物记录的是当前血量而不是满血量，因为考虑到怪物可能是残血。
2.参数、参数名和参数值类型
该参数记录了掩埋点的行为。参数包含的信息不同，对应的信息也不同。所以不能作为公共字段记录在数据表中，而是会以json的形式记录在字段中。分析需要用到具体的信息，可以用一个函数(get_json_object)来解析。
json记录的数据分为key和值，比如:role _ type (key): 1 (value)，所以上面例子的整体json如下，可以如下使用:
3。评论备注的意思是解释。比如文档中只记录了物品和怪物的id，而没有记录具体的名称，因为日志中存储的汉字容易出现乱码。只记录id就可以满足分析要求，减少数据量。同时，在嵌入式文档中，除了首页表中显示的嵌入式文档外，还需要额外写出一个包含多个枚举参数的编码表，方便数据人员分析比较和查询数据。
嵌入式文档的设计完成后，可以提交给RD的学生讲解嵌入式文档。产品的大部分核心数据都是基于嵌入点的，比如用户行为分析、转化分析、流失分析、核心功能分析等。其重要性不言而喻，那么如何才能保证埋葬点的准确性呢？
埋点验收怎么做？
埋设点的验收不必在开发完成并提交安装包后开始。尝试在前期、中期、后期使用一些策略，从多方面保证埋点质量。
1.审查埋藏的文件
埋点文件设计完成后，需要对数据组进行审核，逐个检查埋点和参数，包括:
合理性:是否符合用户行为路径；
完整性:是否覆盖产品的所有场景，能否支持后续的数据应用；
正确性:在嵌入文档中，除了函数的特征嵌入点之外，还有一些共同的嵌入点和共同的参数。检查是否符合BI报表开发的规范。否则，BI报告将不会生成数据。
2.埋藏点发育阶段
在嵌入式点开发阶段，与RD团队保持密切沟通，确保与RD的理解保持一致，使其理解每个点的意义以及后续的应用方案。对于重要埋点和重要参数，RD需要提供相应的源代码，确保每个枚举值都输入到代码中。
例如，用户有多种获取金钱的途径。如果RD省略了两条路径，数据结果将在后续分析中丢失。
3.埋点验收
在埋设阶段完成并提交安装包后，数据校友会将配合QA同学一起做埋设验收。应注意以下几个方面:
转化漏斗是否正常:比如在广告链接中，从广告展示-曝光-点击-关闭，这个链接的pv是一个漏斗逐渐下降，如果不是，那么就要定位埋点。
举报顺序是否正常:新手指导中，id顺序为1-2-3-4，可以追踪单个用户id。根据时间戳检查报告顺序是否符合规范。
隐藏报告是否对应规范中的触发场景。
在实际业务中，接受掩埋地点是一项复杂而乏味的任务。每个项目对应不同的规格。建议建立埋地验收清单，记录需要验收的部位，分配到责任人，并逐一签字检查，防止错漏。
