目录
介绍:
埋点文档
介绍:
埋点是流量数据采集的一种主要方式, 是分析用户行为的重要手段。本质上可以理解为，一次html动作触发了网络请求, 并被服务端的框架存储下来的行为。
按照埋点实现方案分为
按照HTML行为触发网络请求的方式可以划分为
点击事件：用户每点击页面按钮一次就记录一次数据。
曝光事件：当用户成功进入一个页面时记录一次数据，当刷新一次页面也会记录一次数据，如果通过手机HOME键切换出去，则不会记录。
页面停留时长：页面停留时长主要用来记录用户在一个页面的停留时长，他可以通过记录用户进入页面的世界和离开页面的世界计算，计算公式：用户停留时间=离开页面时间-进入页面时间。
埋点的目的：
①产品优化， 结合A/B实验，验证产品功能或者banner的优化是否合理（如提升转化）
②业务分析， 分析不同业务场景的受众情况，如滴滴司机部落的参与度相比其他工具的优劣
③用户画像分析： 通过用户行为的分析， 累计用户画像，分析高潜用户等
埋点文档
一般要包括，埋点名称，采集的类别，用户行为类别，采集时间，采集指标，以及各种id等技术必须字段。 如下：
一般情况下，如果后端能直接获取数据， 不建议再去埋点
具体的案例指导：
①：判断数据是前端埋点还是服务端埋点
一般在大公司，这两种采集方式不同，分别有不同的采集框架
②判断埋点新增的必要性
检查埋点是否已经存在
检查满足该需求是否有类似节点的埋点
检查原埋点逻辑是否已经过时， 需要更新
以及跨app，跨端的埋点统一问题
③设计埋点需求
命名规范：（参考hive表命名规范）
使用由字母、数字、下划线组成，并保证在应用内唯一
行为埋点规范：遵循层级、划分主次 ， 每个页面 or 组件 都有主结构的埋点 ， 功能基于页面 or 主结构延展处理
T1 nav_business_sw (导航栏结构第一层级，结构信息延展到相关数据信息.新：统一使用小写）
{业务|角色}_{组件|页面}_{动作} or {时机}
T2 nav_business_change_ck (结构第二层级，延展到相关 事件或者项目 信息上. 新：统一使用小写）
{业务|角色}_{组件|页面}_{具体元素}_{动作} or {时机}
以下是埋点的一个需求demo
前端埋点需求
后端日志需求
埋点交付验证
- 数据质量方案 — 合格验收从三个方面去衡量 ： 参数覆盖度 、枚举值完善度
- 业务质量方案 — 暂无
- 分析质量方案 — 关联性检验或倒序关联检验
1 参数覆盖率，如核心参数，Pid,乘客id,Tel手机号，设备号
2 枚举值覆盖率， 业务线id,枚举值是否缺失等
3 关联性检验， 如前端埋点和后端埋点的差异，埋点数据和离线数据的量级差异
埋点管理
埋点废弃
规则：若埋点近30天PV为0 或 超过60天未被使用（“使用”的定义见概念说明），则会被废弃。废弃之后将会在当日被踢出白名单，次日埋点数据不再入库。
执行方式：当埋点近20天PV为0 或 超过50天未被使用时，会每两天发送一次预警通知给埋点负责人(业务负责人，需求负责人，开发负责人)，用户可以在邮件中选择是否续签，若点击“续签”之后，埋点将重新计算未使用时间。
