How I turned failed pricing tests into an 18% revenue lift
DOWN is a subscription dating app with 15M+ registered users. Raising prices could grow revenue — or destroy paid conversion. I owned the Android pricing program and used each failed test to narrow the increase, fix the setup, and find a version worth shipping.
Senior Growth PM profile and resume- +18%
- Revenue vs control
- 19.2% vs 19.5%
- D0 churn held
- ~7.25%
- Match rate in both groups
- Ship
- To the tested segment
- My role
- Growth Product Manager
- Product
- DOWN · B2C dating app with subscriptions
- Audience
- New male users · Android · United States
- My ownership
- Brief → treatment → QA → readout → rollout
A higher price only works if people still buy
Subscriptions are a core revenue stream at DOWN. The upside was clear: capture more value from users willing to pay. The risk was just as clear: push too far and the paid funnel collapses.
That was already happening. One test cut VIP conversion by 23.8%. Another lost revenue after an aggressive increase on the three-month offer. A third run had a configuration bug and could not support a decision.
I did not need a better story for the same price increase. I needed a better test.
I used each loss to change the next test
The tests failed for different reasons. That mattered: each reason required a different next move.
-
01 · Stop
VIP conversion fell 23.8%
Paid conversion fell. The result was a reason to revise the offer, not proof of a universal price ceiling.
Next changeUse a smaller price step. -
02 · Stop
The price package earned less
The aggressive three-month offer increase lost revenue. It called for a different package, not a story about a higher price per purchase.
Next changeAdjust prices by offer, not with one blunt increase. -
03 · Invalid
The configuration was broken
The run could not answer the question. I invalidated it, fixed the setup, and tested again.
Next changeVerify configuration, targeting, allocation, and tracking. -
Next test
Moderate, offer-specific increases
The final test used smaller price steps and a fixed setup.
DecisionShip only if revenue grew and the protected metrics held.
The evidence behind the decision
This public reconstruction brings together the pricing recommendation, the earlier failures and the checks behind the next decision. It is a summary of the work, rather than an untouched pre-launch document.
Pricing · New male users · Android · US
Goal and non-goal
Goal: increase total revenue and ARPU.
Not the goal: maximize price at any cost.
Hypothesis
- If
- we use moderate, offer-specific price increases,
- Then
- total revenue and ARPU will rise,
- Without
- hurting paid conversion, early churn, retention, or match rate,
- Because
- the useful next question after aggressive tests failed was whether a smaller step could grow revenue without breaking the funnel.
Four layers of evidence
Did the business result improve?
Did the paid funnel stay healthy?
Did user behavior change downstream?
Can I trust the test at all?
Trade-offs
- Gain: more revenue and a usable price range.
- Risk: lower conversion or delayed churn.
- No test: leave demand and revenue unmeasured.
Sanity checks
- Correct prices in treatment
- Correct audience targeting
- Balanced control and treatment
- Revenue and funnel events working
Decision rules
Revenue improves, protected metrics hold, and the setup is valid.
The direction is useful, but the result is mixed or too weak.
Revenue loses, a guardrail breaks, or the implementation is invalid.
After rollout
Check delayed churn, D7/D30 retention, renewals, refunds, and whether the revenue lift holds at full scale. Test other platforms and segments separately.
A revenue result, an early guardrail and a valid setup answer different questions. I used them together to decide how far the evidence justified going.
The smaller move worked
I replaced the broad, aggressive increase with smaller changes by offer. The test moved several prices together: it answered whether to ship the package, not which single price caused the lift.
Moderate increases by offer
- Default · 1 month
- $31.99 +$2
- Default · 3 months
- $44.99 +$5
- New-user offer · 1 week
- $19.99 +$5
- 3-month promotional offer
- $24.99 from $19.99
Roll out to 100% of new male US Android users, then monitor the result at full exposure.
- Revenue increased
- Immediate funnel metrics held
- The setup passed the checks that had invalidated the earlier run
| Role in decision | Metric | Control | Treatment / change | Read |
|---|---|---|---|---|
| Primary | Total revenue | Control | +18%Observed treatment total vs control | Supported rollout |
| Guardrail | VIP D0 conversion | Baseline | +28.6%Reported relative change; small absolute count | Held |
| Guardrail | D0 churn | 19.5% | 19.2%−0.3 percentage points | Held |
| Guardrail | D1 retention | Baseline | +1.6%Weak positive signal | Held |
| Product health | Match rate | ~7.25% | ~7.25%No reported change | Held |
| Product health | Likes sent | Baseline | +8.32%Reported directional support | Supports |
The +18% refers to total revenue, not an identical ARPU lift. Group sizes were similar but not equal. Raw sample revenue, cohort counts, dashboards and confidential thresholds are omitted. The public summary does not establish a confidence interval for the revenue effect.
The recommendation had a defined boundary
The result was strong enough to roll out to the audience we had tested. It was not permission to copy the same prices to every user.
The complete price package, at 100% exposure, with continued monitoring.
Different willingness to pay and funnel behavior can produce a different answer.
Several prices moved together. The package won; attribution inside it remained open.
- Week 1Check delayed harm
Watch churn and confirm tracking stays healthy at full exposure.
- Weeks 2–4Check durability
Confirm that revenue and ARPU hold with a larger population.
- Month 2Check mature behavior
Review D7/D30 retention, renewals, refunds, and conversion at scale.
The next decision depended on what remained unresolved
Several prices changed together. That made the whole package the unit of the decision. The readout did not isolate offer-level effects or establish that cannibalisation had occurred.
The observed early metrics supported the recommendation. Delayed churn, retention and renewal behaviour still needed monitoring after broader exposure.
The configuration failure did not identify a bad price. Fixing and checking the treatment was necessary before another commercial interpretation.
What I would require in the next readout: the intended decision, the assigned population, a fixed observation window, revenue per user as well as totals, and a clear distinction between early signals and mature outcomes. A positive direction would not by itself establish that an important downside had been ruled out.
Read the lessons from the pricing iterations · How I would assess add-on cannibalisation
This was one decision inside a larger experiment portfolio
At DOWN, I personally owned 53 end-to-end A/B tests across monetization, onboarding, and product quality. I used the same discipline — define the decision, protect the downside, verify the run, and carry the learning forward — across the portfolio.
The 18% result above belongs to this pricing test. The approximately 40% result belongs to the broader Android monetization program.
Working on a subscription decision?
I work on pricing, paywalls, onboarding, and conversion systems where the hard part is deciding what to change — and what not to break.