Mike Kamaev
Menu
DOWN · Dating app · Android pricing

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
The problem

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 $400 after a 60% 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.

Iteration

I used each loss to change the next test

The tests failed for different reasons. That mattered: each reason required a different next move.

  1. 01 · Stop VIP conversion fell 23.8%

    The increase crossed the segment’s tolerance. I stopped instead of explaining the loss away.

    Next changeUse a smaller price step.
  2. 02 · Stop Revenue fell by $400

    The three-month offer had jumped 60%. More revenue per buyer did not offset fewer buyers.

    Next changeAdjust prices by offer, not with one blunt increase.
  3. 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.
  4. 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.
My experiment document

Before launch, I wrote down how we would decide

This is the public version of the experiment brief I used at DOWN. It kept the business goal, user risk, test setup, and ship decision in one place — before anyone saw the result.

Experiment brief

Pricing · New male users · Android · US

Final decision · Ship
Owner
Mike Kamaev
Scope
One platform, gender, market, and user cohort
Options
Ship · Iterate · Stop
Template standard
Metrics, thresholds, duration, and QA locked before launch
01

Goal and non-goal

Goal: increase total revenue and ARPU.

Not the goal: maximize price at any cost.

02

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.
03

Four layers of evidence

PrimaryRevenue · ARPU

Did the business result improve?

GuardrailsVIP CR · churn · retention

Did the paid funnel stay healthy?

Product healthMatch rate · likes sent

Did user behavior change downstream?

ValidityConfig · targeting · split · tracking

Can I trust the test at all?

04

Trade-offs

  • Gain: more revenue and a usable price range.
  • Risk: lower conversion or delayed churn.
  • No test: leave demand and revenue unmeasured.
05

Sanity checks

  • Correct prices in treatment
  • Correct audience targeting
  • Balanced control and treatment
  • Revenue and funnel events working
06

Decision rules

Ship

Revenue improves, protected metrics hold, and the setup is valid.

Iterate

The direction is useful, but the result is mixed or too weak.

Stop

Revenue loses, a guardrail breaks, or the implementation is invalid.

07

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.

DefineAlignBuildQAReadDecideMonitor

Revenue had to win. Conversion and churn had to hold. Match behavior had to stay healthy. And if the setup was wrong, I threw the result away.

The final test

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.

Winning treatment

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
Recommendation Ship

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 $2,084 $2,464+$380 · +18% Win
Guardrail VIP D0 conversion Baseline +28.6%Reported significant; 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 significant Supports
Validity Cohort size 620 638Balanced allocation Pass

Full dashboards, confidential thresholds, and raw user-level data are omitted from this public case.

The decision

I shipped the segment, not a universal price

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.

What I shipped New male users · US · Android

The complete price package, at 100% exposure, with continued monitoring.

What still needed testing iOS, women, existing users, other markets

Different willingness to pay and funnel behavior can produce a different answer.

What the test could not isolate The effect of each individual offer

Several prices moved together. The package won; attribution inside it remained open.

  1. Week 1Check delayed harm

    Watch churn and confirm tracking stays healthy at full exposure.

  2. Weeks 2–4Check durability

    Confirm that revenue and ARPU hold with a larger population.

  3. Month 2Check mature behavior

    Review D7/D30 retention, renewals, refunds, and conversion at scale.

The broader system

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.

Ownership53A/B tests owned from brief through decision
Portfolio quality43%Win rate across monetization, onboarding, and product quality
Android monetization~+40%Revenue growth across multiple pricing, paywall, and offer experiments

The 18% result above belongs to this pricing test. The approximately 40% result belongs to the broader Android monetization program.

Growth product work

Need someone who can own the decision, not just run the test?

I work on pricing, paywalls, onboarding, and conversion systems where the hard part is deciding what to change — and what not to break.

See the B2C Monetization Sprint