> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# 数据分析

更新已经发布，接下来要知道：多少设备下载了、多少已经生效、哪些原生包还在旧版本上，以及失败集中在哪里。Pushy 把这些信息放在同一应用的**概览、版本漏斗、流量画像、失败诊断**四个视图中，让放量和排查都有数据依据。

在[控制台](https://pushy-admin.reactnative.cn/#/realtime-metrics)进入「数据分析」，选择应用。也可以在应用页面切换到「数据分析」标签。上方支持近 **7 / 14 / 35 天**，应用、视图和天数会保存在页面 URL 中，方便团队分享同一分析范围。

> 本页为本地真实控制台截图。「拾光商城」及其版本、流量和设备数据均为模拟数据，用于展示功能，不代表客户案例或效果承诺。点击截图可查看原图。

## 概览：先看规模，再看请求结果

[![拾光商城分析概览：今日请求、活跃设备和按请求结果堆叠的每日趋势](/images/analytics/overview.webp)](/images/analytics/overview.webp)
今日请求量、今日活跃设备、窗口内请求总量和峰值活跃设备，帮助你判断应用最近的更新活跃程度。每日趋势可以在**请求结果**与**活跃设备**之间切换。

往下还能看到请求结果构成与版本速览：

- **已是最新**：客户端已经在运行绑定的最新热更。
- **hdiff / pdiff 增量与整包**：看清实际下发方式和各自占比。
- **暂停、过期、blocked、未登记原生包**：区分正常发布状态和需要检查的配置问题。
- **版本速览**：并列查看各版本的下发、激活、累计激活率、覆盖参照与健康标签，再进入完整版本漏斗。

这里的活跃设备按发起更新检查的设备 uuid 去重，属于更新服务的设备活跃指标。请求次数与去重设备数含义不同，不能将请求量当作用户数。

## 版本漏斗：从下发追到实际生效

[![展开 3.6.2 的版本漏斗，查看原生包明细、累计激活设备以及下载和激活时延](/images/analytics/versions.webp)](/images/analytics/versions.webp)
每个热更版本独立展示**下发 → 下载成功 → 激活 → 回滚**的数据，并列显示失败次数、累计激活率和回滚率。可筛选热更版本或原生包；展开一行，就能继续查看：

- **原生包明细**：比较同一个热更在不同原生包上的下发、下载、激活、失败与回滚。
- **累计激活与下载设备**：用去重设备口径了解这个版本的累计生效情况。
- **发布时间到下载 / 激活的时延**：按 1 小时内、1–6 小时、6–24 小时、1–3 天、3–7 天和 7 天以上分组，看到更新到达及生效的节奏。
- **健康标签**：启动样本达到 10 次后，回滚率达到 1% 标为「关注」，达到 5% 标为「异常」。标签为排查提供线索，仍需结合样本量判断。

例如，模拟版本 3.6.1 的回滚率高于 3.6.2，就可以先筛选 3.6.1，检查是否集中在某个原生包，再转到失败诊断分析原因。

### 正确理解几个比率

| 指标    | 计算口径                    | 如何解读                                        |
| ----- | ----------------------- | ------------------------------------------- |
| 累计激活率 | 累计激活设备 ÷ 累计下载设备         | 两者均为该版本跨日去重的累计值，不随上方天数变化                    |
| 覆盖率   | 累计激活该版本的设备 ÷ 今日活跃设备     | 是累计设备与今日活跃规模的对比，不是「今日设备中有多少运行此版本」，可能超过 100% |
| 下载成功率 | 下载成功事件 ÷（下载成功 + 下载失败事件） | 按所选窗口的事件次数计算                                |
| 回滚率   | 回滚事件 ÷（激活成功 + 回滚事件）     | 看启动结果中回滚的比例，结合样本量判断                         |

窗口内的下载与激活事件可能不属于同一批设备，不宜直接相除作为转化率。累计激活率使用一致的累计去重口径。

## 流量画像：从访问节奏到网络与地区

[![请求域名、IPv4 与 IPv6 占比，以及按省份和国家汇总的请求分布](/images/analytics/traffic.webp)](/images/analytics/traffic.webp)
流量画像保留实时版本曲线，并增加多个互补维度：

| 维度     | 可以回答的问题                              |
| ------ | ------------------------------------ |
| 实时版本曲线 | 哪些热更包和原生包正在发起请求？可选择时间范围并查看曲线与 Top 分类 |
| 小时分布   | 所选天数内，一天的哪些时段更新检查最密集？                |
| 原生包    | 哪些安装版本仍有流量，各占多少，单日峰值设备数是多少？          |
| 运营商    | 请求来自哪些网络类别？中国大陆以外统一归为「其他地区」          |
| 请求域名   | 客户端通过哪些 Host 访问服务？                   |
| IP 版本  | IPv4 与 IPv6 的请求各占多少？                 |
| 地区分布   | 请求来自哪些省份或国家，各自的数量与占比是多少？             |

[![小时分布与原生包、运营商构成](/images/analytics/traffic-hours.webp)](/images/analytics/traffic-hours.webp)
地区面板单独支持**今日 / 近 7 天 / 近 30 天**。中国大陆按省级展示，其他地区按国家级展示；它统计的是完成的更新检查请求，不是设备定位。地区名称会随界面语言展示。

原生包设备数采用所选窗口内的**单日峰值**，因为每日去重计数不能直接相加得到跨日去重设备数。

## 失败诊断：把异常收敛到可排查的范围

[![按版本筛选失败原因，显示原因次数、占比及相关事件类型](/images/analytics/failures.webp)](/images/analytics/failures.webp)
页面汇总失败事件、最常见原因和失败率最高的系统版本。原因表同时展示**次数、占比、事件类型和受影响的热更版本**，可按热更版本筛选。

已知原因包括超时、网络错误、磁盘空间不足、校验不一致、补丁应用失败、HTTP 错误、文件读写和解压失败等。未上报具体原因的事件会单独归类，避免把未知原因解释成某种故障。

[![按系统版本和运营商比较下载成功、下载失败、补丁失败、激活、回滚及相应比率](/images/analytics/failure-dimensions.webp)](/images/analytics/failure-dimensions.webp)
继续往下可按**操作系统版本**和**运营商**对比成功、失败与回滚，判断异常是否集中在某类环境。运营商事件当前没有热更版本维度，筛选单个版本时该表会说明限制，不会展示未经筛选的数据来代替。

需要进一步检查 JavaScript 异常时，可进入「健康度」中的 [JS 报错监控](/docs/errors.md)，查看聚合错误、运行环境和还原后的源码堆栈。

## 数据范围与排查顺序

- 概览、流量与失败诊断按**北京时间自然日**统计；版本漏斗的事件窗口按 **UTC 日**统计。
- 今日数据实时累计，页面会定期刷新；当天尚未结束，不宜直接与完整一天比较。
- 分析日数据最多保留 **35 天**；地区数据最多保留 **30 天**。实时曲线的时间范围独立于页面天数，地区面板也有独立时间窗。
- 累计下载、激活设备与发布后时延属于版本累计数据，不受天数切换影响。原生包筛选不改变版本整体的累计设备和时延口径。
- 设备指标依赖 uuid，客户端事件依赖 SDK 上报；没有采集到的指标不能当作零故障。去重设备数采用近似统计。

一次常见排查可以从概览开始：检查流量和命中结果，再在版本漏斗确认受影响版本与原生包，最后用失败原因和系统分布缩小范围。把同一个应用的这些视图连起来，才能区分「没命中更新」「下载失败」和「已下载但尚未激活」。