数据分析

打开数据分析

登录控制台，点击左侧实时数据。页面依次包含请求概览、包体分布、版本健康度、设备维度和遥测事件明细。

1. 应用选择刚发布的应用，注意 Android、iOS 和 HarmonyOS 是不同应用。

2. 渠道选择本次发布渠道；看整体时选全部渠道。

3. 窗口先选最近 24 小时，确保包含发布时间。

4. 点击刷新，从请求概览往下查看。

下面截图来自 Pakta 实际控制台组件，使用演示数据，展示读数方法。

请求概览：更新进行到哪一步

趋势图把这些事件按时间绘成五条线。将鼠标移到图上查看对应时间点的数量；先看异常是不是从发布后开始，再下钻到具体版本。

同一台手机可能上报多条事件，所以这里的请求量不是新增用户数，也不是检查更新接口的全部访问量。下载成功与启动成功发生的时间也可能不同。

时间范围和曲线怎么看

• 窗口支持最近 24 小时、72 小时、7 天，以及自定义起止时间；自定义范围最多 8 天，开始必须早于结束。

• 桶粒度表示每个点汇总多少分钟的数据。选 5 分钟看短时异常，选 30 或 60 分钟看多天走势，也可以保持自动。

• 事件类型选择“下载失败”时，图表强调该曲线，事件明细只显示相应类型。概览计数和版本健康度仍保留全部类型，方便对照。

• 刷新重新读取当前条件下的数据。切换应用、渠道或时间后，重新确认筛选条件，避免把旧范围的观察结论套到新范围。

例如 14:00 发布后失败突然上升：先选包含 14:00 的两小时时间范围，将粒度设为 5 分钟，再看失败从哪个时间点开始。

包体分布：哪些版本还有人在用

滚动到包体分布，在热更包 / 原生包之间切换：

每行有请求量与占整体的比例，默认展示前 6 个包，超出的数量在列表末尾汇总。横条长度相对请求量最多的包展示，不要把横条长度直接当作全体用户覆盖率。

例如，原生版本 1.0.0 仍有大量记录，而新更新只发到了 2.0.0，那么 1.0.0 用户不会因这次发布获得修复。回到发布窗口核对目标，而不是继续增加 2.0.0 的比例。

版本健康度：是否继续扩大比例

找到本次更新 hash 和原生版本所在行，对照上一稳定版本的数量与比率。

分母为零时页面显示 0，不代表已经验证成功。样本太少时先增加测试和观察时间，不能凭“0%”直接全量。

1. 下载失败率升高：查明细中的网络、HTTP 或文件错误。

2. Patch 失败升高、最终下载成功：检查差分失败原因，同时确认完整包回退是否成功。

3. 回滚升高：停止扩大比例，核对新版本启动错误和健康确认逻辑。

4. 下载、启动成功持续出现且关键业务验证正常：按计划逐步增加比例。

设备维度：查一台手机

在设备维度中找到测试手机的设备标识。开发可通过 getUpdateMetadata().uuid 取得它。

1. 核对设备的 OS、五类事件次数、两项失败率、首次和最近上报时间。

2. 点击设备行，下方遥测事件明细只显示该设备记录；上方出现已选设备标签。

3. 按时间查看先下载、后启动确认，还是下载后回滚。

4. 再点该设备行或删除上方设备筛选标签，恢复全部设备。

每页显示 20 台设备，可用页码查看下一页。设备筛选联动事件明细，不会把整页概览改成单台设备数据。

遥测事件明细：找到失败原因

明细包含时间、类型、设备、系统、包版本、构建信息和详情。先按“事件类型”缩小范围，再核对更新 hash 和发生时间。

明细默认保留 7 天，实际以服务端保留配置为准。需要调查时及时记录时间、设备标识、原生版本与更新 hash。

完成一次发布验收

在测试手机确认新内容已经显示，再在数据页找到对应更新的下载和启动成功记录，最后检查关键业务页面。

确认正常后去控制台调整比例。发现问题时先停止发布或恢复稳定版本，保存事件证据再排查。

disableTelemetry: true 会关闭客户端相关事件上报。打开页面但没有数据时，先让开发确认此项未关闭，设备确实执行过 Release 更新流程并能连接服务端。