scripts: read the install/deletion cohort, the report that made v1.49 not ship pings - #441
Merged
Conversation
… not ship pings
`App Store Installation and Deletion Standard` carries an `App Download Date`
on every row, which makes it the only Apple feed that yields a real COHORT:
how long after downloading did this install get removed.
That report is the stated reason v1.49 shipped a first-run window instead of
D1/D7/D30 retention pings — the pings would have been conditioned on the user
having already opened the popover and accepted the disclosure card, i.e. on
having cleared the very hurdle under investigation, so they could only ever
have described the survivors. But the reconcile tool did not read it, so the
justification was one session away from evaporating. Now it does.
Also adds `App Store Purchases Standard`, which is short enough to print in
full: one purchase, 2026-06-24, iPhone/CN/Alipay, $1.03 proceeds.
THE COVERAGE LINE CAUGHT ITS OWN BUG, WHICH IS THE POINT
First version compared total `Install` events against first-time downloads and
printed **iPad coverage of 114%** — impossible for a subset, and visible
immediately. `Install` spans every Download Type (first-time, redownload,
auto-download, manual update); first-time downloads are one of them. Fixed to
compare first-time against first-time, which moves the sample fraction from a
comfortable-looking 18-64% to the real 5-14%:
Desktop 5/108 = 5%
iPhone 25/203 = 12%
iPad 1/7 = 14%
That matters more than a cosmetic fix. This feed is a CONSENTING-USER SAMPLE,
not a census, and it is a far smaller sample than the first version implied.
The SHAPE of the latency distribution is usable; deletes/installs is not a
deletion rate and the output now says so in the place someone would read it.
Current shape, n=27: median 0 days, 63% same-day, 74% within one day, 89%
within seven. Track it across releases — it is the readout for the v1.49
first-run window, and the honest one, because it is measured outside the app
rather than by the app.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
App Store Installation and Deletion Standardcarries anApp Download Dateon every row, making it the only Apple feed that yields a real cohort: how long after downloading did this install get removed.That report is the stated reason v1.49 shipped a first-run window instead of D1/D7/D30 retention pings — the pings would have been conditioned on the user having already opened the popover and accepted the disclosure card, i.e. on having cleared the very hurdle under investigation, so they could only ever have described the survivors.
But
acquisition_reconcile.pydidn't read it. The justification was one session away from evaporating. Now it does.Also adds
App Store Purchases Standard, short enough to print in full: one purchase, 2026-06-24, iPhone / CN / Alipay, $1.03 proceeds.The coverage line caught its own bug, which is the point
The first version compared total
Installevents against first-time downloads and printed iPad coverage of 114 % — impossible for a subset, and visible on the first run.Installspans every Download Type (first-time, redownload, auto-download, manual update); first-time downloads are one of them.Fixed to compare like with like, which moves the sample fraction from a comfortable-looking 18–64 % to the real figure:
That is not a cosmetic fix. This feed is a consenting-user sample, not a census, and a far smaller one than the first version implied. The output now says so in the place someone would actually read it:
Current shape
n=27— median 0 days, 63 % same-day, 74 % within one day, 89 % within seven, 100 % within thirty.A median at or near zero is the signature of "opened it, didn't get it" — abandonment before the app ever proved itself, which no in-app counter can observe because the counter only fires after the menu is opened and the disclosure accepted.
Track this series across releases: it is the readout for the v1.49 first-run window, and the honest one, because it is measured outside the app rather than by the app.
Verification
--self-teststill passes (the anti-threshold guard is applied to the new feed too).ruffclean — and as of ci: make ruff actually lint the Python it claimed to lint #437 that now actually runs onscripts/.cli-pulse-internal(41d4965), since it quoted the same inflated 18 % figure.🤖 Generated with Claude Code