When a Free Trial Ends Without a Sale

The Day After the Trial Is Not Day One

On day one, the person is deciding whether your app is any good. They have no evidence, so the paywall has to promise. On day eight, they have evidence. They know what the product does, which parts they used, and which parts they never opened. The question in their head has changed from “is this worth trying” to something much more specific: “is what I actually did with this worth the price of it”.

A paywall written for the first question does not answer the second. It is not a timing problem or a creative problem — it is the wrong argument, delivered at the one moment when the person is best equipped to notice.

A lapsed trial user is not an unconvinced stranger. They are a qualified prospect who has already told you which parts of your product they care about.

How Long the Second Pitch Stays Open

Teams usually pick a round number of days, because days are easy to reason about. The better unit is sessions, because that is what you are actually spending. A recovery offer costs you one opening of the app — and you only get a handful of those before the person stops coming back at all.

How wide the window should be depends on how often your product is meant to be used. A daily habit app can make its case in two or three returns, all inside a week. A tool people reach for monthly — taxes, travel, moving house — has a window measured in cycles, not days, and a seven-day cutoff silently discards almost everyone worth recovering.

Decide the shape before the number: do you want one pitch per return until the person converts or stops returning, or one pitch early and one sharper pitch later? The second shape is usually right, and it forces you to answer the question in the next section twice.

Why the Same Offer Twice Is the Default Mistake

Showing the same screen again is the path of least resistance, and it has an honest defence: maybe they were busy the first time. Sometimes that is true. But a trial that ended without a sale produced information, and repeating the first pitch is a decision to ignore it.

So ask what the trial told you, and change the thing it pointed at:

• Someone who used the product hard every day and still did not pay has a price objection.
• Someone who stopped on the second screen has a setup objection, and a cheaper price does nothing for it.
• Someone who used one feature out of eight has a scope objection: they are being asked to buy seven things they never touched.

Those are three different conversations. The reflex — a discount on the same plan — is only the right answer to the first one.

Designing the Recovery Offer

Four shapes, roughly in the order most teams should consider them:

• A shorter commitment. The person liked the product and balked at twelve months. Monthly, or a quarter, is not a discount — it is a smaller decision.
• A narrower product. They used two of your eight features. A cheaper tier that contains exactly those two is a better answer than a discount on all eight.
• More time, with a condition. Someone who never finished setting the product up never evaluated it. Extra days only help if you also fix the thing that stalled them.
• A discount, last. A discount answers one objection — price. Reach for it when the trial data says people got value and still did not pay.

Whichever you pick, the screen has to name the thing that just happened. “Your trial ended” is not an awkward admission; it is the only sentence that explains why this offer looks different from the last one. A recovery screen that pretends to be a first visit reads as a bug.

One constraint from engineering, worth knowing before you design anything: whatever screen you choose has to already exist in a released build. Switching between screens later is cheap; inventing a new one is a release. If the recovery offer needs its own layout, that layout ships with the version that turns this on.

Knowing When to Stop Asking

Every recovery programme needs an end, decided in advance. Two pitches and then silence is a defensible default: one when they come back, one sharper one later, then nothing.

The reason to be strict is that the downside is not symmetric. A missed recovery costs you a subscription you never had. An over-asked user costs you the app on their phone, and sometimes a one-star review on the way out. Treat a dismissal as an answer rather than a non-response, and let people who said no twice simply use the free product in peace.

Build the stop condition into the plan, not into a later clean-up ticket. The moment someone subscribes, the recovery flow has to disappear for them — an offer shown to an existing subscriber is worse than no offer at all, because it tells them there was a better price available.

Reading the Numbers When They Disagree

Conversion on the recovery screen is the number everyone looks at, and on its own it can send you the wrong way. Three combinations worth naming before you start, so you are not interpreting them under pressure:

• Conversion up, retention down. You sold the wrong plan to the right person. Compare how long recovered subscribers stay against people who paid in their first week.
• Conversion up, refunds up. The offer out-argued the product. A refund is a stronger signal than a cancellation, because the person bothered to ask for it.
• Nothing moves at all. Check how many lapsed users ever open the app again. If almost none do, no in-app offer can reach them, and the problem belongs to a channel that can.

The last one is the useful one, because it tells you to stop working on the offer. An in-app recovery flow can only reach somebody who opens the app. Amply notices that the trial has lapsed and routes that session somewhere other than the default paywall; it does not send push or email, it does not render the screen, and it never touches billing. Your app draws the paywall and your store handles the money — which also means the lapse itself is something your app has to tell Amply about.

That hand-off is where the strategy stops and the configuration starts: the post-trial recovery campaign, configured walks through the conditions, the caps and the attributes your app has to write.