数据分析
更新已经发布，接下来要知道：多少设备下载了、多少已经生效、哪些原生包还在旧版本上，以及失败集中在哪里。Pushy 把这些信息放在同一应用的概览、版本漏斗、流量画像、失败诊断四个视图中，让放量和排查都有数据依据。
在控制台进入「数据分析」，选择应用。也可以在应用页面切换到「数据分析」标签。上方支持近 7 / 14 / 35 天，应用、视图和天数会保存在页面 URL 中，方便团队分享同一分析范围。
本页为本地真实控制台截图。「拾光商城」及其版本、流量和设备数据均为模拟数据，用于展示功能，不代表客户案例或效果承诺。点击截图可查看原图。
概览：先看规模，再看请求结果
今日请求量、今日活跃设备、窗口内请求总量和峰值活跃设备，帮助你判断应用最近的更新活跃程度。每日趋势可以在请求结果与活跃设备之间切换。
往下还能看到请求结果构成与版本速览：
- 已是最新：客户端已经在运行绑定的最新热更。
- hdiff / pdiff 增量与整包：看清实际下发方式和各自占比。
- 暂停、过期、blocked、未登记原生包：区分正常发布状态和需要检查的配置问题。
- 版本速览：并列查看各版本的下发、激活、累计激活率、覆盖参照与健康标签，再进入完整版本漏斗。
这里的活跃设备按发起更新检查的设备 uuid 去重，属于更新服务的设备活跃指标。请求次数与去重设备数含义不同，不能将请求量当作用户数。
版本漏斗：从下发追到实际生效
每个热更版本独立展示下发 → 下载成功 → 激活 → 回滚的数据，并列显示失败次数、累计激活率和回滚率。可筛选热更版本或原生包；展开一行，就能继续查看：
- 原生包明细：比较同一个热更在不同原生包上的下发、下载、激活、失败与回滚。
- 累计激活与下载设备：用去重设备口径了解这个版本的累计生效情况。
- 发布时间到下载 / 激活的时延：按 1 小时内、1–6 小时、6–24 小时、1–3 天、3–7 天和 7 天以上分组，看到更新到达及生效的节奏。
- 健康标签：启动样本达到 10 次后，回滚率达到 1% 标为「关注」，达到 5% 标为「异常」。标签为排查提供线索，仍需结合样本量判断。
例如，模拟版本 3.6.1 的回滚率高于 3.6.2，就可以先筛选 3.6.1，检查是否集中在某个原生包，再转到失败诊断分析原因。
正确理解几个比率
窗口内的下载与激活事件可能不属于同一批设备，不宜直接相除作为转化率。累计激活率使用一致的累计去重口径。
流量画像：从访问节奏到网络与地区
流量画像保留实时版本曲线，并增加多个互补维度：
地区面板单独支持今日 / 近 7 天 / 近 30 天。中国大陆按省级展示，其他地区按国家级展示；它统计的是完成的更新检查请求，不是设备定位。地区名称会随界面语言展示。
原生包设备数采用所选窗口内的单日峰值，因为每日去重计数不能直接相加得到跨日去重设备数。
失败诊断：把异常收敛到可排查的范围
页面汇总失败事件、最常见原因和失败率最高的系统版本。原因表同时展示次数、占比、事件类型和受影响的热更版本，可按热更版本筛选。
已知原因包括超时、网络错误、磁盘空间不足、校验不一致、补丁应用失败、HTTP 错误、文件读写和解压失败等。未上报具体原因的事件会单独归类，避免把未知原因解释成某种故障。
继续往下可按操作系统版本和运营商对比成功、失败与回滚，判断异常是否集中在某类环境。运营商事件当前没有热更版本维度，筛选单个版本时该表会说明限制，不会展示未经筛选的数据来代替。
需要进一步检查 JavaScript 异常时，可进入「健康度」中的 JS 报错监控，查看聚合错误、运行环境和还原后的源码堆栈。
数据范围与排查顺序
- 概览、流量与失败诊断按北京时间自然日统计；版本漏斗的事件窗口按 UTC 日统计。
- 今日数据实时累计，页面会定期刷新；当天尚未结束，不宜直接与完整一天比较。
- 分析日数据最多保留 35 天；地区数据最多保留 30 天。实时曲线的时间范围独立于页面天数，地区面板也有独立时间窗。
- 累计下载、激活设备与发布后时延属于版本累计数据，不受天数切换影响。原生包筛选不改变版本整体的累计设备和时延口径。
- 设备指标依赖 uuid，客户端事件依赖 SDK 上报；没有采集到的指标不能当作零故障。去重设备数采用近似统计。
一次常见排查可以从概览开始：检查流量和命中结果，再在版本漏斗确认受影响版本与原生包，最后用失败原因和系统分布缩小范围。把同一个应用的这些视图连起来，才能区分「没命中更新」「下载失败」和「已下载但尚未激活」。