The old question is too small
I wrote Pricing Experiments, published March 1, 2024, after looking at the top 100 grossing apps and how their prices changed over a six-month period. The issue reported an average price increase of roughly 27%, about 20% of apps testing an increase, roughly a third of tests pushing harder toward annual plans, and about 10% of tracked experiments failing. Those are the issue’s historical observations, not a benchmark for your next paywall.
The useful lesson is earlier in the process. Before choosing a number, decide what the test is supposed to move: monthly versus annual selection, free-to-paid conversion, revenue per payer, refund risk, or the customer’s willingness to commit. A test that changes three of those at once will give you a result and no explanation.
Write the decision before the treatment
If you raise the monthly price while leaving the annual price close to the old ten-month ratio, you are testing a commitment nudge. If you raise both prices by the same percentage, you are testing willingness to pay. If you add a lifetime plan, you are testing whether some customers want to trade recurring uncertainty for a single payment. Those are different decisions wearing the same “pricing test” label.
Write one sentence before shipping: “We expect this change to make [customer segment] choose [plan/action] because [reason].” Then keep the rest of the page stable enough that you can read the answer. The source issue’s annual-plan examples are useful because the plan mix was part of the design, not an accidental side effect.
Treat failure as a result
The original issue explicitly said that not every pricing experiment won. That line is more valuable than the average increase. A failed price change tells you that the price, the packaging, the promise, or the audience was wrong for the moment. It does not tell you to keep iterating until a higher number produces a screenshot you like.
Set the stop conditions before launch. What would make you roll back? What movement in annual share would pay for a conversion decline? Which customer segment gets protected? If you cannot answer those questions, you are running a page change, not a pricing experiment.
A five-question pricing review
I would ask:
- Which customer decision is this test trying to change?
- Which unit is primary: revenue per visitor, payer conversion, revenue per payer, annual share, or retention?
- What tradeoff would make the test a win?
- What segment or existing customer promise needs protection?
- What result would make us stop, roll back, or run a different test?
The takeaway
Price tests become useful when they are built around a customer decision and a named tradeoff. The number is the treatment; the decision is the experiment.
Sources and original research
Adapted from my original Pricing Experiments, published March 1, 2024. The top-100-app observations and percentages are historical source reporting; this adaptation turns them into a test-design checklist and adds no current pricing benchmark or new experiment.
Updated September 21, 2026. Based on original First 1000 reporting and the sources listed above.