What a price test during a trial can tell you
A trial has more than one price in it. There is the price during the trial, which is free for most products and a small amount for a paid trial, and there is the price the customer moves to when the trial ends. Stripe models these as two separate recurring prices on one trial offer, and its documentation gives a trial of 1 USD for the first week as a typical shape. A pricing test during a trial changes one of those two numbers, or the length of the period between them, and watches what the buyer does next.
The test answers a narrow question: among people who start a trial, does a different price change how many of them pay, and does the revenue per hundred trials go up or down. It does not tell you about people who never started a trial because the page scared them off, unless the price is shown on the page they saw before sign-up and you also count visitors. Decide which of the two questions you are asking before you set anything up.
Choose one variable and write the question down
The common variables are the post-trial monthly price, the trial price (free against a small paid amount), the trial length and the billing interval. Change one per test. If the price and the trial length move together, a difference in paying customers has two possible causes and you cannot separate them afterwards.
- Post-trial price: does a higher monthly price lose more buyers than it earns in revenue per buyer?
- Trial price: does asking for a small payment at sign-up change who starts and who stays?
- Trial length: does a longer or shorter period change the share that pay at the end?
- Interval: does offering a yearly price beside the monthly one change the mix of what people choose?
For the trial price, the ChartMogul conversion report counts trials by type across 200 products and finds a paid trial as the main entry point for 4% of them. The report gives no conversion figure for paid trials alone, so there is no published number to borrow here. If you want to know how a small paid trial behaves for your product, you have to test it.
The revenue arithmetic before you test anything
A higher price wins when the revenue per buyer it adds outweighs the buyers it loses. The price increase calculator shows this for an existing base: at a current price of $49, a new price of $59 and 400 paying accounts with 5% leaving because of it, 380 accounts stay and MRR moves to $22,420 from $19,600, a net change of +$2,820 a month. The break-even share of customers who can leave is 16.9%, which is the old price over the new price, taken away from 1.
The same logic works per cohort of trials. Suppose 100 trials convert at 15% at $49 a month. That is 15 paying accounts and $735 of monthly revenue. The table shows the conversion rate each other price needs just to match that revenue. A price that needs a rate below what you already see is worth testing, and a price that needs a rate above anything you have seen is not.
| Post-trial price | Conversion rate needed to match the revenue | Paying customers per 100 trials |
|---|---|---|
| $39 | 18.8% | 18.8 |
| $49 | 15.0% | 15 |
| $59 | 12.5% | 12.5 |
| $79 | 9.3% | 9.3 |
Read the middle column as a hurdle, not a forecast. At $59 the rate can fall from 15% to 12.5% before monthly revenue per hundred trials drops. Whether it does fall that far is what the test measures. You can try your own numbers in the price increase calculator and the trial conversion rate calculator.
How many trials each price needs
Small differences in conversion are hard to see in a small number of trials. The table uses the normal approximation to the binomial, the method class the NIST handbook derives for a single proportion, extended to two arms: two-sided 5% significance and 80% power, with the trial count in each arm fixed before the test starts. The arithmetic is ours and is easy to check with any sample size calculator that uses the same settings.
| Rate today | Rate you want to detect | Trials in each arm | Trials in total | Time at 100 new trials a week |
|---|---|---|---|---|
| 8% | 10% | 3,213 | 6,426 | 65 weeks |
| 15% | 18% | 2,402 | 4,804 | 49 weeks |
| 30% | 35% | 1,377 | 2,754 | 28 weeks |
| 30% | 40% | 356 | 712 | 8 weeks |
Two things follow. A rate that starts high needs fewer trials to see the same gap in points, so a product with a card required at sign-up can test sooner than one near the 8% median the ChartMogul report gives for free-to-paid conversion across all products. And a gap of a couple of points at a low rate can take most of a year at a modest trial volume. If the table says the test would run for longer than you can hold the page steady, either test a bigger change or use a different method, such as a before and after comparison over matched cohorts, and say plainly that it is weaker evidence.
Running the test in Stripe
Stripe has a few rules that shape how a price test is built. A price amount cannot be edited. To test a new amount you create a new price, and a lookup key can be moved from the old price to the new one so your pricing page code does not change. Existing subscriptions stay on the price they started on. Archiving a price stops it being used for new subscriptions without touching the old ones.
| What you need | How Stripe handles it |
|---|---|
| Change a price amount | Create a new price. The amount on an existing price cannot be changed. |
| Point a pricing page at the new amount | Move a lookup key to the new price with transfer_lookup_key. |
| Keep current subscribers where they are | Existing subscriptions keep their price until you change them. |
| Free or paid introductory price | A trial offer pairs a trial price with a post-trial price and a duration. |
| Change a trial offer's length | Not possible after creation. Create a second offer for the second arm. |
| Free trial by days | Set trial_period_days or trial_end. A trial offer and a free trial period cannot be combined on one subscription. |
Trial offers need a subscription in flexible billing mode, and the free trial period route works with classic or flexible mode. Revenue from items in a trial does not count toward MRR in Stripe's billing analytics while the trial runs, so a dashboard will show a dip in MRR for the arm with the longer or paid-at-zero trial even when nothing is wrong. Compare arms by customers who paid, not by that MRR line.
Assigning arms and reading the result
Assign the arm when the person signs up, by a stable hash of their account id, and store the arm on the Stripe customer or subscription as metadata. Run the arms at the same time. Two prices run in different weeks differ in the traffic, the season and the campaigns as well as in the price.
Decide when a cohort is closed before you look. A trial cohort is not finished when the trial ends, because the first charge can fail and then be retried. Stripe's recommended Smart Retries default is 8 tries within 2 weeks, so a cohort is complete about two weeks after its last trial ends. The ChartMogul report defines free-to-paid conversion as paying within six months of sign-up, which is a longer window than most trial tests can wait, so state the window you used.
Read three numbers for each arm: the share of trials that made a first successful payment, the revenue per hundred trials, and a guard measure such as the share of first charges that failed or the number of support conversations. A price that wins on revenue and doubles failed first charges has moved cost somewhere else.
Mistakes that make a price test mislead
- Counting trial starts as a win. A cheaper or free entry raises starts and says nothing about payers.
- Stopping when one arm is ahead. Decide the trial count first, as in the table, and read the result once.
- Changing the page copy, the offer and the price in the same week.
- Leaving existing customers in the numbers. Only people who signed up during the test belong to it.
- Reading a short-term revenue gain as proof the higher price is right, without watching cancellations over the next few billing cycles.
Questions about pricing tests
Can I test prices if I only get a few trials a month?
You can run it, but the table shows the cost: a gap of a few points needs hundreds or thousands of trials per arm. With a small volume, test a large change, use matched cohorts and treat the answer as a hint.
Should the trial be free or paid in a price test?
That is a separate test. Run it by itself, because a paid trial changes who starts as well as who pays, and the ChartMogul report gives no conversion figure for paid trials to borrow.
Do existing subscribers see the new price?
Not in Stripe unless you move them. Existing subscriptions keep their price, so a test on new sign-ups does not touch them.
How long should I wait before reading the result?
Until the last trial in the cohort has ended and the failed first charges have had their retry window, about two weeks with the recommended retry setting.
Is a bigger price always riskier?
The break-even share tells you how much risk. A rise from $49 to $59 breaks even when about one customer in six leaves, so the question is whether you expect more than that.
Sources
- Stripe documentation, Configure trial offers on subscriptions: https://docs.stripe.com/billing/subscriptions/trials, read 19 Oct 2026.
- Stripe documentation, Compare trial offers and free trial periods: https://docs.stripe.com/billing/subscriptions/trials/compare, read 19 Oct 2026.
- Stripe documentation, Use free trial periods on subscriptions: https://docs.stripe.com/billing/subscriptions/trials/free-trials, read 19 Oct 2026.
- Stripe documentation, Create and manage prices: https://docs.stripe.com/products-prices/manage-prices, read 19 Oct 2026.
- Stripe documentation, Automate payment retries: https://docs.stripe.com/billing/revenue-recovery/smart-retries, read 19 Oct 2026.
- ChartMogul, The SaaS Conversion Report (Kyle Poyar, 4 Feb 2026): https://chartmogul.com/reports/saas-conversion-report/, read 19 Oct 2026.
- NIST/SEMATECH e-Handbook of Statistical Methods, 7.2.4.2 Sample sizes required: https://www.itl.nist.gov/div898/handbook/prc/section2/prc242.htm, read 19 Oct 2026.