Trials, renewals and the churn nobody chose

The shape of a consumer subscription business

High volume, low price, short cycles and a trial at the front. That combination produces two measurement problems that barely exist in B2B SaaS. First, trials dominate the customer count if you let them, and a tool that counts a trialing user as a customer reports a business you do not have. Second, monthly billing means a payment method is presented twelve times a year, so card failures accumulate into a churn rate that has nothing to do with whether anyone liked the product.

Bastle handles both explicitly. Trials are excluded from MRR by default and reported as their own metric set — conversion rate, trial length, active trials, and which high-value trials expire this week. Failed payments are reported as a distinct cause of churn and handled by Recover rather than folded into the same number as cancellations.

Involuntary churn is where the money is

Expired cards, insufficient funds and issuer declines typically account for a mid-to-high single-digit share of subscription revenue. Those customers were not leaving. Recover treats the three situations that produce them as separate campaigns — a delinquency sequence that starts when a charge fails, a card-expiry warning before anything can fail, and an annual-renewal heads-up before a large charge lands — because a single generic sequence wastes most of the opportunity.

Messages carry a link to a hosted card-update page you can brand, and the new card is written back to your payment processor so the next charge simply works. What happens to outstanding invoices afterwards is a setting, deliberately conservative by default: recovering everything at once collects more and surprises the customer with a total they did not expect.

One honest limitation. Recover's sequences are authored by you, per campaign, in the languages you write them in. Retention specialists that auto-localise dunning across a dozen-plus languages have a real advantage if your base is genuinely international, and it would be misleading to imply otherwise.

The app stores, stated plainly

If your subscriptions are sold through the App Store or Google Play, Bastle connects to both, and both are in beta. It reads auto-renewable subscriptions through the App Store Server API and Play Billing through the Android Publisher API, and applies store commission as a fee so net revenue reflects what the store actually remits rather than the list price.

Beta is not a formality here. These paths have had far less production mileage than Stripe, and store reporting has its own delays and restatements, so plan to check your first month against the store's own reports rather than assuming agreement. If the whole of your revenue is in-app, weigh that against tools built specifically around mobile purchase events, which have been doing only this for longer. The import API remains an alternative if you would rather push the history yourself, and imported sources appear alongside native ones in one set of metrics.

Asking why, at consumer volume

At tens of thousands of subscribers you cannot read the underlying list, so the decomposition has to do the work. Every movement in revenue breaks into new, expansion, reactivation, contraction and churn with the customers behind each, cancellation reasons are weighted by the MRR they cost rather than counted, and saved segments apply across metrics, cohorts and the assistant so you can ask a question about one cohort by name.

Cancellation Insights covers the collection side either through an embeddable widget or by posting reasons from a flow you already built, which matters here because consumer apps usually own their cancellation experience and are not going to replace it.