Should we revert the no-ads sale-pack removal?

0 · The numbers this verdict rests on

1 · What shipped, and what is left of the offer

earn is the decisive column: position holds the SKU for shop grants, so it is the client paying out the reward and cannot fire from a shop card that no longer exists. The 1,646 .sale grants still visible on v29 are the known ~230× re-emission of 30days.sale's 20,000-gem grant by devices that already own it (mostly the China mirror APK) — not sales. Do not read them as evidence the offer survives.

The .sale offer was a new-player window, not a standing shop item — re-confirmed on the extended data across 252 .sale purchases:

90.5% of purchases land within one day of install and 97.6% within two — so D0–D2 is the window the offer actually occupied (97.6% of its purchases fit inside it), and that is the window every comparison on this page uses. Install cohorts at matched days-since-install are still the cleanest comparison available, but not a clean one — see the two design problems at the end of section 2.

Ad-removal revenue by ISO week from GA4, ex-China, USD gross. Note what happened in the same weeks: skip.ad.permanent and skip.ad.30days keep selling, permanent.sale ends the week v32 ships, and skip.ad.30days roughly doubles ($12.75/wk pre → $68–98/wk post in the surviving weeks).

-- Did the removal ship, and on which build? Every no-ads signal by app version,
-- 2026-09-14 .. 2026-10-12 (v32 went live 2026-09-21).
-- `earn` is the decisive column: `position` holds the SKU for shop grants, so it is the
-- client paying out the reward and cannot fire from a shop card that no longer exists.
WITH e AS (
  SELECT app_info.version v, event_name, user_pseudo_id u, PARSE_DATE('%Y%m%d', event_date) d,
    event_value_in_usd usd,
    COALESCE((SELECT value.string_value FROM UNNEST(event_params) WHERE key='product_id'),
             (SELECT value.string_value FROM UNNEST(event_params) WHERE key='position')) sku
  FROM `tiny-knightfall-idle-rpg-game.analytics_538412813.events_intraday_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260914' AND '20261012'
)
SELECT v AS version, MIN(d) first_day, MAX(d) last_day,
  COUNT(DISTINCT u) users,
  COUNTIF(event_name='first_open') installs,
  COUNTIF(sku LIKE '%skip.ad%' AND sku LIKE '%.sale' AND event_name='purchase_click')  sale_taps,
  COUNTIF(sku LIKE '%skip.ad%' AND sku LIKE '%.sale' AND event_name='in_app_purchase') sale_buys,
  COUNTIF(sku LIKE '%skip.ad%' AND sku LIKE '%.sale' AND event_name='earn')            sale_grants,
  COUNTIF(sku LIKE '%skip.ad%' AND sku LIKE '%.sale' AND event_name='iap_purchase_success') sale_success,
  ROUND(SUM(IF(sku LIKE '%skip.ad%' AND sku LIKE '%.sale' AND event_name='in_app_purchase', usd, 0)), 2) sale_usd,
  COUNTIF(sku LIKE '%skip.ad%' AND sku NOT LIKE '%.sale' AND event_name='purchase_click')   full_taps,
  COUNTIF(sku LIKE '%skip.ad%' AND sku NOT LIKE '%.sale' AND event_name='in_app_purchase')  full_buys,
  ROUND(SUM(IF(sku LIKE '%skip.ad%' AND sku NOT LIKE '%.sale' AND event_name='in_app_purchase', usd, 0)), 2) full_usd,
  COUNTIF(sku LIKE '%skip.ad.annual.sale%' AND event_name IN ('purchase_click','in_app_purchase','earn')) annual_sale_signals,
  MAX(IF(sku LIKE '%skip.ad%' AND sku LIKE '%.sale' AND event_name='in_app_purchase', d, NULL)) last_sale_buy
FROM e
GROUP BY v
HAVING users >= 5
ORDER BY first_day

-- Ad-removal SKU revenue by ISO week (Mon-start) and SKU, 2026-08-01 .. 2026-10-12.
-- This is the revenue side of the removal: which SKUs carried it, when they stopped,
-- and what (if anything) replaced them. China is kept as its own row so it can be
-- excluded rather than silently dropped.
WITH e AS (
  SELECT PARSE_DATE('%Y%m%d', event_date) d, event_name, event_value_in_usd usd,
    geo.country country,
    COALESCE((SELECT value.string_value FROM UNNEST(event_params) WHERE key='product_id'),
             (SELECT value.string_value FROM UNNEST(event_params) WHERE key='position')) sku
  FROM `tiny-knightfall-idle-rpg-game.analytics_538412813.events_intraday_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20261012'
)
SELECT DATE_TRUNC(d, WEEK(MONDAY)) wk,
  REPLACE(sku, 'com.idle.tiny.', '') sku,
  IF(country = 'China', 'China', 'rest') geo_group,
  COUNTIF(event_name = 'purchase_click') taps,
  COUNTIF(event_name = 'in_app_purchase') buys,
  ROUND(SUM(IF(event_name = 'in_app_purchase', usd, 0)), 2) usd,
  COUNTIF(event_name = 'earn') grants
FROM e
WHERE sku LIKE '%skip.ad%'
GROUP BY wk, sku, geo_group
ORDER BY wk, sku, geo_group

2 · Design — install cohorts at matched days since install, and the two things wrong with that

Windows are D0, D0–D2 and D0–D7; each arm is restricted to installs whose whole window finished by 2026-10-09 (10-10 is an intraday, partial shard), so the D0–D7 arm is smaller than the D0–D2 arm by construction — which is why the two must never be compared to each other, only to their own offer-present baseline. Two traps are handled explicitly:

• China is excluded from both arms. The 09-19 mirror/bot spike is ~300 installs/day on v29 with $0 IAP and $0 ads; left in, it would make the post arm look better and v29 look terrible. It is still 9.7% of post-removal installs (255), so the all-builds row above exists to show it makes no difference.
• The 2026-09-28 09:00 → 09-29 03:00 UTC event gap (~18h, no events at all) sits inside the D0–D7 window of installs from 09-21 to 09-27, i.e. only the post arm. The gap-free row removes exactly those installs; the gap can only understate post revenue, which is the conservative direction for this verdict.

-- Per user-day facts, 2026-08-01 .. 2026-10-12 (one row per device per active day).
-- Source: GA4 raw export, events_intraday_* shards only. Extended from
-- notebooks/sql/15_user_day_facts.sql with the no-ads SKU classes split out, so the
-- substitution question (did .sale buyers move to the full-price twin?) can be answered
-- on the same per-install-day grid without a second scan.
WITH ev AS (
  SELECT user_pseudo_id u, PARSE_DATE('%Y%m%d', event_date) d, event_name e,
    event_timestamp ts, geo.country country, app_info.version v, event_value_in_usd usd,
    -- `earn` carries the SKU in `position`, purchases in `product_id`; take both, in this order
    COALESCE((SELECT value.string_value FROM UNNEST(event_params) WHERE key='product_id'),
             (SELECT value.string_value FROM UNNEST(event_params) WHERE key='position')) sku,
    -- Impression-level ad revenue reported by AppLovin MAX.
    (SELECT COALESCE(value.double_value, value.float_value, CAST(value.int_value AS FLOAT64))
       FROM UNNEST(event_params) WHERE key='value') val,
    (SELECT value.string_value FROM UNNEST(user_properties) WHERE key='appsflyer_id') af
  FROM `tiny-knightfall-idle-rpg-game.analytics_538412813.events_intraday_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20261012'
)
SELECT u, d,
  ANY_VALUE(country) country,
  ARRAY_AGG(v IGNORE NULLS ORDER BY ts DESC LIMIT 1)[SAFE_OFFSET(0)] v,
  MAX(af) af,
  COUNTIF(e='first_open') first_opens,
  -- all IAP
  SUM(IF(e='in_app_purchase', usd, 0)) iap_usd,
  COUNTIF(e='in_app_purchase') iap_buys,
  -- ad-removal SKUs, all of them
  SUM(IF(e='in_app_purchase' AND sku LIKE '%skip.ad%', usd, 0)) noads_usd,
  COUNTIF(e='in_app_purchase' AND sku LIKE '%skip.ad%') noads_buys,
  -- the discounted .sale variants removed in v32
  SUM(IF(e='in_app_purchase' AND sku LIKE '%skip.ad%' AND sku LIKE '%.sale', usd, 0)) sale_usd,
  COUNTIF(e='in_app_purchase' AND sku LIKE '%skip.ad%' AND sku LIKE '%.sale') sale_buys,
  -- the full-price twin of the pack that mattered: skip.ad.permanent at $29.99
  SUM(IF(e='in_app_purchase' AND sku LIKE '%skip.ad.permanent%' AND sku NOT LIKE '%.sale', usd, 0)) perm_full_usd,
  COUNTIF(e='in_app_purchase' AND sku LIKE '%skip.ad.permanent%' AND sku NOT LIKE '%.sale') perm_full_buys,
  -- the single pack that carried the volume: skip.ad.permanent.sale at $10.99
  SUM(IF(e='in_app_purchase' AND sku LIKE '%skip.ad.permanent.sale%', usd, 0)) perm_sale_usd,
  COUNTIF(e='in_app_purchase' AND sku LIKE '%skip.ad.permanent.sale%') perm_sale_buys,
  -- card taps: purchase_click, the player opening the offer
  COUNTIF(e='purchase_click' AND sku LIKE '%skip.ad%') noads_taps,
  COUNTIF(e='purchase_click' AND sku LIKE '%skip.ad.permanent%' AND sku NOT LIKE '%.sale') perm_full_taps,
  COUNTIF(e='purchase_click' AND sku LIKE '%skip.ad%' AND sku LIKE '%.sale') sale_taps,
  COUNTIF(e='purchase_click') shop_taps,
  -- ad revenue (impression-level) and impressions
  SUM(IF(e='ad_impression_MAX', COALESCE(val, 0), 0)) ad_usd,
  COUNTIF(e='ad_impression_MAX') ad_imps
FROM ev
GROUP BY u, d

-- One row per device: install date, install country, install build.
-- Trimmed to `first_open` only (notebooks/sql/15_user_history.sql also pulled purchase
-- dates, which the user-day facts now carry at day resolution anyway).
SELECT user_pseudo_id u,
  MIN(IF(event_name='first_open', PARSE_DATE('%Y%m%d', event_date), NULL)) install_date,
  ARRAY_AGG(IF(event_name='first_open', geo.country, NULL)
            IGNORE NULLS ORDER BY event_timestamp LIMIT 1)[SAFE_OFFSET(0)] install_country,
  ARRAY_AGG(IF(event_name='first_open', app_info.version, NULL)
            IGNORE NULLS ORDER BY event_timestamp LIMIT 1)[SAFE_OFFSET(0)] install_ver
FROM `tiny-knightfall-idle-rpg-game.analytics_538412813.events_intraday_*`
WHERE event_name = 'first_open'
GROUP BY u

Two design problems, stated up front — read these before any number below

1. This is not a natural experiment. The offer-present arm is installs 2026-09-04…09-20 and the offer-absent arm is 2026-09-21…10-07, so any calendar trend — UA campaigns ending, traffic quality, the 09-28 data gap, a store algorithm change — loads onto the treatment. Install cohorts at matched days-since-install remove the update-speed selection that ruins a version cut, but they cannot remove time. Every net-per-install interval on this page spans zero, and the arms' install rate differs by 2×.

2. A version-defined split cannot measure this effect, and its face value is misleading. It looks like the clean cut — “installs on a build that still has the offer” vs “installs on a build that does not” — but once v32 shipped, Play would not serve an older build to a new device, so a post-removal install on v31-or-older is almost never a real Play install. In this data 47.1% of that arm's installs are the known China mirror/bot APK (294 of 624), against 1.1% for v32+. The naive version split therefore reads IAP $0.06 per install for the arm whose client still has the offer versus $0.35 for the arm that lost it — which would argue for keeping the removal — while measuring a third-party APK spike, not the offer. It is disclosed here and used nowhere else in this document.

D0–D2 per install, all post-removal installs including China. The older-build row is what a version cut would report as the “offer present” counterfactual; it is an artifact of 47.1% mirror traffic, and it is why this cut is not used as evidence anywhere on this page.

What that leaves

The per-install comparison below is the best available read, but it is corroboration, not the load-bearing argument. The argument is the failure of the trade-up plus the un-replaced revenue plus the worse replacement product.

3 · Per-install outcomes

The offer-present arm sells across builds, which matters for the diagnosis: per-1,000 installs, .sale buyers were 16.9 on v24, 8.5 on v25, 13.3 on v26.2 and 8.0 on v29 — the offer was universal, not a quirk of one build.

4 · The decisive test — is the ad-revenue gain the removal, or the build?

Three checks, in increasing order of strictness:

1. Same week, by build. The two build groups are measured over exactly the same calendar days, so no time trend, UA campaign change or seasonal effect can produce the gap. v34 alone — 70% of the post arm — earns $77.93 per 1,000 impressions at 81.0% fill.
2. Same week, the two builds side by side. In 09-21…09-27 alone, v34 earns $61.40 per 1,000 impressions at 86.3% fill while v29 — the build whose client still sells the pack — earns $34.23 at 65.8%.
3. The one build present on both sides of the removal. v29's client never lost the offer, so the removal is a non-event for it. Across the removal its ad revenue per DAU is flat ($0.08 → $0.07) and its impressions per DAU are flat (1.7 → 1.8). Whatever moved ad revenue between the arms, it is not something the removal did to a build.

Is the gap bigger than ordinary build-to-build variation? No. In the pre-removal fortnight, with the offer on sale for everyone and no removal in existence, the same metric already ranged across builds — v26.2 $49.55, v25 $83.58, v24 $36.37, v29 $46.88, v28 $87.66 in the same two weeks. The arms' difference is inside the spread that builds produce on their own.

Pre-removal window 2026-09-07…09-20, offer present for every build.

Post-removal window 2026-09-21…10-07.

China excluded, as everywhere else on this page. Including the China mirror/bot APK's active users makes the older builds look worse, not better — v29's rewarded fill falls from 65.1% to 46.2% and its impressions held roughly constant (881 → 903), while v34 barely moves (81.0% either way). The per-impression gap is 2.1× on either basis ($77.93 vs $37.97 excluding China, $77.93 vs $37.11 including it).

What this does and does not settle

• Settled: the ~60% of the arm difference that is revenue per impression is a property of the v32+ ad stack (fill 79.1% vs 62.7%), not of the removal — the mechanism makes that impossible. Counting it as compensation is what made the removal look neutral.
• Not settled: a residual behavioural effect could exist for v32+ installs, because build and removal are perfectly collinear on the install side (every post-removal install is v32+, every pre-removal install is older). The check that would separate them is the country-standardised per-impression comparison below, and it is underpowered: the older builds contribute only ~20–180 impressions per country in the post window.
• The country-controlled cells are mixed and noisy — v32+ higher in Germany, Indonesia, South Korea and the US; older builds higher in Italy and Spain; Brazil level. That is consistent with a build/traffic-composition story rather than a uniform removal effect, but it is not a clean control, so the honest treatment is to withdraw the whole ad term rather than try to allocate a share of it.

-- Same-calendar-week ad economics by build — the decisive attribution test.
--
-- The question: the offer-absent arm earns more ad revenue per install than the
-- offer-present arm. Is that the removal (players who cannot buy ad-removal watch more
-- ads) or a property of the build (v32+ has much better rewarded fill than v29)?
--
-- Holding the calendar week fixed and grouping by build answers it, because a shop-card
-- change cannot alter revenue *per impression*. The window deliberately starts before the
-- removal so the same build gradient can be measured while the offer was still on sale.
WITH ev AS (
  SELECT app_info.version v, user_pseudo_id u, PARSE_DATE('%Y%m%d', event_date) d,
    event_name e, geo.country country,
    (SELECT COALESCE(value.double_value, value.float_value, CAST(value.int_value AS FLOAT64))
       FROM UNNEST(event_params) WHERE key='value') val,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key='ad_type') ad_type,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key='status') status
  FROM `tiny-knightfall-idle-rpg-game.analytics_538412813.events_intraday_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20261012'
    AND event_name IN ('ad_impression_MAX', 'ad_request_status', 'ad_reward')
)
SELECT DATE_TRUNC(d, WEEK(MONDAY)) wk, v AS version, country,
  COUNT(DISTINCT CONCAT(u, '|', CAST(d AS STRING))) user_days,
  COUNTIF(e = 'ad_impression_MAX') imps,
  ROUND(SUM(IF(e = 'ad_impression_MAX', COALESCE(val, 0), 0)), 2) ad_usd,
  COUNTIF(e = 'ad_request_status' AND ad_type = 'rewarded') rew_req,
  COUNTIF(e = 'ad_request_status' AND ad_type = 'rewarded' AND status = 'success') rew_ok,
  COUNTIF(e = 'ad_reward') rewards
FROM ev
GROUP BY wk, version, country
ORDER BY wk, version, country

5 · The crux — did .sale buyers trade up to the $29.99 twin?

Read the Play table as the authoritative cross-check (one row per order; GA4's in_app_purchase is Play's auto-logged telemetry and misses billing-only app instances). Two things stand out. Ad-removal orders fell 76% (120 → 29 over 20 days each) while the rest of the catalogue fell 38% (341 → 210, and total orders 461 → 239) — the removal cost the product real demand, and it did not come back at $29.99. And the one SKU that did pick up is a strictly worse product for the same money: 30 days of no ads instead of permanent.

6 · Net per install, per week, against the revenue that vanished

Where the apparent replacement came from (D0–D2, $/install): the surviving no-ads SKUs $0.05 ($0.01 … $0.08, significant — it is skip.ad.30days picking up, i.e. a worse product at the same price), other IAP $0.06 (−$0.04 … $0.18, not significant) and ad revenue $0.07 ($0.04 … $0.10, significant but withdrawn — see section 4).

The ad term, in one paragraph. Impressions per 1,000 installs rose 1,043.3 → 1,368.7 (+31%) and revenue per 1,000 impressions $60.32 → $96.39 (+60%). The second of those is the larger half and is mechanically impossible to attribute to a shop-card change; section 4 shows it is present in the same calendar week against every older build. The arms' build mixes differ (the offer-present arm is v24/v25/v26.2, the offer-absent arm is 70% v34), so the whole line is withdrawn from the primary estimate rather than partly credited.

Per-install outcomes in removal-aligned buckets (D0–D7)

Revenue run-rate by week, ex-China

Revenue is gross: event_value_in_usd on in_app_purchase is VAT-inclusive outside the US (75.4% of ad-removal revenue is non-USD) and the GA4 export has no refund event. VAT largely cancels in the twin-vs-sale comparison because both sell into a similar country mix, and refunds are handled separately in section 7. These weekly rows are restricted to devices with a first_open, so revenue and installs describe the same population; counted over the whole export the same weeks are 9–11% higher — .sale $277.43 → $304.13 in the 09-07 week and $197.55 → $221.54 in 09-14 — which is why the destroyed run-rate is quoted here as $241–$267/week rather than as one number.

Campaign mix — the arms are consecutive weeks, not a randomisation

The offer-absent arm has more Tier-1 ROAS traffic, which monetises better. Reweighting each arm's per-campaign outcome to the offer-present mix ((unattributed): 71%, GA_TinyKnightfa_A_ROAS_Global_20072026: 26%, GA_TinyKnightfa_A_ROAS_Tier1_150926: 3% of installs with an AppsFlyer id):

Mix reweighting moves D0–D2 slightly towards neutral (+0.0018 vs +0.0277 raw) and leaves the D0–D7 direction unchanged (-0.0819).

7 · Refunds — a separate action item, not a condition of the rollback

Defect 1 — the client never acknowledges one-time-product purchases. 10 refunds in the ledger were initiated by Google, and every single one lands between 72.167 h and 72.173 h after the charge (mean 72.169 h) — a machine, not a player. That is the signature of Play's automatic refund for a purchase the client never acknowledged inside the 3-day deadline. By SKU: skip.ad.permanent ×3, skip.ad.30days ×3, skip.ad.30days.sale ×1, skip.ad.permanent.sale ×1 — i.e. one of the ten is on the pack that was removed and six are on the two SKUs that remain on sale — plus auto.blessing ×2, which is not an ad-removal SKU at all. Removing the .sale packs cannot fix this, and it is not .sale-specific.

Defect 2 — the .sale pack's own grants went missing. Its ledger refunds are dominated by player-initiated reasons: 4× not_received, 2× defective, only 1× Google-initiated. That is players saying they paid and got nothing, on the pack that was ~30% of the offer-present arm's revenue per install (it alone was $0.13 of the $0.46 total). GA4 cannot separate a delivery bug from refund abuse of a cheap permanent entitlement; the reason mix, and the fact that the same acknowledgement signature appears elsewhere, both point at the delivery path rather than at abuse. The concrete next step is a client/Play question, not a telemetry one: take one refunded order, check its acknowledgement state, and check what the account was actually granted.

The ledger is an accumulation of Play's 30-day voidedpurchases window (re-pulled 2026-10-10 20:29, 40 refunds; earlier pulls cannot be recovered). Play's monthly sales report, which is complete, is the table in section 5 and is the better denominator: 30 refunds on 700 orders, 4.3%, of which ad-removal SKUs are 16.

8 · Verdict, the counter-argument, and what would falsify it

The strongest argument against rolling back

Two things, and they are why this is written as a preponderance call. First, the raw D0–D2 point estimate is positive — total revenue per install +0.0277 (CI −$0.14 … $0.20), and campaign-mix reweighted +0.0018. If even part of the ad gain is real behaviour rather than the build — players who cannot buy ad removal watching more rewarded ads, which the data cannot rule out because build and removal are collinear on the install side — then the removal is closer to neutral than to a loss, and a rollback would be undoing a change that paid for itself. Second, the arms are consecutive time periods, not a randomisation: UA campaigns ended, traffic quality moved (post-removal D1 retention was ~5 pts lower), and the install rate halved, so no observational cut here is a clean counterfactual. If the removal's real purpose was to stop refund abuse rather than to reprice, the case for undoing it must rest on the refund numbers, and those are small (13 post-removal refunds against 17 before).

What would falsify this verdict

• A holdout, the only clean test. Ship a build that exposes skip.ad.permanent at $10.99 to a random half of new installs for two weeks. If the treated half does not out-earn the control, the destroyed .sale line was being replaced by something the measurement cannot see, and the rollback is wrong.
• Ad attribution, measured properly. Ad revenue per DAU and rewarded fill by build within the same calendar week, with enough old-build users to control for country. Section 4 already shows the per-impression gap is a build property ($78.46 vs $36.68 per 1,000 impressions at 79.1% vs 62.7% fill); if a properly powered country-controlled version showed the gap vanishes, the removal's neutrality would be back on the table.
• Price elasticity, measured directly. The v21 precedent cuts against the removal (combined ad-removal buyers rose 9.3 → 10.5 per 1,000 users when the mix flipped to $10.99). If a test of $10.99 against $29.99 showed the $29.99 tier converting comparably once the offer is present, restoring the discount would be unnecessary.
• Refund causality. If a client audit shows permanent.sale's not_received/defective refunds were refund abuse rather than a delivery fault, the case for keeping that specific SKU out of the catalogue strengthens; if they were a grant bug, the fix is client-side and restoring the pack carries no extra refund risk.
• Already checked, and neither reopens the case for keeping it removed: excluding the top payer moves the D0–D2 primary estimate from −$0.04 to −$0.05, and campaign-mix reweighting to −$0.03.

9 · Traps respected (and what I could not establish)

• Reused, not re-derived: the offer window, the 36.7% break-even framing, the v21 precedent, the refund-reason mix and the China spike were taken from the 2026-09-18/09-25/10-02 work and re-checked here rather than redone.
• Never scored on active users for the effect. Every effect comparison is install cohort × matched days-since-install, because the offer only exists in a new player's first days and a version cut on active users is an update-speed selection artifact. The one active-user comparison (section 4) asks a build-property question — revenue per impression, which who the users are cannot change — and it is labelled as such. The version-defined split is disclosed in section 2 and used nowhere.
• Gross revenue. event_value_in_usd is gross of refunds and VAT-inclusive outside the US; refunds come from Play's API, not GA4, and are reported separately. GA4 also misses billing-only app instances, so its absolute revenue level is slightly low — Play's order counts in section 5 are the authoritative totals.
• Not established: (a) the net revenue effect. The same-week build test settles the per-impression half of the ad question (section 4), but a residual behavioural ad component cannot be isolated because build and removal are perfectly collinear on the install side, and the install-cohort design confounds the removal with calendar time. That is why the net-per-install estimate is presented as corroboration with intervals that span zero, and why a version-defined split — which would report the opposite — is disclosed in section 2 and used nowhere; (b) whether the .sale refunds were a delivery bug or refund abuse — GA4 has no refund event and the client-side grant telemetry is a known partial instrumentation (9–73% per SKU), so this needs a client/Play check of one order's acknowledgement state; (c) why skip.ad.3days, skip.ad.10days and skip.ad.30days.sale also stopped selling in the week of 09-14, a week before v32 shipped — Play shows their last orders on 09-09/09-10/09-15, so there was a second shop change outside the v32 removal that this page does not explain; (d) whether the D0–D7 (-0.1331) or the D0–D2 (-0.0413) IAP-only estimate is closer to the truth — the two windows use different (nested) install sets and both intervals span zero, so the data cannot separate them; (e) the counterfactual conversion rate. The rollback's expected recovery is inferred from what the pack sold before it was withdrawn; it assumes those players still behave the same way in a smaller, differently-sourced install base, which nothing here tests.