Tiny Knightfall · source: GA4 export tiny-knightfall-idle-rpg-game.analytics_538412813 ·
weeks run Friday to Thursday · revenue is gross (VAT-inclusive outside the US, before refunds) ·
per-version tables cover 2026-10-02 to 2026-10-08 and exclude China unless stated ·
predecessor: week ending 1 Oct.
An uneventful week. Total revenue $788, up +11% on last week's $710; DAU 520 (was 560); new installs outside China 852 (was 926). Nothing broke, and no new issue appeared in the data. The two things worth knowing are both corrections rather than events:
The apparent jump in ad performance is one account. Ad revenue $174 against $113, eCPM $80 against $57 — but a single new player in Romania is credited $15.00 of it, all three of their impressions logged at exactly $5.00, which are the only $5.00 impressions in the entire export. Removing that one account, eCPM is $73 against $53 — roughly flat. Ad revenue net of the $5.00 impressions is still up +53% and the increase runs across the distribution, not just the top of it, so the ad business did improve; it is the size of the eCPM jump that the three impressions manufacture. User-days carrying an impression worth $1 or more are 15 of 2186 impressions but 36% of ad revenue, up from 18% the week before.
Day-1 retention recovered and the v34 question from last week is closed. On the same six install days, D1 is 26.1% for 02–07 Oct installs against 20.9% for 25–30 Sep. v33 and v34 were never really competing for the same installs — v33 took 8 installs this week (3 of them outside China) — so last week's "v34 progresses less than v33" reading was a rollout-cohort artefact, not a build regression. v34's own first-day progression is stable (42.2% → 40.3% reaching stage 10).
The state of last week's open items is in section 1; the rest of the page is the evidence for the numbers above.
Interstitials are unchanged and still by design: 725 INTER impressions exist in the whole export, every one of them an interstitial_backup_<placement> fallback; this week v34 logged 0 regular interstitials. This is not a defect.
| # | area | problem | affected versions | evidence | recommended action |
|---|---|---|---|---|---|
| 1 | Ad data quality | Three ad impressions logged at exactly $5.00 inflate the week's eCPM and ARPU | v34 (all 3 on one account) | A single new account in Romania (installed and last seen 10-05, 3 impressions, 18 min) is credited $15.00 — 9% of the week's ad revenue. All three impressions are logged at value = 5, the only $5.00 impressions in the whole export, 2 of them on AppLovin and 1 on Mintegral, all under the same MAX unit id 25f9e97521de1f7b. User-days carrying an impression worth $1 or more are 15 of 2186 impressions but 36% of ad revenue, up from 18% the week before. | Check this account's user-level revenue in the AppLovin MAX report for 5 October. If MAX also shows $5.00 per impression the value is real and the account is a genuine outlier; if it does not, the client's impression revenue parameter is being set from something other than the MAX callback. Either way, state the week's ad revenue with and without this account until it is resolved. |
| 2 | Ad monetisation | Ad-load failures changed shape: DNS blocking now dominates, host-resolution is down | v32, v33, v34 | Failed loads this week: 48% are the DNS lookup returning 0.0.0.0 (18 users, median 35 each, max 2,955), 35% log no error message at all (20 users, mainly Iran), and only 12% are Unable to resolve host "ms.applvn.com" (91 users) — last week that was the largest group at 40%. The retry behaviour is unchanged and still unbounded: 5,150 failed loads across 64 users. | Stop requesting ads for the session after a host-resolution or 0.0.0.0 failure instead of retrying to thousands of attempts per device, and always populate error on ad_request_status failures so bucket C can be diagnosed. |
| 3 | IAP | No-ads sale packs still absent; full-price offer converts poorly | v32, v33, v34 | 0 .sale taps, purchases and grants on v32–v34. Full-price no-ads taps 0 / 39 / 101 produced 0 / 1 / 14 purchases. The offer-absent arm's total revenue per new install on D0–D6 is $0.363 excluding its top payer, against $0.445 for the offer-present arm. | No client change required. Pricing decision pending the parallel no-ads analysis. |
| 4 | Analytics | Generic ad_reward over-fires; use ad_rewarded_<placement> as the reward record | v34 and older | Placement rewards track rewarded impressions almost exactly: 2,139 rewards against 2,132 impressions, 993 user × placement × days equal and 15 cells with an excess of 38 rewards. The generic ad_reward event runs at 0.97× per impression on v34 and 2.60× on v26.2. | No gameplay fix. Treat ad_rewarded_<placement> as the reward record and ad_reward as unreliable for counting. |
| 5 | Stability | Crash logging exists only from v30 and carries no exception type | v30+; not measured on v29 and older | app_exception first appears on v30 (3 fatal events, 1 user) and exists on v31–v34. 0 non-fatal exceptions are logged anywhere. Fatal exceptions in the first two days of a new install: 0.86% (v34), 4.93% (v33). | Attach the exception type or a Crashlytics issue id to app_exception, and log non-fatal exceptions, so a build regression can be seen without a store review. |
| 6 | Analytics | No new or dropped event names this week — but that check now has to be run weekly | — | Zero event names first seen on or after 10-02, and zero events logged by at least 20 v29 users that fall below a quarter of their v29 rate on v34. Coverage is unchanged from v29 through v34. | No action. Rerun both checks after every release; a version silently vanishing looks like "no data for that build", not like a bug. |
| 7 | Distribution | Unofficial v29 distribution in China continues, and v29 still receives installs | v29, v34 | China this week: 210 users, 120 installs, 33.2 min per user, 0 purchases, 10 ad impressions ($0.03). v29 also took 421 non-China users with 218 .sale reward grants and 0 purchases — the known repeated emission of the 30days.sale grant. | Excluded from KPIs. Consider blocking unofficial builds by installer source or signature. |
| # | what the previous report left open | outcome | what the numbers now say |
|---|---|---|---|
| 1 | v34 day-0 progression lower than v33 (42% vs 51% reach stage 10) | Resolved — not a regression | On the only dates the two builds were both being distributed (25–30 Sep, v33 n=138, v34 n=604) v33 really did progress further (51.4% vs 42.2% reaching stage 10) — but that is a rollout-cohort difference, not a build difference: v33's installs were concentrated on 25–26 Sep and it took only 8 installs in this report's week (3 of them outside China). v34's own progression is stable to slightly better on identical days (42.2% → 40.3%). |
| 2 | D1 retention fell to 20.9% for 25–30 Sep installs, attributed to traffic not the build | Confirmed, and it has reversed | Same six install days, same extract: D1 20.9% for 25–30 Sep installs → 26.1% for 02–07 Oct, so last week's 20.9% stands under the stricter six-day window. The whole move is non-Tier-1 traffic recovering (20.8% → 27.5%) while Tier 1 was flat (23.6% → 23.6%). Build is still not the explanation: v34's D1 on the two windows is 21.7% → 26.6%, and v33 is not comparable this week at all (8 installs in total, 3 outside China). |
| 3 | No-ads .sale pack removal — note the revenue context only | Held | Still zero .sale taps, purchases or grants on v32–v34. Revenue is not falling further: total $788 this week against $710 last week (+11%), IAP $613 against $597, ads $174 against $113. |
| 4 | Anything genuinely new — events, crashes, countries | Nothing new | No event name first seen on or after 10-02; no event dropped between v29 and v34; no new country of note; two unpublished builds appeared (v35 9 installs from 10-04, v36 6 installs from 10-07) with no crash logging yet. Fatal-crash rate on new installs is unchanged at 0.86% on v34. |
Revenue held at $788 (+11% on last week) while DAU kept falling to 520.
DAU is down -7% week on week and -42% against the week of 4 September. Installs outside China are down -8%. Revenue per DAU has risen in step ($1.515 against $1.268), so the revenue line is an audience story, not a monetisation story — and this week even the audience decline stopped costing money.
| week from (Fri) | DAU | DAU China | installs ex-CN | installs China | IAP USD | no-ads USD | .sale USD | other IAP USD | ad USD | total USD | payers | % DAU watching an ad | eCPM USD |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 08-28 | 969 | 7 | 1,943 | 25 | 1,544 | 508 | 363 | 1,036 | 129 | 1,673 | 84 | 6.6 | 50.9 |
| 09-04 | 899 | 5 | 1,959 | 15 | 1,349 | 513 | 321 | 836 | 98 | 1,448 | 67 | 6.7 | 50.7 |
| 09-11 | 824 | 6 | 1,688 | 30 | 1,298 | 515 | 302 | 783 | 146 | 1,443 | 56 | 7.6 | 54.4 |
| 09-18 | 776 | 136 | 1,119 | 635 | 878 | 145 | 50 | 732 | 121 | 999 | 40 | 8.3 | 53.8 |
| 09-25 | 560 | 33 | 926 | 99 | 597 | 131 | 0 | 466 | 113 | 710 | 37 | 8.6 | 57.0 |
| 10-02 | 520 | 18 | 852 | 49 | 613 | 163 | 0 | 450 | 174 | 788 | 40 | 9.7 | 79.8 |
(cached: wk1009_15_user_day_facts.parquet)
(cached: wk1009_15_user_history.parquet)
One account is credited $15.00 — 9% of the week's ad revenue — from three impressions each logged at exactly $5.00.
The account (36d01b175594c2cc…) installed on 10-05 in Romania, was active only that day, and logged 3 ad impressions. Every one is logged with value = 5 — the only $5.00 impressions in the whole export, where the next largest single impression is $4.62. Two came through AppLovin and one through Mintegral, all under the same MAX unit id 25f9e97521de1f7b. The account also made two purchases on the same day ($24.25), so it is not obviously a bot; the question is whether MAX really paid $5.00 an impression for it.
| week from (Fri) | ad USD | largest single user USD | % of week's ad USD from that user | ad USD excluding that user | eCPM USD excluding | impressions of $1 or more | % of ad revenue from impressions of $1 or more |
|---|---|---|---|---|---|---|---|
| 09-18 | 121 | 8.5 | 7.0 | 113 | 50.2 | 7 | 24.4 |
| 09-25 | 113 | 9.4 | 8.3 | 104 | 52.5 | 7 | 17.5 |
| 10-02 | 174 | 15 | 8.6 | 159 | 73.0 | 15 | 36.2 |
The $5.00 impressions make the headline ad numbers unusable, but ad revenue did genuinely rise even without them.
Excluding the single largest ad-revenue user each week, eCPM went $50 → $53 → $73, against a headline of $54 → $57 → $80. On the same basis the week's ad revenue is $159 against $104 the week before (+53%), and the increase is spread rather than concentrated: users earning more than $1 account for $130 of it against $76, and the total among users earning more than $0.50 is $150 against $92 (71 users against 50). So the ad business did improve this week; the headline eCPM overstates it by roughly what the three $5.00 impressions are worth.
| week from (Fri) | users with any ad revenue | median ad $ per earning user | ad $ from users above $1 | users above $1 | ad $ from users above $0.50 | users above $0.50 | top 10 users' ad $ |
|---|---|---|---|---|---|---|---|
| 09-18 | 304 | 0.100 | 67.0 | 26 | 94.6 | 64 | 43.2 |
| 09-25 | 248 | 0.100 | 76.1 | 27 | 92.4 | 50 | 48.8 |
| 10-02 | 256 | 0.160 | 130 | 41 | 150 | 71 | 72.5 |
| week from (Fri) | users | impressions | ad USD | eCPM USD |
|---|---|---|---|---|
| 09-04 | 3,895 | 1,941 | 98.3 | 50.7 |
| 09-11 | 3,526 | 2,677 | 146 | 54.4 |
| 09-18 | 2,729 | 2,256 | 121 | 53.8 |
| 09-25 | 2,327 | 1,987 | 113 | 57.0 |
| 10-02 | 2,169 | 2,186 | 174 | 79.8 |
-- ad revenue by impression size, from the weekly facts extract SELECT ... SUM(ad_usd), COUNTIF(ad_imps > 0), SUM(ad_imps) ... GROUP BY user_pseudo_id, day -- see notebooks/sql/15_user_day_facts.sql; ad_usd = SUM(value) over ad_impression_MAX
Three impressions, one account, 5 October 15:43–17:47 UTC.
These are the rows to reconcile against MAX user-level revenue. If MAX shows $5.00 per impression the value is real and the account is an outlier the pipeline should exclude from trend reporting; if it does not, the client is writing the wrong number into ad_impression_MAX's value parameter.
-- the three impressions, from the raw export
SELECT FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', TIMESTAMP_MICROS(event_timestamp)) ts, geo.country,
app_info.version, ad_placement, value, ad_source, ad_unit_name
FROM `tiny-knightfall-idle-rpg-game.analytics_538412813.events_intraday_*`
WHERE _TABLE_SUFFIX BETWEEN '20261002' AND '20261008' AND event_name = 'ad_impression_MAX'
AND user_pseudo_id = '36d01b175594c2cc957eb8a6c88bafcc'Day-1 retention is back to 26.1% for installs from 2 October, from 20.9% for the previous week's installs.
Share of new installs (excluding China) active on the calendar day after install. The headline and the per-build funnel below use the same six install days in each week (25–30 Sep and 02–07 Oct), because the extract's last day is 09 October: an install on 10-08 has its day 1 on 10-09 and is already counted, while an install on the last day of an earlier week does not. Installs of 27 September are excluded from both, as their day 1 falls inside the 28 September collection gap.
| install week from (Fri) | installs | D1 % | installs in observation window | D1 % (observation window) | D1 % Rest of world | D1 % Tier 1 |
|---|---|---|---|---|---|---|
| 2026-08-21 | 3,010 | 26.5 | 2,625 | 26.3 | 25.8 | 27.9 |
| 2026-08-28 | 1,943 | 24.6 | 1,701 | 24.9 | 25.1 | 23.6 |
| 2026-09-04 | 1,958 | 25.9 | 1,662 | 25.6 | 25.6 | 26.8 |
| 2026-09-11 | 1,689 | 26.6 | 1,482 | 26 | 25.4 | 28.3 |
| 2026-09-18 | 1,123 | 25.6 | 947 | 25.8 | 26.2 | 24.7 |
| 2026-09-25 | 796 | 21.7 | 679 | 20.9 | 20.8 | 23.6 |
| 2026-10-02 | 852 | 22.3 | 729 | 26.1 | 27.5 | 23.6 |
The recovery is in non-Tier-1 traffic; Tier 1 is unchanged at 23.6%.
Rest of world went 20.8% → 27.5% while Tier 1 went 23.6% → 23.6% (tier split computed over the observation window). That is the mirror image of last week, when the drop was concentrated in non-Tier-1 traffic. At 679–729 installs in the window this is a swing of about 45 players, so the honest reading is that D1 has returned to its normal 22–27% band rather than that anything was fixed.
v34's first-session progression is stable, and the build comparison that suggested otherwise is confounded.
Restricted to the six install days each week with their day-1 returns fully observed (25–30 Sep and 02–07 Oct), both weeks' installs are measured identically. v34's D1 rose 21.7% → 26.6% and its stage-10 reach is 42.2% → 40.3%. v33 appears only in the earlier window: it was shipped alongside v34 on 25–26 September and had 138 installs there, then 8 installs in this report's week (3 outside China). Comparing the two builds across those dates compares a staged rollout's early adopters with a fully distributed build's ordinary traffic, which is the same selection artefact the release notes warn about.
| install week | install build | installs | D1 % | % start stage 1 | % reach stage 10 | % reach stage 20 | median min in 24 h | % under 1 min | sessions in 24 h | % with a fatal crash |
|---|---|---|---|---|---|---|---|---|---|---|
| A 25-30 Sep (previous report) | 33 | 138 | 18.8 | 71.7 | 51.4 | 36.2 | 8.5 | 25.4 | 1.5 | 5.1 |
| A 25-30 Sep (previous report) | 34 | 604 | 21.7 | 66.7 | 42.2 | 25.3 | 4.7 | 32.8 | 1.6 | 0.990 |
| B 02-07 Oct (this week) | 34 | 689 | 26.6 | 67.6 | 40.3 | 24.8 | 5.8 | 28.2 | 1.6 | 0.580 |
(cached: wk1009_d1_first_session_this_week.parquet)
(cached: wk1009_onboarding_by_install_version.parquet)
| install_ver | first_install | last_install | installs | d1_eligible | d1_pct | median_d0_minutes | pct_under_1_min_d0 | installs_with_fatal_crash_d0d1 | pct_with_fatal_crash |
|---|---|---|---|---|---|---|---|---|---|
| 34 | 09-25 | 10-08 | 1,519 | 1,300 | 24.9 | 4.7 | 32.4 | 13 | 0.860 |
| 33 | 09-25 | 10-07 | 142 | 130 | 17.7 | 7.1 | 28.9 | 7 | 4.9 |
Fatal crashes on new installs are unchanged: 0.86% of v34 installs in their first two days.
v33 is higher at 4.93% but on only 142 installs. Exception logging starts in v30, so older builds are not comparable — zero crashes there means "not measured". No non-fatal exceptions are logged anywhere.
| version | first_day | fatal_exceptions | nonfatal_exceptions | users_affected |
|---|---|---|---|---|
| 30 | 09-21 | 3 | 0 | 1 |
| 31 | 09-22 | 10 | 0 | 4 |
| 32 | 09-22 | 24 | 0 | 11 |
| 33 | 09-24 | 16 | 0 | 12 |
| 34 | 09-26 | 26 | 0 | 17 |
(cached: wk1009_crash_logging_by_version.parquet)
2,139 of 2,170 rewarded placement rewards (98.6%) have a matching impression on the same placement within the hour.
For each reward, the same user's impressions were searched ±1 hour on the same placement. 1,959 rewards are followed by their impression within 0–1 s (MAX logs the impression after the reward callback, median 0.25 s), and only 31 rewards have no same-placement impression within an hour. The count-based check agrees on the population it covers: 993 user × placement × days have exactly as many rewards as impressions, and 15 cells have an excess of 38 rewards. No reward is granted without an ad beyond that small residue.
| gap_bucket | rewards | max_gap_s | also_impression_within_17s_before |
|---|---|---|---|
| next impression 0–1 s after | 1,959 | 0.997 | 23 |
| 1–5 s after | 151 | 4.9 | 1 |
| 5–17 s after | 22 | 16.8 | 0 |
| 17–60 s after | 5 | 31.8 | 0 |
| 1–10 min after | 2 | 573 | 0 |
| no impression within 1 h after | 31 | – | 0 |
(cached: wk1009_reward_impression_offsets.parquet)
| comparison | user_placement_days | rewards | impressions | excess_rewards |
|---|---|---|---|---|
| 1 equal | 993 | 2,103 | 2,103 | 0 |
| 2 more rewards than impressions | 15 | 67 | 29 | 38 |
(cached: wk1009_reward_impression_counts.parquet)
The generic ad_reward event still over-fires — 0.97× per impression on v34 — but only where there is no ad at all.
ad_reward carries one fixed AdMob unit id whatever network served the ad, so it cannot be used to count rewards. Placement rewards track impressions 1:1 on every build.
| build | users | placement rewards | rewarded impressions | placement rewards per impression | generic ad_reward per impression |
|---|---|---|---|---|---|
| 26.2 | 71 | 20 | 20 | 1 | 2.6 |
| 29 | 67 | 4 | 4 | 1 | 6.8 |
| 34 | 1,510 | 2,145 | 2,107 | 1.0 | 0.970 |
(cached: wk1009_reward_counts_by_version.parquet)
DNS blocking is now the largest cause of failed ad loads (48%) and host-resolution failures have fallen to 12%.
Last week the largest group was Unable to resolve host "ms.applvn.com" at 40% of failed loads. This week it is 12% (91 users, mainly Sudan, Iran and Ethiopia), while lookups returning 0.0.0.0 — the signature of a DNS ad blocker — are 48% from only 18 users, one of whom retried 2,955 times. A third group, 35% of failed loads from 20 users, logs no error value at all, so its cause cannot be determined from the data.
| what the SDK reported | users | failed loads | % of failed loads | median per user | max per user | top countries (users) |
|---|---|---|---|---|---|---|
| A · lookup of ms.applvn.com returns no address | 91 | 1,162 | 12.4 | 6 | 129 | Sudan 10, Iran 7, Ethiopia 6, Bangladesh 4, Afghanistan 3, Algeria 3 |
| B · lookup returns 0.0.0.0 (DNS ad blocker) | 18 | 4,505 | 47.9 | 35 | 2,955 | Indonesia 8, Brazil 4, Ecuador 1, Italy 1, Latvia 1, Malaysia 1 |
| C · no error message logged | 20 | 3,323 | 35.4 | 14 | 1,169 | Iran 13, Cuba 3, France 1, Iraq 1, Israel 1, Myanmar (Burma) 1 |
| D · no fill (no ad available) | 1 | 8 | 0.100 | 8 | 8 | Hong Kong 1 |
| E · other (connection reset, TLS, timeout …) | 7 | 401 | 4.3 | 32 | 244 | Canada 2, Iran 2, Bangladesh 1, Cuba 1, Ethiopia 1 |
(cached: wk1009_ad_fail_reasons.parquet)
Retry intensity is unchanged and still unbounded: 5,150 failed loads this week across 64 devices.
Builds with at least 50 users, counts per 1,000 users of that build. Rewarded fill is 84.3% on v34.
| build | users | rewarded impressions | regular INTER impressions | backup INTER impressions | ad USD | rewarded fill % | failed ad loads | users with failures | failed loads per affected user |
|---|---|---|---|---|---|---|---|---|---|
| 34 | 1,238 | 2,107 | 0 | 56 | 174 | 84.3 | 5,150 | 64 | 80 |
(cached: wk1009_ads_by_version.parquet)
Interstitials are unchanged and still by design: 725 INTER impressions exist in the whole export, every one of them an interstitial_backup_<placement> fallback; this week v34 logged 0 regular interstitials. This is not a defect.
Checked across the whole export rather than this week alone, because a single week cannot show that something never happens.
| placement | impressions | users | first_day | last_day | versions |
|---|---|---|---|---|---|
| interstitial_backup_acquire_hero | 76 | 43 | 08-24 | 10-09 | 22,24,25,26.2,28,29,32,34 |
| interstitial_backup_welcome_back | 74 | 50 | 07-14 | 10-09 | 17,18,19,20,21,22,24,25,26.2,28,29,33,34,9 |
| interstitial_backup_daily_quest | 74 | 48 | 07-05 | 10-04 | 10,16,18,19,20,21,22,24,25,26.2,29,34,8,9 |
| interstitial_backup_key_challenge_BossRush | 57 | 45 | 07-07 | 10-09 | 10,14,16,17,18,19,20,21,24,25,26.2,29,32,8,9 |
| interstitial_backup_summon_companion | 45 | 34 | 07-09 | 10-08 | 10,15,16,17,19,20,21,22,24,25,29,34,9 |
| interstitial_backup_lucky_spin | 44 | 35 | 07-14 | 10-08 | 10,14,16,17,18,19,20,21,22,24,25,26.2,34 |
| interstitial_backup_key_challenge_GoldRush | 43 | 33 | 07-20 | 10-09 | 14,17,18,20,21,22,24,25,26.2,29,32,34 |
| interstitial_backup_summon_skill | 41 | 29 | 07-12 | 10-08 | 10,16,17,18,19,20,21,22,24,25,29,34 |
| interstitial_backup_blessing_attack | 37 | 17 | 07-12 | 10-07 | 16,17,18,21,22,24,29,34,9 |
| interstitial_backup_summon_gear | 32 | 24 | 07-10 | 10-10 | 10,15,16,17,18,19,20,21,22,24,26.2,29,34,9 |
| interstitial_backup_blessing_cooldown | 24 | 12 | 07-18 | 10-09 | 10,16,17,21,24,29,34 |
| interstitial_backup_game_speed_x2 | 22 | 20 | 07-23 | 09-29 | 16,17,19,20,21,24,26.2,29,34 |
| interstitial_backup_skip_time_research | 22 | 10 | 07-29 | 10-08 | 17,18,20,21,26.2,29,34 |
| interstitial_backup_flybox_gold | 20 | 16 | 07-16 | 10-06 | 10,14,17,20,21,24,26.2,29,34 |
| interstitial_backup_key_challenge_HoneyWar | 20 | 14 | 07-29 | 10-01 | 17,18,20,21,24,26.2,29,34 |
| interstitial_backup_blessing_gold | 18 | 11 | 07-18 | 10-06 | 10,17,19,20,21,26.2,29,34 |
| interstitial_backup_summon_talisman | 13 | 9 | 08-03 | 10-06 | 18,21,24,28,29,34 |
| interstitial_backup_flybox_blessing | 9 | 9 | 07-12 | 09-29 | 10,15,21,22,24,26.2,29 |
| interstitial_backup_key_challenge_KingOfHell | 8 | 7 | 07-22 | 10-04 | 16,18,24,26.2,29,34 |
| interstitial_backup_key_challenge_SugarWorld | 7 | 6 | 08-03 | 09-21 | 18,24,29 |
| interstitial_backup_summon_toy | 5 | 4 | 08-24 | 09-20 | 22,24,26.2,29 |
| interstitial_backup_key_challenge_CatLegion | 5 | 4 | 08-27 | 09-21 | 24,29 |
| interstitial_backup_flybox_gem | 5 | 5 | 08-01 | 09-29 | 15,20,21,29,34 |
| interstitial_backup_leagueboss_attack_ad | 5 | 5 | 07-15 | 10-09 | 10,21,24,34 |
| interstitial_backup_observe_astrology | 5 | 3 | 08-31 | 09-20 | 24,26.2,29 |
| interstitial_backup_daily_garden_scissors | 5 | 4 | 07-18 | 10-08 | 15,24,26.2,34 |
| interstitial_backup_daily_exp_shard | 2 | 2 | 07-26 | 08-10 | 17,20 |
| interstitial_backup_refresh_cat_legion_cards | 2 | 2 | 09-06 | 09-12 | 24,26.2 |
| interstitial_backup_daily_garden_torch | 2 | 2 | 07-07 | 08-18 | 21,8 |
| interstitial_backup_daily_ability_point | 1 | 1 | 07-21 | 07-21 | 16 |
| interstitial_backup_rewareded_mini_event | 1 | 1 | 09-20 | 09-20 | 29 |
| interstitial_backup_daily_garden_saw | 1 | 1 | 07-18 | 07-18 | 15 |
(cached: wk1009_interstitial_history.parquet)
Still zero .sale signals on v32–v34, and revenue has stopped falling.
Total revenue $788 against $710 last week and $999 in the week of 18 September. The full-price no-ads offer is being tapped 101 times on v34 for 14 purchases. The parallel analysis of the removal itself is separate; this section only records the context.
| build | users | .sale taps | .sale purchases | .sale reward grants | full-price no-ads taps | full-price no-ads purchases |
|---|---|---|---|---|---|---|
| 34 | 2,400 | 0 | 0 | 0 | 101 | 14 |
| 29 | 421 | 0 | 0 | 218 | 0 | 0 |
| 32 | 98 | 0 | 0 | 0 | 0 | 0 |
| 33 | 418 | 0 | 0 | 0 | 39 | 1 |
(cached: wk1009_sale_by_version.parquet)
On D0–D6 the offer-absent arm's revenue per new install is $0.363 excluding its top payer, against $0.445 for the offer-present arm.
No-ads revenue per install is the only large, consistent difference; other IAP and ad revenue per install partly offset it. Every interval for the net change includes zero, so this remains a small-sample result.
| window | arm | installs | no-ads buyers /1k | no-ads taps /1k | no-ads USD/install | other IAP USD/install | ad USD/install | total USD/install | total excl. top payer |
|---|---|---|---|---|---|---|---|---|---|
| D0–D2 | offer present (installs 09-10..20) | 2,445 | 13.1 | 26.6 | 0.213 | 0.173 | 0.075 | 0.461 | 0.415 |
| D0–D2 | offer absent (installed on v32+) | 1,588 | 7.6 | 72.4 | 0.113 | 0.268 | 0.138 | 0.519 | 0.476 |
| D0–D6 | offer present (installs 09-10..20) | 2,445 | 13.1 | 27.4 | 0.213 | 0.201 | 0.078 | 0.491 | 0.445 |
| D0–D6 | offer absent (installed on v32+) | 1,409 | 5.7 | 79.5 | 0.077 | 0.245 | 0.112 | 0.434 | 0.363 |
The campaign cohorts that ran this week are far less concentrated than the two previous weeks' spikes.
AppsFlyer data for installs from 2–8 October. The 28–30 September Global cohort had 69% of its IAP from one Swedish player and the Tier1 15-09 cohort 98% from one US player; this week's largest payers are 23% and 22% of their cohorts.
| campaign | installs 02–08 Oct | spend USD | rev. observed to | IAP USD | ad USD | ROAS to date % |
|---|---|---|---|---|---|---|
| ROAS_Global_20072026 | 407 | 734 | D6 | 239 | 84.0 | 44.0 |
| ROAS_Tier1_29092026 | 185 | 1,700 | D5 | 97.3 | 164 | 15.4 |
| campaign | players with IAP revenue | IAP USD | largest payer USD | % from largest payer | % from top 3 payers | AF ad rows | players with ad revenue | AF ad USD |
|---|---|---|---|---|---|---|---|---|
| ROAS_Global_20072026 | 13 | 242 | 54.7 | 22.6 | 55.2 | 731 | 148 | 84.0 |
| ROAS_Tier1_29092026 | 8 | 97.3 | 21.6 | 22.2 | 57.3 | 281 | 86 | 164 |
Unlike the two previous weeks, the ROAS campaigns' revenue this week is not one player: the largest payer is 23% of the Global cohort's IAP and 22% of the Tier1_29092026 cohort's, against 69% and 98% for the 28–30 September cohorts. The top three still carry 55% and 57%, so per-cohort ROAS remains a small-sample number.
-- dashboard/af_cohort_revenue_check.py 2026-10-02 2026-10-08 -- pulls raw AppsFlyer IAP and ad-revenue rows per install cohort into -- dashboard/afdata_local/af_cohort_1002_1008_rows.csv, then groups by campaign and AppsFlyer ID -- cohort sizes, spend and revenue above come from the AppsFlyer payload in .github-target/campaigns.html
China remains the same picture: 210 users on v29, $0.03 of ad revenue and no purchases.
33.2 min per user, 3 shop taps opened, 0 purchases, rewarded fill 27.1%. Distribution is unchanged from the pattern first seen on 19 September and this traffic stays excluded from the KPIs.
| region | version | users | installs | minutes_per_user | shop_taps | purchases | iap_usd | ad_impressions | ad_usd | rewarded_fill_pct |
|---|---|---|---|---|---|---|---|---|---|---|
| China | 29 | 210 | 120 | 33.2 | 3 | 0 | 0 | 10 | 0.030 | 27.1 |
| rest of world | 34 | 2,391 | 1,519 | 31.4 | 309 | 133 | 1,042 | 3,798 | 274 | 80.7 |
| rest of world | 33 | 404 | 142 | 30 | 123 | 19 | 141 | 111 | 7.6 | 74.1 |
| rest of world | 29 | 217 | 39 | 15 | 14 | 1 | 3.4 | 198 | 5.2 | 59.8 |
| rest of world | 32 | 97 | 13 | 33.6 | 2 | 5 | 21.2 | 15 | 0.310 | 31.7 |
(cached: wk1009_china_by_version.parquet)
Older builds still take installs and are almost entirely inert.
This week, by install build and counting all countries: v34 809, v29 54 (40 of them in China), v35 9, v33 8, v21 7, v36 6, v32 2, v26.2 2 and a handful of single installs on builds back to v1. None of the pre-v34 builds logs meaningful revenue. Two unpublished builds also appeared for the first time: v35 (from 10-04, mostly OnePlus devices) and v36 (from 10-07). Neither logs a crash or a rewarded ad, which is what a build that has not finished rolling out looks like.
No event name was introduced or dropped this week, and no parameter set changed.
Event names first observed on or after 2 October: none. Events logged by at least 20 v29 users that fall below a quarter of their v29 per-user rate on v34: none. Coverage is unchanged from v29 through v34, which also means the v35 and v36 builds above have not shipped new logging yet.
(cached: wk1009_new_events_by_version.parquet)
(cached: wk1009_dropped_events_by_version.parquet)