Payer rate and ARPU report — Vloom-GP, data through 2026-07-30

1Daily figures by install day

Today is 2026-07-30, so each cohort has only aged as far as the calendar allows. Cohort age dN of install day D is calendar day D+N, which caps what any row can show.

No cohort has a settled number. Only 07-24 has a complete d5; 07-25 reaches d4. The 07-28 cohort has one complete day beyond install (d1) and 07-29 has none. 07-30's figures move while the day runs.

Days before 07-24 carry 1–32 installs each and are excluded from every test below.

95% confidence intervals on the d0 payer rate:

The five complete days genuinely differ from each other — this is not day-to-day noise (χ² = 15.28, 4 dof, p = 0.0042). 07-27 against 07-28 is a real drop, not a fluctuation: 2.60×, Fisher p = 1.33 × 10⁻⁴.

2ARPU decomposition

ARPU = payer rate × ARPPU, exactly.

ARPPU range across the window: $7.60 – $16.83. Pre-break range (07-24 to 07-27): $7.60 – $14.23. Repurchase across the break: 1.65 → 1.69 → 1.67.

ARPPU also holds as each cohort ages, so this is not a d0 artifact (this metric's denominator is paying users, which grows rather than collapses — §11):

3Cohort maturation

Cells past a cohort's honest age are blank; * marks the age whose calendar day is still running. Both tables use a fixed d0 denominator (§11 explains why Adjust's own _dN fields cannot be read directly here).

Payer rate. The × after each day is that day's step (dN ÷ d(N−1)); the last column is cumulative from d0 to the last complete day.

ARPU, recomputed on the same fixed denominator:

Most of the accrual lands in the d1–d3 steps and is spent by d4 on both metrics.

The last column of each table is measured to a different depth per row — d5 for 07-24 down to d1 for 07-28 — so it does not read down the column as a trend. Compare the × step columns, which are at equal depth.

Is 07-28 + 07-29 actually different from the three days before?

07-25, 07-26 and 07-27 show no difference from each other at d1 (χ² = 0.828, 2 dof, p = 0.6609), so it is fair to treat them as one baseline. Compared against that baseline three ways:

Every cohort is truncated to a common age before comparing. Payer rate accrues with age, so reading each cohort at whatever depth it happens to have reached would credit the older group with extra days of accrual and inflate the gap by construction.

Both say the difference is statistically significant. 07-29 is absent from the d1 row because its d1 is still running; no cohort on either side has a complete d2 or deeper on both sides of the break, so d1 is as deep as a like-for-like comparison can currently go.

Payer arrival profile. Only the two oldest cohorts can carry one. Pooling 07-24 and 07-25 (407 installs, 27 payers), the share of a cohort's eventual payers present by each age is d0 63.0%, d1 66.7%, d2 88.9%, d3 96.3%, d5 100%. That base is 27 people, so the profile is an order of magnitude rather than a measurement.

4By creative and ad set

Per creative, d0 payer rate:

Per ad set: in_sasian_3up_purchase_d60 5.56% → 2.92%; utility_6s_purchase_d10 11.39% → 2.20%.

T3 India alone (one campaign, one geo): 6.61% → 2.81%, Fisher p = 1.34 × 10⁻³. T3's own complete days also differ from each other (χ² = 11.63, 3 dof, p = 0.0088).

5By country, tier and generation

Full window, d0 payer rate. Pooled rate 4.97%.

Per campaign:

6By attribution status

Fisher p = 8.56 × 10⁻⁷.

Unattributed share of installs by day:

Tracker coverage on backend payments: 63.4% carry a resolvable creative tracker.

7Against the fleet benchmark

Same cohort age (d0), Android only.

India is 83% of our volume.

8Delivery hours

Installs by UTC hour block:

07-27 against 07-28 on identical hours: 1.42×, Fisher p = 0.036.

Conversion by hour of day, pooled 07-26 → 07-29: peak 17.28% at 07:00 UTC, trough 2.40% at 10:00 UTC. No single hour shows a step change.

9Findings

1. The break is 07-27 → 07-28. The 27th is the peak of the run on both payer rate and ARPU. The day-to-day variation is statistically real (§1), not sampling noise.

1. The fall is in the payer rate only. ARPPU on 07-28 ($16.83) sits above the pre-break range, and repurchase is flat at 1.65 → 1.69 → 1.67 (§2). Fewer people paid; those who did paid normally and bought as often as before. Measures aimed at pricing, packaging or basket size address the part that did not change.

1. 07-28 + 07-29 are statistically different from the three days before. Compared at d0, where every cohort is complete, the gap is 1.95× (p = 6.1 × 10⁻⁵); compared at d1, the deepest age available on both sides, it is 2.86× (p = 4.4 × 10⁻⁶). The three pre-break days show no difference from each other at d1 (p = 0.66), so using them as one baseline is fair (§3). The 07-28 cohort is also accruing more slowly — 1.06× from d0 against 1.19× for 07-27 and 1.36× for 07-26 — but on one day of accrual that is a weak signal, not a settled trend.

1. Day-0 ARPU understates by roughly 1.4×–1.7×. On the only cohorts old enough to say — 07-24 (1.46× by d5), 07-25 (1.70× by d4) and 07-26 (1.35× by d3) — ARPU keeps accruing after install day but not dramatically (§3). Payer rate accrues on a similar scale. The 07-28 and 07-29 cohorts are too young to place on the curve, so the size of the revenue damage is not settled.

1. Revenue cost so far. 707 installs on 07-28 returned $269 against $476 at the 27th's ARPU. Across the two complete post-break days, day-0 revenue is ~$478 below the 07-25→27 run rate, or ~$587 below the 27th alone.

1. No dimension of how we split the buy explains it. Seven creatives spread 1.89%–11.39% on the 27th converge into 2.20%–3.03% on the 28th (§4); the same fall appears in both ad sets and inside a single campaign and geo. Over the full window country, tier, generation and campaign all fail to separate — every interval covers the pooled 4.97% (§5).

1. About half the headline size was delivery timing. The 28th lost its evening block (2.5% share against 24.9%), and conversion swings ~7× by hour of day. Restricted to hours both days ran, the fall is 1.42× rather than 2.60×, and it persists ~35% below the 27th three days on (§8).

1. Unattributed installs are the largest single effect in the data — 1.00% against 4.97%, p = 8.6 × 10⁻⁷ — and their share rose from 13.4% to 19.4% at the break with zero payers (§6). Either that traffic genuinely does not convert, in which case a rising share drags the blended rate down mechanically and part of finding 1 is mix; or attribution is losing real payers, in which case every per-arm rate here understates.

1. India converts at 64% of the fleet benchmark and is the only country whose interval clears its benchmark (§7). At 83% of our volume it is the largest single gap in the report.

10Open items

11Measurement notes

Adjust's cumulative_paying_users_conversion_rate_dN is unusable — it reads 805% at d7 on this app. It divides cumulative payers by cohort_size_dN, the count of users who have aged N days, and that denominator collapses on a young account:

Every rate here is sum(paying_users_d0..dN) / cohort_size_d0 — fixed denominator, raw counts, no Adjust rate column read. The incremental column paying_user_conversion_rate_dN is also unsafe in an aggregated pull: it is a weighted mean of per-day rates, ~4% off the honest figure.

all_revenue_total_per_user_dN (ARPU) carries the same collapsing denominator, and it is the easier one to miss. Measured on this pull:

Recompute as ARPU_dN × cohort_size_dN / cohort_size_d0 before quoting any ARPU past d0. Reading the raw field produced a "2.4×–3.7× ARPU maturation" figure in an earlier draft of this report; the honest range is 1.35×–1.70×. ARPPU (revenue_total_per_paying_user_dN) is safe — its denominator is paying users, which grows rather than collapses (07-27: 11.43 → 12.36 → 12.32; 07-28: 16.83 → 16.18).

Cohort age is capped by the calendar. dN of install day D is calendar day D+N, so on 07-30 the 07-28 cohort has no d3 at all and its d2 is still running. Adjust returns 0 for those cells, and a cumulative sum turns the 0 into a flat line that reads exactly like "the cohort stopped converting." Blank every cell past a cohort's age before drawing any conclusion from a maturation table. A pooled payer-arrival profile has the same defect in a subtler form: young cohorts contribute a d0 and nothing else, which loaded the first bucket to 80.8% against 63.0% on mature cohorts only.

Repurchase is cumulative events over cumulative payers, so it can fall when a cohort adds payers faster than transactions (07-24 reads 2.83 at d3, 2.57 at d5). It is an average per payer to date, not a rate.

The day dimension is UTC; Ads Manager reports UTC−7. Verified — cohort day totals match UTC hour sums (1,307 / 707 / 962), not Pacific (1,188 / 629 / 829). Use asset_estimator.sources.window_for_pt_day() for any Meta join. Any comparison against a table on a different time base must reconcile this before the dates can be trusted.

A finished day is final. Re-pulling the 07-27 window two days later, every already-elapsed hour returned byte-identical; the only movement was the hour still in progress at the first pull. Same-day figures are provisional for the current hour only.

A part-day figure cannot be compared against a full-day one — the ~7× hour-of-day swing in §8 is the reason, and it is the binding constraint on any daily report.

12Reproduction

export ADJUST_API_TOKEN=$(bwx field suite.adjust.com api_token | tail -1)   # LAST line
python _runs/2026-07-29_payer_rate_analysis/pull.py
python _runs/2026-07-29_payer_rate_analysis/analyse.py    # -> results.json

Wilson intervals throughout. Where a table had cells too thin for the standard chi-square, an exact (permutation) test was used instead.

For a recurring daily report, the cohort pull belongs in asset_estimator/ — it is the one piece here that would otherwise be rewritten every cycle, the failure asset_estimator/README.md § "Why it exists" exists to stop.