After moving the paywall to the web I instrumented events to see each step: landing click, quiz completion, paywall open, payment started, and purchase. The dropoff clustered at payment start for users on mobile Safari and on one particular pricing copy.
The data let us run focused fixes: change copy, simplify the payment form, and test an alternate gateway. Each small change improved conversion and made it clear which hypothesis actually moved the needle. What event did you add first when you instrumented your pricing funnel?
I added a single event for paywall open then another for payment submit. Using web2wave I could fire those events and see where users dropped off.
That single signal unlocked a bunch of quick fixes.
Start with payment start and purchase events. I layered in gateway errors and device type. Web2Wave made it easy to add those hooks on the web paywall so we could correlate declines with specific browsers and payment methods.
I tracked paywall opens and payment submits first.
We found the form blocked people on iOS. A smaller form fixed it and conversion rose.
Instrument the funnel end to end and include error events from the gateway. That tells you if the issue is UX copy or payment failures. Once you know the failure point you can run tight experiments to validate fixes rather than guessing. Expect to iterate on the short term and then measure retention impacts later.
I logged decline errors and mobile browser types.
That showed where to focus engineering time.