付费率与 ARPU 报告：Vloom-GP，数据截至 2026-07-30

1按安装日的每日数据

今天是 2026-07-30，所以每一批用户能走到第几天由日历决定。安装日 D 的第 N 天就是日历上的 D+N 天，这一条限定了每一行最多能显示到哪里。

没有任何一批的数字是定局。 只有 07-24 有完整的 d5，07-25 走到 d4。07-28 这批在安装日之后 只有一个完整日（d1），07-29 一个都没有。07-30 的数字在当天走完之前还会变。

07-24 之前每天只有 1 到 32 次安装，下面所有检验都不纳入。

d0 付费率的 95% 置信区间：

五个完整日之间的差别是真实的，不是每日波动（χ² = 15.28，自由度 4，p = 0.0042）。 07-27 到 07-28 的下跌是真实的，不是波动：差 2.60 倍，p = 1.33 × 10⁻⁴（Fisher 检验）。

2ARPU 拆解

ARPU = 付费率 × ARPPU，是恒等式。

整个窗口 ARPPU 的区间是 $7.60 到 $16.83；下跌之前（07-24 至 07-27）是 $7.60 到 $14.23。 复购跨过下跌点的三个读数：1.65 → 1.69 → 1.67。

ARPPU 在各批用户变老的过程中也稳住了，所以这不是 d0 的假象（这个指标的分母是付费用户数， 会变大而不会塌掉，见第 11 节）：

3按同期群天数的累积

超过各批实际天数的格子留空，* 表示那一天还在进行中。两张表的分母都固定为 d0 安装数 （第 11 节说明为什么不能直接读 Adjust 自己的 _dN 字段）。

付费率。每一天后面的 × 是当天的步长（dN ÷ d(N−1)）；最后一列是从 d0 到最后一个完整天的累计。

ARPU，用同样的固定分母重算：

两个指标的累积主要发生在 d1 到 d3 这几步，到 d4 基本走完。

两张表的最后一列每一行的测量深度都不同，从 07-24 的 d5 一直到 07-28 的 d1，所以顺着这一列往下读不能当成趋势。要比较就看 × 步长列，它们的深度是对齐的。

07-28 加 07-29 和前面三天真的不一样吗

07-25、07-26、07-27 三天在 d1 上彼此没有差别（χ² = 0.828，自由度 2，p = 0.6609）， 所以把这三天当成一条基准线是合理的。用三种口径分别和这条基准线比：

比较之前先把所有批次截到同一个天数。付费率会随天数累积，如果各批各读自己走到的深度， 就等于给更老的那一组多算了几天的累积，差距会凭结构被放大。

两个口径都显示差异是统计显著的。 d1 那一行没有 07-29，因为它的 d1 还在进行中； 下跌两侧目前都没有完整的 d2 或更深，所以 d1 已经是同天数比较能到的最深处。

付费用户到齐的节奏。 只有最老的两批能算这个。把 07-24 和 07-25 合起来（407 次安装， 27 个付费用户），一批用户最终付费人数中，到各天数已经到齐的比例是 d0 63.0%，d1 66.7%，d2 88.9%，d3 96.3%，d5 100%。这个底数只有 27 个人， 所以这条曲线只是个量级，不是测量结果。

4按素材和广告组

按素材，d0 付费率：

按广告组：in_sasian_3up_purchase_d60 5.56% → 2.92%；utility_6s_purchase_d10 11.39% → 2.20%。

只看 T3 印度（同一个广告系列、同一个地区）：6.61% → 2.81%，Fisher p = 1.34 × 10⁻³。 T3 自己各个完整日之间也有差别（χ² = 11.63，自由度 3，p = 0.0088）。

5按国家、T1/T2/T3 和测试轮次

全窗口 d0 付费率，汇总值 4.97%。

按广告系列：

6按归因状态

Fisher p = 8.56 × 10⁻⁷。

未归因占当日安装的比例：

后端付费的 tracker 覆盖率：63.4% 带得上可解析的素材 tracker。

7与合作方基准的对比

对比基准是合作方应用矩阵（Android，全部历史）。两边都取 d0，同为 Android。

印度占我们全部量的 83%。

8投放时段

按 UTC 小时段的安装数：

07-27 对 07-28，截到相同小时：1.42 倍，Fisher p = 0.036。

按一天内的小时汇总（07-26 至 07-29）：最高 UTC 07:00 的 17.28%，最低 UTC 10:00 的 2.40%。 没有任何单一小时出现阶跃。

9结论

1. 下跌发生在 07-27 到 07-28 之间。 27 号是整段时间里付费率和 ARPU 的最高点。日与日之间的 差异在统计上是真实的（第 1 节），不是抽样波动。

1. 下跌全部来自付费率。 07-28 的 ARPPU（$16.83）高于下跌前的区间，复购是平的： 1.65 → 1.69 → 1.67（第 2 节）。付钱的人变少了，而付了钱的人花的钱和购买频次都照旧。 针对定价、套餐或客单价的动作，动的是没有变化的那一部分。

1. 07-28 加 07-29 和前面三天在统计上确实不同。 在六批都完整的 d0 上比，差 1.95 倍 （p = 6.1 × 10⁻⁵）；在两侧都有数据的最深天数 d1 上比，差 2.86 倍（p = 4.4 × 10⁻⁶）。 下跌前三天在 d1 上彼此没有差别 （p = 0.66），所以把它们当成一条基准线是合理的（第 3 节）。07-28 这批的累积也更慢：从 d0 涨 1.06 倍， 07-27 是 1.19 倍，07-26 是 1.36 倍；但只有一天的累积，这是个弱信号，还谈不上趋势。

1. 用 d0 ARPU 判断回本会低估约 1.4 至 1.7 倍。 在唯一几批够老的数据上：07-24 到 d5 是 1.46 倍，07-25 到 d4 是 1.70 倍，07-26 到 d3 是 1.35 倍（第 3 节）。安装日之后 ARPU 确实还在 涨，但幅度没那么大，付费率的累积幅度也差不多。07-28 和 07-29 这两批还太新，放不到这条曲线上， 所以收入受损的幅度尚未确定。

1. 目前的收入损失。 07-28 的 707 次安装带回 $269，按 27 号的 ARPU 应为 $476。 下跌后两个完整日的 d0 收入，比 07-25 至 27 的水平低约 $478，比单独对比 27 号低约 $587。

1. 买量的任何切分方式都解释不了它。 27 号分布在 1.89% 到 11.39% 之间的七个素材，28 号全部落进 2.20% 到 3.03%（第 4 节）；两个广告组内部、以及单一广告系列加单一地区内部，跌幅同样存在。 放到全窗口看，国家、T1/T2/T3、测试轮次和广告系列都分不出差别，每个区间都覆盖汇总值 4.97%（第 5 节）。

1. 日度跌幅里大约一半来自投放时段。 28 号晚间几乎没有量（17–23 时只占 2.5%，前一天是 24.9%），而付费率 在一天之内的波动接近 7 倍。截到两天都在跑的相同小时，跌幅是 1.42 倍而不是 2.60 倍，并且三天 之后仍比 27 号低约 35%（第 8 节）。

1. 未归因安装是数据里最强的单一效应：1.00% 对 4.97%，p = 8.6 × 10⁻⁷，而且它的占比在下跌点 从 13.4% 升到 19.4%，这两天付费用户都是零（第 6 节）。要么这部分流量本来就不转化，那么占比 上升会机械地拉低混合比率，第 1 条里有一部分是结构造成的；要么归因漏掉了真实付费用户，那么 这里每一组的比率都被低估。

1. 印度的转化只有矩阵基准的 64%，也是唯一一个置信区间穿过基准的国家（第 7 节）。 它占我们全部量的 83%，是本报告里最大的单项差距。

10未解决的问题

11测量说明

Adjust 的 cumulative_paying_users_conversion_rate_dN 不能用，在这个应用上 d7 读出 805%。 它用累计付费用户数去除 cohort_size_dN，后者只统计已经活到第 N 天的用户，在一个年轻账户上这个 分母会塌掉：

本报告每一个比率都是 sum(paying_users_d0..dN) / cohort_size_d0，分母固定，从原始计数算， 不读 Adjust 的任何比率列。单日增量列 paying_user_conversion_rate_dN 在聚合口径下同样不可靠： 它是各日比率的加权平均，跟正确读数差约 4%。

all_revenue_total_per_user_dN（ARPU）带着同一个会塌掉的分母，而且这个更容易漏掉。 在这次拉取上实测：

引用 d0 之后的任何 ARPU 之前，都要按 ARPU_dN × cohort_size_dN / cohort_size_d0 重算。 直接读原始字段，在本报告的早期草稿里得出过「ARPU 累积 2.4 到 3.7 倍」，正确的区间是 1.35 到 1.70 倍。ARPPU（revenue_total_per_paying_user_dN）是安全的，它的分母是付费用户数， 会变大而不会塌掉（07-27：11.43 → 12.36 → 12.32；07-28：16.83 → 16.18）。

同期群天数受日历限制。 安装日 D 的第 N 天就是日历上的 D+N 天，所以在 07-30 这一天， 07-28 这批根本没有 d3，它的 d2 也还在进行中。Adjust 对这些格子返回 0，而累计求和会把这个 0 变成一条水平线，看起来正好像「这批用户不再转化了」。从任何累积表里下结论之前， 先把超过各批实际天数的格子留空。汇总口径的「付费到齐节奏」有同一个毛病的隐蔽版本： 新批次只贡献 d0、后面没有，把第一格抬到了 80.8%，而只看够老的批次是 63.0%。

复购是累计交易笔数除以累计付费用户，所以当一批用户新增付费人数快于新增交易时它会回落 （07-24 在 d3 是 2.83，d5 是 2.57）。它是到目前为止的人均交易笔数，不是一个比率。

day 维度是 UTC，Ads Manager 是 UTC−7。 已验证：同期群 day 的合计等于该日 UTC 各小时之和 （1,307 / 707 / 962），而不是太平洋时间各小时之和（1,188 / 629 / 829）。跟 Meta 做关联时用 asset_estimator.sources.window_for_pt_day()。跟任何采用不同时区口径的表格对比之前， 必须先把这一点对齐，否则日期不可信。

一个走完的自然日是终值。 隔两天重新拉 07-27 那个窗口，每一个已经走完的小时都完全一致， 唯一变动的是第一次拉取时还在进行中的那一小时。当天数据只有正在进行的那一小时是暂时的。

当天未结束的数据不能和完整一天的数据相比。 原因是第 8 节里接近 7 倍的小时波动， 这也是任何日报最硬的约束。

12复现

export ADJUST_API_TOKEN=$(bwx field suite.adjust.com api_token | tail -1)   # 取最后一行
python _runs/2026-07-29_payer_rate_analysis/pull.py
python _runs/2026-07-29_payer_rate_analysis/analyse.py    # 输出 results.json

全程用 Wilson 区间。凡是表格里的格子太薄、标准卡方不适用的地方，改用精确检验（置换法）。

如果要做成常态化日报，这个同期群拉取应该收进 asset_estimator/，它是这里唯一一段每个周期 都会被重写的代码，而这正是 asset_estimator/README.md「Why it exists」那一节要防的事。