Paywall and Trigger Economics for Subscription Apps

Redesigning a paywall screen has moved trial starts between 6 and 19 percent across the fourteen subscription apps we have taken through this work. Moving the moment the paywall fires - out of onboarding and into the first completed search, the first saved listing, the first employer reply - moved day-60 paid retention by more than twice that, in both directions. So we start with the trigger and treat the screen itself as the cheap part. What we read before we touch anything: Ninety days of subscription events from RevenueCat or Adapty, App Store Connect and Play Console subscription reports side by side with them, and your product event stream in Amplitude, Mixpanel or BigQuery. We rebuild cohort revenue by trigger point rather than by screen variant, because the same paywall in front of two different intents is two different products. If the app produces fewer than roughly 400 trial starts a month, we will tell you a test cannot settle inside six weeks and propose a round of session recordings and cancellation interviews instead. The levers we work on, in order: Where the paywall fires and how deep the free path runs before it does. What the paid tier promises at that exact moment, written fresh rather than lifted from the App Store description. Price and term structure: annual anchoring, introductory offers, Apple win-back offers and offer codes, Play base plans and offer phases. Then the cancellation path, which is where Play's pause option and App Store retention offers usually recover more than any acquisition change we could make in the same quarter. How the testing runs: One lever at a time, sequentially, two to four tests a quarter. Each is powered to detect a 10 percent relative change and read on day-30 paid conversion and day-90 revenue per install, never on trial start alone. We write the stopping rule before the test starts and we publish the losers to you with the same detail as the winners. Native A/B through App Store Connect Product Page Optimization and Play Store listing experiments where the change is store-side; in-app through your own flag system, not a third-party paywall SDK we would have to hand you as a dependency. What we will not do: We do not produce twenty paywall variants for a workshop. Volume of variants is what a team reaches for when it has not decided what it believes. We do not build pre-selected annual plans with obscured trial terms, blocked back buttons, or countdown timers that reset. Those win the test, then arrive later as refunds, one-star reviews and an App Review rejection, and we would rather lose the pitch. We do not gate the supply side of a two-sided app behind a paywall without a hard argument for it, because thinning supply to bill it is usually the most expensive euro a marketplace ever earns. We do not touch pricing in a market where you have not checked local payment method coverage first. Who should not hire us for this: Habit apps - meditation, fitness, streak-based language learning. Their economics run on daily reactivation and our judgement there is no better than your own. Apps before launch, with no cohort to read. Teams who want the paywall fixed while the activation funnel underneath it is broken; in that case the honest sequence is activation first, and we will say so in the first call rather than take the engagement. What you receive: A written trigger map with revenue per cohort attached to each candidate point, the rewritten offer copy in English and Dutch, a test plan with stopping rules, and a decision memo per test that says what we now believe and what we would change next. Implementation sits with your engineers; we specify, review the build and read the result.