1. 埋点设计
1.1. 埋点需求基本要素
- 上报时间
- 涉及页面
- 用户信息
- 系统信息
- 触发条件（session 回溯）
- 上报位置
1.2. 埋点事件设计原则
- 驼峰命名法；
- 命名格式：模块_页面_事件；
- 区分公共事件，
- 如设备、位置、机型等，不要每次都上报，这样可以大大减少数据冗余；
- 相同的功能事件设置相同的 event_id，通过属性参数来做区分；
1.3. 埋点设计步骤
- 需求梳理
- 在设计属性和事件的时候，我们要知道哪些经常变，哪些不变，哪些是业务行为，哪些是基本属性；
- 基于基本属性事件，我们认为属性是必须采集项，只是属性里面的事件属性、根据业务不同有所调整而已。
- 业务分解
- 梳理确认业务流程、操作路径和不同细分场景、定义用户行为路径
- 分析指标
- 对特定的事件进行定义、核心业务指标需要的数据
- 事件设计
- APP启动，退出、页面浏览、事件曝光点击
- 属性设计
- 用户属性、事件属性、对象属性、环境属性
-
1.4. 埋点日志基本字段
- 用户 ID
- 事件名称
- 事件 ID
- 所在页面（位置）
- 属性
- 属性值
- 时间
- 设备上报时间
- 到达服务器的时间
1.5. 多维事件模型
- event 事件模型
- 使用 event 记录用户在产品上的各种行为；
- What
- When
- Where
- Who
- How
- user 用户模型
- user 的基础属性信息
- 二者既可以分别分析，也可以关联分析。
1.6. 埋点的总体要求
- 数据稳定准确，反映真实业务场景
- 需要长期监控，数据需要长期存储
- 业务属性丰富，可以做深度业务分析
- 对于核心 KPI，指标需要全面覆盖
- 需要设置数据权限
2. 埋点采集的顶层设计
2.1. 用户识别
- 用户识别机制的混乱会导致两个结果：
- 一是数据不准确，比如UV数据对不上；
- 二是涉及到漏斗分析环节出现异常。
- 因此应该做到：
- a.严格规范ID的本身识别机制；
- b.跨平台用户识别
2.2. 同类抽象
- 同类抽象包括事件抽象和属性抽象：
- 事件抽象即浏览事件，点击事件的聚合；
- 属性抽象，即多数复用的场景来进行合并，增加来源区分。
2.3. 采集一致
- 采集一致包括两点：
- 一是跨平台页面命名一致，
- 二是按钮命名一致
- 埋点的制定过程本身就是规范底层数据的过程，所以一致性是特别重要，只有这样才能真正的用起来
2.4. 渠道配置
- 渠道主要指的是推广渠道，落地页，网页推广页面，APP推广页面等，这个落地页的配置要有统一规范和标准。
2.5. 系统化管理埋点事件
- 实现统一的格式；
- 方便埋点查询、变更管理；
- 易于埋点元数据管理；
- 方便埋点生命周期管理；
- 便于进行埋点数据质量的监控。
3. 埋点需求梳理
3.1. 埋点事件表
-
事件表示例：
- 埋点位置
- 如果业务覆盖了APP、Web和小程序平台，分开管理会造成指标冗余；
- 对于多平台存在的核心指标，采用的是统一事件名定义；
- 不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；
- 事件定义：
- 比较难处理的是【触发条件】的准确定义和描述，如页面的进度数据，触发定义成加载和加载成功完全不同；
- 比如，首页模块浏览，模块长短不一，到何种深度会触发对应模块的浏览，需要定义时想清楚，与开发沟通实现细节，避免后期踩坑；
- 参数定义：
- 用来定义事件的参数，也可以理解为事件维度；
- 该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度；
- 平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，这样做的好处是：减少指标冗余、指标管理工作、培训成本，以及使用者的学习成本。
- 当然这里也并不完全执着于抽象公用性，对于数据PM和开发来说，指标越精简越好，便于理解和管理，但对于运营同事来说，学习和使用成本高企，数据产生了但无法最大化应用侧价值，那就得不偿失，所以需要平衡。
3.2. 事件上报时机
- 事件埋点
- 比如：下单成功；
- 页面埋点
- 比如：完成页面跳转
- 曝光埋点
- 进入页面时，模块可见面积大于 50%，才上报；
- 手指不停的滑动，模块可见面积小于 50% 不上报，大于 50% 才上报；
- 滑动停止时，模块可见面积小于 50% 不上报，大于 50% 才上报；
3.3. 事件标识 & 参数命名规则
- 事件的命名规则：
- 同一类功能在不同页面或位置出现时，按照功能名称命名，页面和位置在ev参数中进行区分。
- 仅是按钮点击时，按照按钮名称命名。
- 事件格式：
- 事件分为事件标识和事件参数
- 事件标识
- 作为埋点的唯一标识，用来区分埋点的位置和属性，不可变，不可修改。
- 事件参数
- 埋点需要回传的参数，ev参数顺序可变，可修改
- 事件标识和事件参数之间用“#”连接(一级连接符)
- 事件参数和事件参数之间用“/”来连接(二级连接符)
- 参数使用 key=value 的结构，当一个 key 对应多个 value 值时，value1 与 value2 之间用“，”连接(三级连接符)
- 当埋点仅有事件标识、没有事件参数的时候，不需要带#
- 备注：
- app埋点调整的时，事件标识不变，只修改后面的埋点参数(参数取值变化或者增加参数类型)
3.4. 通用埋点设计
- 在自定义埋点设计中，有一些通用的事件往往是比较复杂的，而且随着业务发展，会变得越来越复杂。
- 比如：APP 平台的分享事件，如果按功能模块，每个功能模块都设计了自己的分享事件，则这个事件会越来越分散，如果想聚合做复合指标（如：通过分享/日活来衡量内容质量），分享事件要先聚合平台各功能模块的分享事件，太分散会产生应用上的问题。
-
此时，建议仍然是将通用类型的埋点统一进行管理，通过变量字段进行拓展，来满足多功能模块的埋点需求，可以通过多个参数来进行区分。
-
通用埋点事件需求示例
3.5. 数据指标地图
- 数据能力推广的第一个难点，是让让大家知道平台上有哪些数据。
- 在各平台埋设的指标，采用excel的方式进行管理的问题是指标一多起来，找起来不太方便，对于定义者来说自然很容易找到，但是对于使用者来说则不太友好。
- 即使搜中文名称，也会存在同一个地方，大家用不同的关键词去搜索，比如：模块、版块、板块。
- 数据指标地图，将不同功能模块的数据指标进行了拆解和说明，其他同事找数据指标之前，先打开指标地图大概定位，然后再去对应的sheet表中寻找对应指标的细节定义和可下钻的维度信息。
3.6. 指标字典
- 从数仓里自助取数时，会有以下的问题：
- 有哪些表；
- 表格对应的是哪块业务的数据；
- 有哪些字段；
- 字段的含义是什么；
- 等等
- 这个需要明确具体内容，需要确认、并且约定好，在新增时及时更新对文档的解释。
3.7. 版本迭代
- 随着版本迭代有新功能的埋点，或者针对之前功能的优化，所以需要对之前埋点进行调整。从埋点管理的角度，新增/修改的埋点，需要整合到之前的埋点系统里，这样能够方便使用者查阅整体的埋点明细。
- 关于版本迭代中的埋点管理，相比于excel也有更好的工具化管理办法，如：做一个web端埋点管理平台，可以看到所有的埋点。同时，功能 PM 可以在该平台上按照字段要求提交自己的埋点需求，然后走审批流程，能够进入开发的埋点，会打上版本标记，待上线后，对应的埋点会出现在平台总表里，供使用者查看。
-
3.8. 埋点状态监控
-
主要负责对埋点的存活状态、未知埋点发现及数据异常进行提醒。
- 埋点的存活
- 主要是针对已经确定的埋点进行监控，而是否存活主要是通过测试人员进行回归测试来判断。
- 未知埋点发现
- 主要是通过上报数据进行分析，如果出现了未知的埋点标识数据，则进行提醒，方便反向跟踪问题。
- 数据异常提醒
- 主要从数据本身的阈值异常以及上下游埋点比例的阈值进行监控。
