The QBR conversation, lightly fictionalized but heard in some form four times in the last quarter:
VP of Growth: "What did we earn from ASO this quarter?" ASO Manager: "Our PPO experiments lifted CVR by an average of 8.4% across the apps we tested." VP: "So in dollars." ASO Manager: "Well, the CVR lift, applied to our install volume, would suggest somewhere around — let me run the math after this meeting."
That moment, repeated quarter after quarter, is where ASO programs lose their case for next quarter's investment. Not because the work was bad. Because the vocabulary the work was reported in does not match the vocabulary the budget is allocated in.
This post is about how to do the CVR-to-revenue translation honestly — in a way that survives leadership scrutiny rather than dying under it.
Why CVR alone does not survive a budget meeting
CVR uplift is the operator's working metric. It is the cleanest signal a store experiment produces. It also has three problems when it leaves the operator's surface:
It is a percentage, not a quantity. A 10% CVR lift sounds large. It might represent a few thousand dollars or a few hundred thousand. Without the install volume and revenue context, the percentage is unanchored.
It assumes the user is interpolating downstream behavior on your behalf. A CVR lift on the store page is an install-tap lift. It tells you nothing about whether the marginal installs activate, subscribe, purchase, or retain at the same rate as the baseline cohort. Most VPs know this in the abstract; in the QBR they will assume worst-case translation unless you give them better.
It compounds the noise of every input it inherits silently. Apple's PPO confidence threshold, your traffic split, your cohort window, the post-install attribution tier — all of these affect what an "8.4% CVR lift" actually means. None of them are visible in the percentage. Leadership tends to discount the percentage to zero when the inputs are not surfaced.
The ASO Manager's job is not to have CVR memorized. It is to translate CVR into the metric leadership reads — without losing accuracy in the translation — and to do that translation defensibly enough that the next VP question is "how do we run more of those?" rather than "is the math right?"
The components of an honest translation
A revenue projection from a CVR posterior needs three inputs from outside the experiment, and all three should come from the same place: your connected MMP.
ARPU. Average revenue per user, ideally segmented by acquisition channel and time horizon. This must come from MMP-derived data — AppsFlyer, Adjust, Branch, or Firebase Analytics-derived. Operator-attested ARPU ("we usually see about $3 per install") is the failure mode that tanks the conversation when the VP asks for the source.
Install-to-paid rate. What fraction of installs convert to a paying user, within a defined window. Subscription apps measure subscription start; transactional apps measure purchase. This rate is per-app and varies enormously by category — global benchmarks here are not honest.
Lifespan. How long the average paying user stays paying. Paired with ARPU and install-to-paid, this gives you the LTV component the projection rests on.
These three inputs make the CVR posterior translatable. Without them, you are extrapolating a CVR percentage into a revenue claim with no traceable source — and that claim does not survive the meeting.
The line in our claim-safety contract that is worth repeating: revenue claims are RANGES, not point estimates. "$3K–$5K per month additional revenue if the variant is winning at 85% probability" is defensible. "+$4,200 per month additional revenue" is not. The variance in the posterior plus the variance in ARPU and install-to-paid stack — pretending they collapse to a single number is what gets the budget cut.
What the disclosure has to look like
A revenue projection that survives leadership scrutiny carries its assumptions inline, not in an appendix. The hypothesis-card row our system is wiring this into will put the disclosure on the same row as the claim: the range, the probability threshold, the inputs sourced from your MMP, the time period the projection covers. (Today ASOLOOP renders one workspace-level revenue band, from your connected AppsFlyer revenue, on the Teams-tier stakeholder dashboard; the per-hypothesis row below is where it is headed, not what ships yet.)
What the row looks like, conceptually:
Variant B: ~$3K–$5K/month additional revenue at 85% probability of winning. Inputs: ARPU $4.18 (AppsFlyer, last 90 days, organic cohort) · install-to-paid 14.3% (AppsFlyer, last 90 days) · lifespan 8.4 months (AppsFlyer, last 12 months). CVR posterior: P(winner) = 0.87 against control, based on 24,400 viewers per cell.
The reason this works in a QBR is the same reason it works for the ASO Manager's own confidence: every input traces to a source. The VP can ask "how do we know ARPU is $4.18?" and the answer is the AppsFlyer report from the last 90 days. The VP can ask "why a range and not a number?" and the answer is the Bayesian posterior accommodates the uncertainty in the win probability and in the inputs themselves. None of those answers require the ASO Manager to leave the meeting and run the math.
When no MMP is connected
A real situation: ICP 2 indie operators, and some ICP 1 teams on AppsFlyer Zero, do not have an MMP feed wired up. The honest thing to do is not to fabricate revenue from operator-attested ARPU. The honest thing is to surface CVR confidence on its own and disclose that no revenue projection is available until the MMP feed is connected.
ASOLOOP handles this explicitly: CVR confidence surfaces on every hypothesis card regardless, and the workspace revenue band on the Teams-tier stakeholder dashboard stays in its connect-your-MMP state — it reads "Revenue band requires MMP" rather than inventing a figure — until AppsFlyer is connected. The VP question in this case becomes "what would it take to get to revenue projections?" rather than "why are these numbers so soft?" — and the answer is one MMP integration.
The principle: no revenue claim without traceable assumptions. This is the line our claim-safety validator rejects against. It is also the line that makes the QBR survive.
Reframing the QBR slide
The slide that loses budget says: "This quarter, ASO experiments lifted CVR by 8.4% on average."
The slide that retains budget says: "This quarter, four ASO experiments produced revenue impact in the ranges below at 85% probability. Aggregate range: ~$X–$Y per month, projected over the next 12 months at current install volume. Inputs sourced from AppsFlyer."
The first is a percentage with no anchor. The second is the metric your VP reads.
There is a Pro+ surface in ASOLOOP — the Executive Progress Report — built for this slide: what changed, what won, which signal produced it, exported as a stakeholder PDF. The dollar figures in the slide above are the part still being wired — translating each CVR posterior into a per-experiment revenue range is in progress, and the report will not show those numbers until they are real. For ASO Managers carrying the reporting burden quarter after quarter, the value of the report is roughly the value of the hours that go back into the program.
The honest part
Bounded AI on revenue claims feels more conservative than the marketing of competitor tools. "+30% installs" will always sound bigger than "$3K–$5K per month at 85% probability." The first claim cannot survive a real conversation with a CMO who has been around the block. The second one can.
The line we keep coming back to is the practitioner's: "it helps, but always have it reviewed by a professional." The professional in the QBR is a VP or CMO, and the review is whether the numbers will survive their next conversation with the CFO. Revenue ranges with traceable MMP-derived assumptions survive that conversation. CVR percentages without anchors do not.