How do you run a pricing experiment safely?

A pricing experiment done wrong can get your app removed from the App Store, expose you to legal risk, or permanently damage customer trust. Done right, it's the highest-leverage lever you have for revenue growth. The key is separating what you're allowed to test from what will get you in trouble, and designing experiments that produce clean, actionable data.

Understand the boundaries before you touch a price

Most founders think pricing experimentation is simple: show group A one price, group B another, measure conversion. But if you're building a mobile app, you're operating inside a platform with explicit rules about what you can change remotely and what you can't. Rik Haandrikman's breakdown of Apple's remote testing guidelines draws a clear line: you can change data—prices, copy, paywall layouts, onboarding flows—but you cannot change code behavior, swap in external payment processors on the fly, or detect when Apple reviewers are watching and behave differently.

The practical implication: your pricing experiments must live inside the binary Apple reviewed. That means your paywall can dynamically display different prices fetched from a remote config, but you cannot route users to a Stripe checkout page as a substitute for in-app purchase, and you cannot download new executable logic to handle payments. Tools like RevenueCat's remote paywall configuration exist precisely to give you this flexibility within the rules. Before you design any experiment, map out whether each variable you want to test is a data change or a behavior change. If it's the latter, you need a different approach.

On web and non-Apple platforms, the constraints are different but not absent. You still need to avoid showing materially different prices to different users in ways that could be construed as discriminatory pricing under consumer protection law in some jurisdictions. The safest framing is always: you're testing presentation and packaging, not hiding information or deceiving any customer segment.

Design the experiment before you set prices

The most common pricing experiment mistake is launching with two prices and no hypothesis. If you don't know what you're testing for, you won't know what the result means. A well-designed pricing experiment starts with a specific, falsifiable claim: 'We believe annual plans convert better at $79 than $99 because our user research shows price sensitivity above $80.' That's testable. 'Let's try a few prices and see what happens' is not.

Next, decide what you're actually varying. Pricing experiments often conflate multiple variables—price point, billing frequency, feature packaging, and anchoring—all at once. Isolate one variable per experiment. If you're testing whether $9.99 vs. $12.99 changes conversion on your monthly plan, don't also change the feature list or the paywall copy at the same time. You won't know which change drove the result.

Determine your sample size and runtime before you start, not after. The temptation to call a winner early when one variant looks good is one of the most common ways founders generate false confidence from pricing tests. Use a statistical power calculator: plug in your baseline conversion rate, the minimum effect size you actually care about (e.g., a 15% lift in revenue per visitor), and your desired confidence level. This tells you how many users you need in each arm before the result is meaningful. If your traffic is low, you may need to run the experiment for weeks. That's fine—what's not fine is stopping after 200 sessions because one price 'looks like it's winning.'

Protect revenue and relationships during the test

A pricing experiment is not a reason to charge some customers more than others for identical value in a way they'd find unfair if they discovered it. The psychological contract with your users matters. The safest approach is to randomize by session or device ID at the paywall, not by user account, and to never show different prices to users who are actively comparing notes—which is a real risk in communities, Slack groups, and Twitter threads where your users talk to each other.

Build a rollback path before you launch. If variant B is converting at half the rate of your control, you need to be able to kill it without a deploy. This is where remote configuration earns its keep: the kill switch should take under five minutes to trigger, not require a hotfix, review, and release cycle. Define in advance what a 'bad result' looks like and automate an alert if you hit that threshold—a 30% drop in conversion rate within 48 hours, for example, should trigger a Slack notification and a pause on the experiment.

Also: grandfathering matters. Any user who subscribed under a price during your experiment period deserves that price on renewal, unless you've explicitly communicated a change. Failing to grandfather is both a trust issue and, in subscription businesses, a churn risk that can dwarf whatever revenue lift you captured from the higher price.

Use Apple's anti-steering ruling as a new lever, carefully

The post-Epic ruling landscape opens up a meaningful new dimension for iOS pricing experiments: you can now direct users to web checkout as a genuine alternative, not just a backup. Haandrikman's analysis of this ruling highlights that web purchases give you something IAP never could—full attribution data. When a user clicks through to your web checkout page, you can instrument the entire funnel with analytics, connect it to your ad campaigns, and actually know whether that paid acquisition converted to revenue.

This creates a legitimate pricing experiment structure: test whether offering a discount exclusive to web checkout (e.g., 'Save 20% when you subscribe on the web') produces enough lift in total conversions to offset the friction of leaving the app. The experiment variable here is the price differential and the messaging, not anything that violates platform rules. But execute this carefully: the messaging must be clear, the web flow must be genuinely functional and trustworthy, and you need to coordinate between marketing and product so the experience isn't confusing. A user who clicks a 'save 20%' link and lands on a broken or unfamiliar checkout flow will abandon and distrust you more than they would have if you'd never offered the option.

The data advantage from web checkout attribution—knowing which ad channel drove a purchase, being able to re-engage via email—compounds over time. If your pricing experiments reveal that web-checkout users have meaningfully higher LTV, that changes your entire customer acquisition strategy, not just your paywall.

Read results honestly and act on them

When your experiment concludes, the primary metric is revenue per visitor, not conversion rate alone. A price increase will almost always lower conversion rate; the question is whether it raises revenue. Calculate: (conversion rate) × (price) × (estimated LTV multiplier for retention at that price point). A 10% drop in conversion paired with a 25% price increase is a net win—unless churn at the higher price erodes LTV enough to negate the difference, which is a lagging signal you need to track separately.

Report the full result internally, including confidence intervals, not just the point estimate. A result that shows 'variant B generated 18% more revenue' with a wide confidence interval that includes zero is not a result you should ship. It's a result that tells you to run the experiment longer or with a larger audience. Founders who only report wins from pricing experiments create a false sense of progress; the null results are equally important because they tell you where price sensitivity actually lives.

Finally, treat each pricing experiment as an input into a model, not a one-time answer. Your optimal price today is not your optimal price in twelve months. As your product adds value, as your brand becomes more recognized, as your market matures, willingness to pay shifts. Build a rhythm of testing—quarterly for fast-growing products, semi-annually for stable ones—and maintain a log of every experiment you've run, the hypothesis, the result, and the confidence level. That log becomes a strategic asset: a map of where your pricing power actually comes from.

“Apple permits remote testing that changes data, not code.”

— Rik Haandrikman, source

The one thing to do

Define your hypothesis, sample size, and kill-switch conditions before you change a single price—experiments designed after launch produce noise, not insight.

Frequently asked questions

Can I show different prices to different users on iOS?

Yes, as long as the prices are fetched remotely as data and your app handles IAP through Apple's approved system. You cannot swap in an external payment processor or download new payment logic. Use a remote configuration tool and test paywall variants, not payment mechanics.

How long should a pricing experiment run?

Long enough to reach your pre-calculated sample size at the specified confidence level—never stop early because one variant 'looks like it's winning.' For most early-stage apps with modest traffic, this means weeks, not days.

What's the difference between a pricing experiment and price discrimination?

A pricing experiment tests which price point or package maximizes revenue across a randomly assigned population. Discriminatory pricing targets specific demographic groups with systematically higher prices for identical value, which can violate consumer protection law in many jurisdictions and is not what you're doing.

What should I do if my pricing experiment shows no significant result?

A null result is valid data—it tells you price is not the primary lever in that range, and you should look at packaging, feature value, or positioning instead. Document it, don't re-run it hoping for a different outcome, and move to testing a different variable.

Sources

More playbook answers · Growth Prophet home