Trial to paid conversion rate: how to measure it properly

Trial to paid conversion rate looks like the easiest metric in a subscription business: trials that paid, divided by trials. In practice almost every version of it hides a decision, and small differences in those decisions move the number by more than most changes you make to the product. Here are the decisions, in the order you have to make them, with what each one does to the rate.

There are no industry benchmarks in this post. Published figures mix card-upfront and no-card trials, consumer apps and B2B tools, and different denominators. Your own trend, on a fixed definition, is the comparison that holds.

Which trials belong in the denominator?

Group trials by the day they started, not by the day they converted.

The tempting version counts conversions that happened in October and divides by trials that started in October. That mixes two groups of people. Conversions in early October mostly come from September trials, and a trial started on 28 October can't have converted yet. When trial volume is growing, this version understates conversion. When it is shrinking, it overstates it. Neither has anything to do with how well trials convert.

A cohort by start date asks one clear question: of the people who started a trial in this period, how many became paying customers?

What about trials that haven't ended yet?

Leave them out until they resolve.

A running trial is neither a conversion nor a loss. If you count it as a non-conversion, the most recent cohort always looks bad, and every dashboard built that way shows conversion "falling" in the current month.

Excluding running trials has its own bias in the other direction. People who pay early, on day three of a fourteen-day trial, are already in the numerator, while the undecided ones are out of the denominator. So a young cohort's rate tends to start high and settle as its trials end. Treat a cohort as final only once every trial in it has ended, and until then show the rate next to the number of trials still running.

Here is the calculation as SQL, assuming a trials table with a start, a scheduled end and the date of the first successful payment:

select
  date_trunc('month', started_at) as cohort,
  count(*) as started,
  count(*) filter (where ends_at > now() and converted_at is null) as still_running,
  count(*) filter (where converted_at is not null) as converted,
  round(
    100.0 * count(*) filter (where converted_at is not null)
    / nullif(count(*) filter (where converted_at is not null or ends_at <= now()), 0),
    1
  ) as rate_pct
from trials
group by 1
order by 1;

What counts as converted?

A first successful payment after the trial, not a subscription status.

With a card on file, a subscription can leave its trial state before the first charge goes through, and a declined card at trial end is not a new customer. Look for a paid invoice.

Then decide what to do about refunds. If someone pays, asks for their money back two days later and cancels, counting them as converted flatters the rate. A simple rule is to treat a full refund within a short window as not converted. The exact window matters less than writing it down and keeping it.

Do card-upfront and no-card trials measure the same thing?

No. They measure different behaviours, and the rates are not comparable.

A card-upfront rate is partly a measure of who didn't cancel. A no-card rate is a measure of who actively chose to pay. If you switch from one to the other, the trial-to-paid rate will jump or crash and that tells you very little. Start a new series at the switch date.

The number that survives the switch is one step earlier: paying customers divided by signups, or by visitors who reached the pricing page. It shows whether the change brought you more customers overall, which is what you wanted to know.

With card-upfront trials, it is also worth watching the second payment. Customers who converted by forgetting to cancel tend to show up as cancellations or refund requests right after the first charge.

On Stripe, a no-card trial ends according to trial_settings.end_behavior.missing_payment_method: the subscription is canceled, paused, or an invoice is created. Whichever you use, your conversion query has to treat each outcome the same way every time.

How do mobile trials and intro offers fit in?

App Store and Google Play subscriptions add a wrinkle. A free trial there is one kind of introductory offer. Other intro offers are discounted paid periods: a cheap first month, or a reduced price paid up front for several months.

RevenueCat events carry a period type that separates trial, intro and normal periods, which lets you handle each one deliberately:

• Free trials follow the same rules as web trials. Cohort by start, wait for the trial to end, count a conversion at the first paid renewal.
• Paid intro offers are paid from day one, so they are not trials. The rate worth tracking is intro to full price: of the people who started on the discounted period, how many renewed at the regular price.

Store trials are opt-out: the subscription renews into a paid period unless the person cancels in their device settings. In that sense they behave more like card-upfront web trials than no-card ones, which is one more reason not to merge web and mobile into a single conversion rate. Report them per source. If you bill both ways, the setup in combined MRR for Stripe and RevenueCat covers how to keep customers and subscriptions from being double counted.

Does conversion differ by acquisition channel?

Usually, and that is one of the more useful things this metric can tell you. Someone who found you through a search for the exact problem you solve arrives with a different intent from someone who clicked a launch-day post out of curiosity.

To split conversion by channel, you need the first touch saved with each signup: landing page, referrer and UTM parameters, recorded on the first visit and carried through to the account. Then group your trial cohort by that channel. Keep an explicit "unattributed" group for trials with no first touch instead of dropping them, or every channel's rate will be computed on a different subset of your trials. The choice between first and last touch changes which channel gets credit. The post on first-touch vs last-touch attribution goes into that.

How many trials before the rate means anything?

More than most small products get in a month per channel.

With small samples, a single conversion moves the rate a lot. The size of that move is easy to compute: one conversion is 1 ÷ n of the finished trials.

So if a channel with 12 finished trials converts at 25% and another with 15 converts at 33%, those are three conversions and five conversions. That is not a finding.

A few habits help:

• Pool time. Look at channel conversion per quarter, not per month, until volumes grow.
• Ignore small gaps. Don't act on a difference smaller than what two or three extra conversions would produce in the smaller group.
• Show the counts. Always put "5 of 15" next to "33%". The fraction carries the uncertainty the percentage hides.
• Compare to yourself. The same definition, the same trial setup, over time.

Writing it down

The definition that comes out of these decisions fits in one sentence: trials grouped by start date, running trials excluded until they end, converted meaning a first successful payment not fully refunded within N days, reported separately for web and each app store.

That is close to how Joinsight defines it: the share of trials started in a period that became paid, with trials still running left out until they end. Through the MCP server, the overview returns trials started, converted and still in trial side by side, so the provisional part of a young cohort stays visible. The full wording is on the metric definitions page.