How to count a free-trial conversion honestly.

A trial you start today converts next week, or next month, or during a billing retry two months from now. Almost every dashboard divides this week's conversions by this week's trial starts anyway — which means the number moves hardest when nothing about your product has changed at all.

The arithmetic that makes growth look like failure

Say you run a one-week free trial and 40% of people who finish it keep paying. Last week 40 people started a trial; this week, after a decent Reddit post, 80 did.

The conversions landing this week belong to last week's cohort: 40 × 40% = 16. Divide those 16 by this week's 80 starts and you report 20%. Your conversion rate appears to have halved, in the same week your funnel doubled. Nothing changed except the size of the denominator you borrowed from the wrong period.

It works in reverse too, which is worse. A week where trial starts collapse makes the ratio spike, so a traffic problem shows up on the dashboard as a conversion win. If you only look at the rate, you will go hunting for what you did right.

Cohort the denominator, then wait

The fix is mechanical: fix the group, not the week. Take everyone who started a trial in a given window — a week is a reasonable unit for indie volumes — give that group an ID, and only ever count conversions back against the cohort that produced them. The question stops being "what converted this week" and becomes "of the 40 people who started on the week of the 14th, how many paid?"

That reframes the reporting problem into a waiting problem, which is the honest version of it. A cohort isn't finished when the trial ends, because both stores keep trying to bill after that:

On Apple's side, a failed renewal puts the subscription into billing retry for up to 60 days, during which Apple keeps attempting the charge and nudging the customer by email, push and an App Store banner. If you also turn on a billing grace period, you pick one of three settings — 3, 16 or 28 days — during which access continues while payment is recovered (weekly subscriptions cap at six days, since the grace period can't outrun the billing period).

Google Play works the same shape with different levers: a declined renewal can enter a grace period with access intact, then account hold with access revoked. The two together must total at least 30 days, and since 1 December 2025 the default is auto-calculated as 60 days minus whatever grace period you set.

So a cohort's trial ends on day 7 and its revenue can still change on day 60. Two numbers beat one here: a provisional read at a fixed, consistent checkpoint — day 14 after the cohort closes, say — and a matured figure once the recovery window is spent. Label which is which on the dashboard. Unlabelled provisional numbers get quoted in investor updates as if they were final.

Cancelled is not the same as expired

A user who cancels on day two of a seven-day trial keeps access until day seven. Nothing about their state changes at the moment of cancellation except one flag: auto-renew goes off. If your "currently trialling" count treats them as live, you're carrying known losses as potential wins for five more days.

Both platforms expose that flag — Apple in the renewal info attached to the subscription status, Google in the subscription's auto-renewing state — and it's the most useful early signal you have. The share of an in-flight cohort still set to auto-renew is a decent forecast of where that cohort lands, available days before the money does. Just don't report it as the conversion rate; it's an estimate of one.

Keep the ineligible out of the denominator

Trials are offers, and offers have eligibility rules. Apple's introductory offers are once per subscription group per account (with Family Sharing complicating it further); on Google Play you define the eligibility criteria yourself, typically new-customer acquisition. A lapsed subscriber who resubscribes usually can't take the trial again — so they show up as a straight paid start with no trial attached.

Fold those into a blended "paid starts" metric and your trial conversion rate drifts upward every time win-backs grow, for reasons that have nothing to do with the trial. Count trial-eligible starts and returning paid starts as separate funnels. They answer different questions.

Refunds split the question in two

A trial that converts and then gets refunded is simultaneously a successful conversion and zero revenue. Both readings are legitimate and they belong to different decisions: conversion rate tells you whether the trial length and onboarding work; net revenue per trial tells you whether the business works. Pick one per chart and say which. A single "trial performance" number that quietly nets out refunds will fall without telling you whether fewer people converted or more people regretted it.

Changing the trial resets the baseline

Apple's preset free-trial durations are 3 days, 1 week, 2 weeks, 1 month, 2 months, 3 months, 6 months and 1 year; Google Play allows anything from 3 days to 3 years. Those are not interchangeable settings with a shared metric. A 3-day cohort and a 1-month cohort differ in how much of the product people saw, how far they are from the decision, and how long you wait to know.

If you change the duration, start the series over. Keep the old cohorts on the chart, cut a visible line at the change, and resist averaging across it. The same goes for price changes and paywall rewrites: every one of them is a new baseline, and the honest chart shows the seam.

At indie volumes, most of the movement is noise

This is the part that saves the most wasted effort. If 20 people finish a trial and 8 pay, that's 40% — but the 95% confidence interval on 8-of-20 runs roughly from 19% to 61%. A cohort at 30% and a cohort at 50% are not telling you anything distinguishable.

To pin a 40%-ish rate to within ±5 points at that confidence you need somewhere around 370 completed trials. If you're seeing 20 a week, that's four months of data for one reliable reading, and the conclusion isn't "measure harder" — it's to stop reacting to weekly wiggles entirely. Make changes big enough to show up over a quarter, judge them on pooled cohorts, and spend the attention you free up on things you can actually observe: where people stop during onboarding, which screen they quit on, what they tell you in support email.

What to actually put on the dashboard

Four columns, one row per weekly cohort: trials started, trials completed, converted (with a provisional/matured label), and net revenue after refunds. A fifth column for the share still set to auto-renew if the cohort is in flight. No single headline percentage, no rolling average that mixes cohort ages, no comparison to a cohort that hasn't matured.

It's a less exciting dashboard than the one with a big number on it, and it has the considerable advantage of being true.

The same discipline applies to anything else you change upstream of the trial. New screenshots or a rewritten subtitle move who arrives at the paywall, not just how many — so a listing change and a trial-conversion change measured in the same week will happily explain each other wrongly. Ship the listing change, mark the date on the chart, and read the cohorts that start after it.