背景#
组内负责的产品页面主要的流量途径来自集团各 App 端内，其中业务重点关注的一个指标是到达率
到达率计算：资源位点击到页面展现 / 资源位点击
- 资源位点击为 Native 侧埋点，BI 会根据物料名称判断对应业务
- 页面展现为 Web H5 侧埋点，一般设置在
mounted声明周期内
最近一直收到到达率降低的问题反馈，在投入不少人力成本进行一些 case 分析后发现原因主要在以下几个方面：
- 人群意向 / 疲劳度问题
- BI 统计问题，分子 / 分母计算有误
- 页面访问慢
为了后续遇到类似问题时能有现成的统计数据直观地查看用户折损点，更有效地进行问题分析与定位，需要对现有用户链路做分析，进行了一番调研，特此记录一下。
调研#
现有用户链路的查看途径是在内部监控统计平台的个人诊断链路上：
- 首先选择不同的端，对应会去查不同的埋点上报数据表（Native 和 H5 区分）
- 其次输入用户 ID + 时间，可以选择对应的页面以及过滤事件精简查询结果
- 最终依据上报时间把该用户对应时间内所有相关的操作埋点直接展示出来
可以看到个人诊断链路的核心逻辑是 基于单个用户标识去检索以时间为序的全量操作埋点
而行为路径的统计展示需要 基于固定的操作埋点去计算以逻辑约定为序的阶段漏斗数据，即需要有 存在明确顺序 并且 具有合理统计维度 的关键埋点，因此个人诊断链路工具不能满足统计的需要。
从 用户点击资源位 到 页面展现 结束，对应的技术行为路径为：端内打开 webview 加载 H5 至展现。
基于这个行为路径咨询对应埋点 SDK 同学后有以下结论：
- Native SDK 与 H5 SDK 链路 加载无明确顺序（类比组件生命周期与页面生命周期），只能基于一端数据进行监测
- Native SDK
- 标准埋点有 打开 H5 页面 - 开始加载 H5 页面 - H5 页面加载完成，但目前暂不支持（依赖后续发版）
- 已有埋点有 进入某页面 - 某页面退出，触发时机较宽泛（包含 打开 / 关闭 App、App 内切换页面、前后台切换等），无合理的统计维度
- 关键埋点如 左上角点击返回：端上无直接埋点；SDK 的自动采集上报统一埋点：需要以 控件类型名称 + 控制器名称 + 触发方法名 作为条件筛选，查询成本偏高且不稳定，并且也无合理的统计维度
- 总结：Native 现有链路无可行监测点
- H5 SDK
- 标准埋点有 H5 页面初始化 - H5 页面曝光（onLoad 后），具体业务相关信息有 访问页面完整链接 和 页面路由，可以依据 inrouter 和渠道号等信息进行模糊匹配
- 借助现有漏斗分析功能可以简单计算到达率
- 总结：H5 现有链路存在监测点，但效果有限
结论#
短期方案：H5 初始化 - 曝光 漏斗转化率技术侧可监测，做辅助观察
长期方案：Native 发版后进行 Native 侧链路监测，同时推动端加上点击返回埋点监测跳失率等更具业务意义的指标