In-App Purchase Pricing Experiments That Lift Revenue

Price is the one growth lever that drops straight to the bottom line, yet it is the one most teams set once — by intuition or a competitor glance — and never revisit, which is why pricing is the highest-impact experiment most apps never run. Acquisition costs money to move. Retention takes months to shift. A price change ships in an afternoon and re-rates every transaction that follows it.

The reason teams avoid it is fear: change the number and you might tank conversion, or leave money on the table, or upset existing users. So the price sits frozen while the team A/B tests the colour of the purchase button. That instinct is backwards. The structural choices — what you charge, what you bundle, whether a trial requires a card — move revenue far more than any cosmetic tweak, and they are entirely testable.

The discipline that matters is treating each pricing decision as a hypothesis with a measured outcome, not a one-off bet. You are not guessing the "right" price; you are running a sequence of controlled tests that converge on the price-and-package structure that maximises long-term revenue per user. The teams that win at in-app monetisation are not the ones with the cleverest first guess — they are the ones who test, measure on the right metric, and keep iterating.

There is a second reason pricing is under-tested: the feedback loop feels intimidating because price touches money directly, whereas a creative test feels safe because the worst case is a flat result. But that asymmetry is an illusion. A creative test that wins lifts conversion at the top of the funnel; a pricing test that wins re-rates every rupee that flows through the funnel forever after. The downside of testing price carefully — on new cohorts, with a clear metric — is small and reversible. The downside of never testing it is a permanent, invisible tax on revenue.

Across our 300+ apps managed since 2013, the pattern is consistent: the apps leaving the most money on the table are rarely under-spending on ads. They are charging a price nobody ever tested, packaged the way the founder happened to set it up in year one. Pricing is where a week of structured experimentation routinely beats a quarter of acquisition optimisation.

Your trial structure moves conversion more than your price, your copy, or your creative combined — free-to-paid conversion runs at roughly 2.6% for a no-card freemium trial, 18.2% for an opt-in trial, and 48.8% for an opt-out card-required trial, according to Adapty's trial-conversion data. That is a near-19x spread, driven entirely by how you architect the trial — not by the underlying value of the product.

• Freemium (no card, ~2.6%): the user gets value for free with no payment details captured. The lowest friction to start, and by far the lowest conversion to paid — most users simply never come back to pay.
• Opt-in trial (~18.2%): the user actively chooses a trial. Higher intent than freemium, meaningfully higher conversion, and the model most subscription apps default to.
• Opt-out / card-required trial (~48.8%): the user enters payment details up front and is charged automatically unless they cancel. Fewer people start, but those who do convert at nearly half — the highest-converting structure by a wide margin.

The tension is obvious: requiring a card up front suppresses trial starts but multiplies conversion of the trials you do get. RevenueCat's 2025 State of Subscription Apps sharpens the same point from a different angle — a hard paywall converts at a 10.7% download-to-paid median versus 2.1% for freemium, and longer trials of 17-32 days convert around 42.5% against 25.5% for trials under four days.

The takeaway for an experiment programme is that the trial model is the first thing to test, before you ever touch the price itself. Moving from a no-card freemium flow to an opt-in or card-required trial is a structural change that can multiply paid conversion several times over — a far larger swing than any price tweak will produce. In India specifically, the card-required model collides with low card penetration, which is exactly where a UPI Autopay mandate becomes the local equivalent of the card-on-file trial.

Sometimes it does, sometimes it does not — and there is no clean, reliable industry figure that says "raise your cheapest pack by X and revenue rises by Y," so anyone quoting one is guessing. This is a question you have to answer with your own data, because the outcome depends entirely on how price-sensitive your specific buyers are.

The logic that tempts teams to raise the entry price is sound on the surface. A cheapest pack that is too cheap can anchor the whole catalogue low, train users to expect bargain pricing, and cannibalise the larger packs that carry your margin. Nudge the floor up and, in theory, some buyers trade up, average order value rises, and revenue follows. In theory.

In practice, the cheapest pack is often the gateway purchase — the first time a hesitant user commits any money at all. That first transaction matters disproportionately, because a user who has bought once is directionally far more likely to buy again than one who never has, even though there is no hard, citable percentage on exactly how much more likely. Raise the entry price and you may collect more per first purchase while quietly shrinking the number of users who ever cross that line — and that downstream loss does not show up in the conversion number, only in long-term revenue.

So the honest answer is structural: test it, and judge it on lifetime value rather than the immediate uplift. Run the higher floor against the current floor as a controlled experiment, then watch second-purchase rate and cohort revenue, not just average order value on the first buy. We have run this exact test across apps in our portfolio and seen it land both ways on near-identical catalogues — which is precisely why it has to be measured per app rather than assumed.

There is also a packaging variable hiding inside this question. "Raising the cheapest pack" can mean lifting the price of the existing entry item, or it can mean adding a new, even cheaper entry item below it to capture the most price-sensitive first-timers while the larger packs anchor higher. Those are different experiments with different risks, and conflating them is how teams confuse themselves. If your goal is more first purchases, a lower true floor may serve you better; if your goal is higher average order value from buyers who would have spent anyway, lifting the floor may. Decide which goal you are testing for before you touch the catalogue, because the same price move can be right for one and wrong for the other.

The principle that holds everywhere is that price interacts with purchasing power, so a floor that is "too cheap" in one market is correctly priced in another — the foundation of app price localisation by country.

Price for volume and frequency, not for a high ticket — the India microtransaction sweet spot sits at roughly ₹10-30 per item, and 75% of Indian gamers now pay for in-app purchases, so the winning model is many small, frictionless buys rather than a few expensive ones. The market that fails in India is the one that ports a $4.99 starter pack straight across at ₹400 and wonders why nobody buys.

Two things make the ₹10-30 band work. First, purchasing power: a price that reads as trivial in the US is a real decision in India, and the FX-converted equivalent of a Western pack lands far above what a price-sensitive buyer will spend on impulse. Second, payment rails: UPI makes a ₹20 purchase genuinely frictionless — no card, no stored credentials, a two-tap approval — which is what lets the small-but-frequent model run. The reporting in Outlook's coverage of India's IAP economy and the price-point discussion among PocketGamer.biz's Indian Mavens both point to the same low-ticket, high-frequency pattern.

• Set a true local floor: a ₹10-30 entry item gives a hesitant first-time buyer a near-painless way to commit, which seeds the repeat-purchase behaviour that drives lifetime value.
• Stack value, not price: rather than one ₹400 pack, offer a ladder of small packs so users can buy at the frequency that suits them — the aggregate spend of frequent small buys often beats a rarely-bought large one.
• Lean on UPI for recurring revenue: for subscriptions, a UPI Autopay mandate replaces the card-on-file that India largely does not have, the same way our app subscription monetisation strategy guide frames recurring billing for the market.

This is doubly true for games, where India's enormous, young, mobile-first player base monetises through exactly these microtransactions — the dynamics we cover in depth in gaming app marketing in India. The mistake is treating India as a single discounted version of a Western price sheet; the right move is a purpose-built low-ticket catalogue priced and packaged for how Indians actually pay.

A clean price test changes exactly one variable, splits users randomly into stable cohorts, runs long enough to capture repeat behaviour, and is judged on revenue per user rather than conversion rate — anything looser and you will draw the wrong conclusion with confidence. Most "price tests" that mislead teams fail on one of those four points.

1. Isolate one variable. Test the price, or the pack structure, or the trial model — not two at once. If you change the entry price and the bundle contents together and revenue moves, you have learned nothing about which one did it.
2. Randomise and hold cohorts stable. Assign each new user to control or variant at install and keep them there. Never show the same user two different prices for the same item — beyond the measurement noise it introduces, price inconsistency erodes trust and invites complaints.
3. Pick the right success metric before you start. The metric is ARPU or LTV per cohort, not conversion. A lower price that converts more buyers can still earn less per user, and a higher price that converts fewer can earn more — conversion alone will point you the wrong way.
4. Protect existing buyers. Run price tests on new cohorts. Re-pricing items out from under users who already bought at the old price is the fastest route to refund requests and one-star reviews.

A practical note on platform mechanics: the App Store and Google Play do not give you arbitrary price-experiment tooling the way a web checkout would, so most teams run server-driven paywalls or use a subscription platform's experiment layer to assign variants and read results. Whatever the plumbing, the experimental rigour is the same — one variable, stable cohorts, the right metric, a fair window.

Run a price test for at least one full repeat-purchase or renewal cycle, and until each cohort has enough conversions to be statistically meaningful — for a subscription that usually means weeks, not days, because the number that matters only appears after the first renewal. Calling a test on day-three conversion is the most common way teams ship a price change that loses money.

The reason is that the early signal and the true signal often disagree. A cheaper price wins the first-purchase race almost every time — more people convert, conversion looks great, and the temptation is to ship it. But the revenue question is decided later: do those buyers come back, renew, and spend again? If the cheaper price draws lower-intent buyers who churn before they repeat, the early conversion win reverses into a revenue loss once the renewal cycle plays out. You only see that if you wait for it.

• Cover one renewal cycle minimum. For a monthly subscription, that means running past the first renewal so you can read retained revenue, not just trial starts. Judging before the first renewal is judging half the experiment.
• Reach a real sample. Each cohort needs enough conversions for the difference to be more than noise. Low-traffic apps need longer windows precisely because they accumulate conversions slowly — patience is not optional, it is the test.
• Avoid seasonal contamination. Do not start a test the week of a festival sale or a major marketing push that skews who installs — the cohort you measure has to resemble your normal user.

The cultural fix is to set the decision date and metric before you launch the test, then hold to it. Pre-committing to "we judge cohort LTV after 30 days, not conversion after three" removes the temptation to call an early, flattering, wrong result. Patience is not a nice-to-have in price testing — it is the difference between a measured decision and an expensive guess dressed up as data.

The pricing mistakes that cost the most are the quiet ones — testing pixels instead of structure, judging on conversion instead of LTV, porting Western prices to India, calling tests too early, and never testing at all — because none of them announce themselves as a problem. They simply leave revenue uncollected, month after month, with no error message.

• Testing the skin, not the structure: endlessly A/B testing button colours and headline copy while the price, the packs, and the trial model — the things that actually move revenue — stay frozen. Change the offer architecture first; cosmetics are the last 5%, not the first.
• Optimising for conversion instead of revenue: shipping the variant that converts the most buyers without checking whether it earns the most per user. A cheaper price almost always wins on conversion and frequently loses on revenue — the wrong metric makes the wrong call look like a win.
• Porting Western prices to India: taking a $4.99 pack and listing it at the FX-converted ₹400+ instead of pricing a purpose-built ₹10-30 microtransaction. The result is a catalogue that the market simply will not buy — the exact problem that price localisation solves.
• Calling tests on the early signal: shipping a price after three days of flattering conversion data, before the renewal cycle reveals whether those buyers actually retain. The early winner and the real winner are often different prices.
• Never testing at all: the biggest mistake of the lot — running the price the founder set in year one, forever, because changing it feels risky. The frozen price is almost never the optimal one.

In our portfolio, the single most common finding when we audit a stalled monetisation curve is not a broken funnel or a weak paywall — it is a price that has never once been tested against an alternative. The fix is rarely dramatic: a structured sequence of single-variable tests, judged on LTV over a full cycle, that converges on the right price-and-package structure for the audience you actually have.

If you want a pricing-experiment programme designed and run properly — single-variable tests, LTV-based decisions, India-aware packaging — that is exactly the work our monetisation team does. You can see how we approach growth across our case studies, or talk to us directly about your catalogue.