A conversation about paywall and growth strategy with Jonathan Parra (known as 'The Paywall Guy'), who has designed over 4,700 paywall experiments for consumer apps, previously at Superwall and now running Tapas Growth. Topics include whether teams optimize too early, a 4-part experimentation framework, tracking the right metrics, how quickly results appear after a paywall experiment, paywall touchpoints, how the same offer can produce opposite outcomes, and a paywall approach he won't recommend. Serves as a companion to a previous paywall episode. # Video Identity Observations: "He Tested 4,700 Paywalls. These Won." ## Channel Audience ### Primary audience: app founders and subscription-app operators - The transcript repeatedly addresses people building mobile apps with paywalls: *"most founders are optimizing the wrong thing"* — explicitly naming **founders** as the target audience. - Advice assumes a mobile subscription business context: paywall placements, onboarding flows, App Store metrics (D1/D7/D30, trial-to-paid, LTV, ARPU, churn), and **Mobbin** as a reference point (*"78% of iOS apps on Mobbin show the paywall after onboarding"*). - Segments the audience further into builders vs. operators: *"If you're vibe coding an app… you're going to be focusing on ARPU… But, if you're building like a long-term business… optimize for LTV and retention."* This acknowledges an audience that includes both hobbyist/indie builders and serious subscription businesses. ## Claimed Scope ### Topic scope: paywall optimization and subscription app growth - The framing sentence defines the episode's scope: *"we are unpacking the biggest growth lessons from thousands of paywall experiments."* - Covers a specific practice area in depth: paywall design testing, personalization, price packaging, paywall touch points (onboarding, cancel-flow, win-back, delete-intent), metrics selection, and discounting strategy. ### Scope framed as expert-sourced, not self-promotional - The channel's authority claim comes from the guest: *"I spoke to someone who's designed 4,700 paywalls."* - The host's role is interviewer/curator — visible in recurring framing questions (*"How important is paywall optimization?"*, *"What's a paywall best practice you completely disagree with?"*) and in the closing synthesis: *"Jonathan kept coming back to the same question. What kind of business are you trying to build?"* ## Self-Description Evidence ### No explicit channel self-description is present - The transcript contains no statements like "on this channel we…" or channel mission statements. The only near self-reference is *"today, we are unpacking…"*, which describes the episode rather than the channel's identity. ### Demonstrated (not claimed) channel patterns - **Expert-interview format**: host questions structure the conversation; a named guest ("Jonathan") provides the expertise. - **Editorial synthesis**: the host closes with a takeaway framing (*"Neither of these are right or wrong, but they're very different games"*). - **End-screen funneling**: *"Next up, watch this paywall video…"* indicates the channel maintains a topical series/playlist around paywalls and app monetization — evidence of a niche content vertical, though only demonstrated for this single video. ## Summary | Dimension | Evidence | |---|---| | Intended audience | App founders / subscription-app operators ("most founders are optimizing the wrong thing") | | Claimed scope | Growth lessons from thousands of paywall experiments | | Format evidence | Host-interview with practitioner guest, closing editorial synthesis | | Explicit channel self-description | None present in this video | # Delivery Observation — "He Tested 4,700 Paywalls. These Won." ## Format The video alternates between a **host framing the topic** and a **guest (identified as Jonathan near the end) answering interview questions**. Host lines serve as transitions and conclusions: > "So today, we are unpacking the biggest growth lessons from thousands of paywall experiments and why most founders are optimizing the wrong thing." > "Throughout this conversation, Jonathan kept coming back to the same question. What kind of business are you trying to build?" ## Guest Vocabulary & Framing - **Metric and funnel jargon used fluently and densely:** "ARPU as my North Star metric," "trial to paid conversion rate, LTV, D1, D7, D30, churn," "statistically significant win," "cognitive load." - **"Moves the needle"** appears repeatedly as the test of an experiment's value: > "Design tests move the needle the most." > "After design, personalization moves the needle the most." > "It incrementally gets smaller and smaller in what moves the needle." - **"Honestly"** is a recurring softener before blunt claims: > "As a starting point, it's honestly not that important." > "For your first paywall, honestly, all that you need to do is..." ## Teaching Habits - **Enumerated hierarchy as a teaching device.** The guest sequences tactics by impact: design → personalization → price packaging → device-based testing, framing each step as a smaller lever: > "But, that's like one of the last levers that you really pull because it's so much work." - **Concrete numeric thresholds to make advice actionable:** > "If it's above 80%, you're doing good. If it's 90% or above, you're crushing." - **Contrastive scenarios to teach tradeoffs** — same tactic, different business goal: > "If you're vibe coding an app... you're going to be focusing on ARPU as the key metric. But, if you're building like a long-term business... then optimize for LTV and retention." - **Direct debunking of beginner over-engineering:** > "I get in calls with some people that think they need to do all these crazy optimizations... You really don't." - **Candid uncertainty when the evidence doesn't support a clean answer:** > "That you have to test actually because I have tested it multiple times and I still have inconclusive results." ## Host Communication Patterns - The host inserts **statistical asides** mid-conversation: "In fact, 78% of iOS apps on Mobbin show the paywall after onboarding." - The host **closes with a synthesized takeaway and a next-video hook**, framing the guest's central theme as "they're very different games." ## Tone - Conversational and pragmatic; hard truths delivered with softeners or resigned framing: > "Unfortunately, it works." - Repetition of **"long-term game" / "long-term business"** as the moral of the discussion. ## Uncertainty This is a single video; "honestly," "moves the needle," and the ARPU-vs-LTV framing recur within it but may reflect interview-topic steering rather than stable habits across the speaker's body of work. One-off moments (the iPhone 17 Pro / low-battery-mode pricing example, "you're crushing") are vivid but not verifiable as recurring patterns. # Observation Record — "He Tested 4,700 Paywalls. These Won." ## Speakers - **Host (unnamed)** — interviewer; poses questions, delivers closing synthesis. - **Jonathan (guest)** — the person described as having "designed 4,700 paywalls"; identified by name only in the host's closing line ("Throughout this conversation, Jonathan kept coming back…"). > The transcript does not name the host; speaker attribution for the guest rests on the closing mention of "Jonathan," and turn-taking structure (question/answer alternation). --- ## Claims and Reasoning — Jonathan ### 1. Paywall optimization is not the first priority - "As a starting point, it's honestly not that important." - For a **first paywall**, all that's needed is: a headline describing the product, a couple of bullet points, and a continue button. - Founders who think they need "crazy optimizations" for placements and paywalls early on are mistaken; the priority is "getting users into your app first," optimizing traffic later. ### 2. Testing priority hierarchy (in order of impact) 1. **Design tests** — "move the needle the most." Try radically different designs: video paywall, bullet-list paywall, trial timeline paywall, long-form paywall. 2. **Personalization** — name callouts, highlighting user goals; e.g., a fitness app showing imagery matching the user's identity ("strong man on the paywall"). 3. **Price packaging design** — vertical vs. horizontal product groups, footer design, weekly vs. real-price presentation. 4. **Device-based price testing** — explicitly flagged as "one of the last levers" because "it's so much work"; impact "incrementally gets smaller and smaller." ### 3. Product packaging guidance - Default to a **yearly product** ("we see that that has the highest LTV"), and show only **two options** to "decrease cognitive load." - Qualification preserved: "a yearly product may not be the best for your business." ### 4. Device-based price discrimination - Example given: iPhone 17 Pro on 5G, no low battery mode → show higher price; iPhone 13 Pro on 3G, low battery indicator active → lower price. ### 5. Metrics depend on the business - "That depends entirely on the business." - He "used to use ARPU as my North Star metric," but it "doesn't necessarily give you all the answers": a $3–4 ARPU may come from weekly products with **90–95% monthly churn**. - Metrics he tracks: **paywall percentage** (>80% of installs viewing paywall is good; ≥90% is "crushing"), trial-to-paid conversion, LTV, D1/D7/D30, churn. - Metric by business type: - Vibe-coded, growth-focused app → optimize **ARPU**. - Long-term business → optimize **LTV and retention**, balancing churn. ### 6. Experimentation outcomes and patience - Method: client's paywall as control vs. 4–5 new designs. - Claim: they beat the control in the first week **for every app except two**; for those, a statistically significant win took until the second or third experiment. - "You just have to be patient also. It's not always going to work out." ### 7. Paywall touchpoints - "All the different touch points are extremely important": onboarding paywalls, gated-feature paywalls, settings-page paywalls, cancel-flow win-back discounts, pre-delete paywalls ("Before you go…"). - Most used: **after-onboarding paywall**. The host adds a cited figure: "**78% of iOS apps on Mobbin** show the paywall after onboarding." ### 8. Account creation before vs. after paywall — explicitly unresolved - "That you have to test actually because I have tested it multiple times and I still have inconclusive results," attributing this to different app categories. - Personal preference: account first, then paywall, so "I can tie a user ID to the person that's actually subscribing." ### 9. Discounts — conditional position - Steep discounts in **win-back campaigns**: "I think is okay." - Immediate 80%-off offers **after onboarding**: disliked — "you could be cannibalizing revenue" before users see the paywall again. - For subscribers considering canceling: a lower rate before price testing is "the cool way" to keep would-be churners. ### 10. Disagreed-with best practice: spin-the-wheel paywall - Described as a **predetermined** lottery landing on a discount percentage. - Contradiction preserved as stated: bad for long-term business optimization, "but if you're optimizing for a weekly price, and you want to maximize revenue, **unfortunately, it works**." - Additional concern: users are "getting comfortable closing paywalls" because they expect an offer afterward. --- ## Host's Closing Synthesis - Jonathan "kept coming back to the same question": **what kind of business are you trying to build?** - Host's framing: the two approaches (short-term revenue vs. long-term business) are "**neither of these are right or wrong**, but they're very different games." --- ## Unresolved Tensions (preserved, not smoothed) - **Yearly default vs. business fit**: yearly maximizes LTV, but Jonathan explicitly notes it may not suit every business. - **ARPU vs. LTV**: ARPU is explicitly retired as a universal North Star, yet still recommended for a specific builder type. - **Spin-the-wheel**: simultaneously criticized and admitted to work under a revenue-maximizing goal. - **Account-before-paywall**: tested repeatedly, results remain inconclusive by Jonathan's own account. - **Two of his client apps** did not show first-week wins — an exception he volunteers rather than omits. # Video Attribution & Provenance Record **Video:** *He Tested 4,700 Paywalls. These Won.* **Video ID:** 01a15ba0-7833-7f3b-9d64-e69dd00cd1bd ## Speakers & Roles | Speaker | Role | Evidence | | --- | --- | --- | | **Host/Interviewer** | Creator/interviewer; asks questions, provides framing and outro narration | Opens video ("I spoke to someone who's designed 4,700 paywalls"), interstitial commentary, closing narration | | **Jonathan** | Guest — paywall optimization expert; claims experience designing **4,700 paywalls** | Named explicitly by host in closing: *"Throughout this conversation, Jonathan kept coming back to the same question"* | | **Unnamed intro speaker** | Appears only in opening teaser via `>>` markers; may be host or Jonathan — **not explicitly identified** | Transcript offers no name attribution for the cold-open quotes | **Format note:** Transcript uses `>>` dialogue markers indicating a multi-speaker interview edit; only the guest is named (Jonathan), and only once. ## Third-Party & Referenced Sources - **Mobbin** — third-party data platform cited by the host: *"78% of iOS apps on Mobbin show the paywall after onboarding."* This statistic is presented by the host, not the guest. - **Client results claims** — made by the guest about his own business: his team beat the client's control paywall in week one "for every app except two." These are self-reported and unverified in the transcript. - Guest's personal professional experience (4,700 paywalls) is a self-reported credential; no independent verification is supplied. ## Promotional Segments - **Flagged:** Closing call-to-action: *"Next up, watch this paywall video on why some of them work and some don't."* — promotes other channel content. - **Possible promotion (contextual, not explicit):** The guest references "our clients" and describes his firm's service model (designing 4–5 paywalls against a control); no explicit sales pitch or product name appears. ## Uncertainty & Unavailable Channels - No curated metadata supplied beyond title and transcript — speaker full names, credentials, and channel identity unconfirmed. - **Comments availability:** Unknown — no evidence in source material. - The opening teaser speaker attribution is ambiguous (host vs. guest). - Guest's company/affiliation is never named. ## Source Inventory Summary - **Referenced external source:** Mobbin (statistic). - **Self-reported claims:** 4,700 paywalls designed; client win-rate results. - **Explicit promotion:** Outro video recommendation. - **Named individuals:** Jonathan (guest only). I spoke to someone who's designed 4,700 paywalls. \>\> How important is paywall optimization? \>\> As a starting point, it's honestly not that important. \>\> And the highest converting paywall isn't always the one that you should use. \>\> Unfortunately, it works. \>\> So today, we are unpacking the biggest growth lessons from thousands of paywall experiments and why most founders are optimizing the wrong thing. \>\> For your first paywall, honestly, all that you need to do is to have a headline describing the product, a couple bullet points describing the product and what it does, and a button to continue. I get in calls with some people that think they need to do all these crazy optimizations for their placements and paywalls in the beginning. You really don't. You just need to make sure that you're getting users into your app first, and then you can optimize that traffic later. \>\> When you run a paywall experiment, how do you decide what's worth testing first? \>\> Design tests move the needle the most. So, you try radically different designs until you find something that blows everything out of the water. You could have a video paywall, you could have bullet list paywall, a trial timeline paywall, a long-form paywall. After design, personalization moves the needle the most. Calling out their name, highlighting their goals. \[music\] So, if they're male or female and it's a fitness app, you can show like a strong man on the paywall and it's representative of the user's identity, and then price packaging design. So, how do you design the footer of the paywall? If you have a yearly and a weekly product, are they vertical product groups? Are they horizontal? What do you put in those product groups? How do you present the price? Do you show it as weekly for both options with a subtitle that shows the actual real price? Or how do you go about that? Ideally, you want to default to a yearly product because we see that that has the highest LTV. You only want to show two to decrease cognitive load on the user, but a yearly product may not be the best for your business. You can also start doing tests based on what kind of device the user has. If the user is on an iPhone 17 Pro, they're on 5G and don't have low battery mode, show them a higher price as opposed to an a user that's on an iPhone 13 Pro on 3G and their low battery indicator is working, maybe you want to show them a lower price because they may or may not convert at the higher price. But, that's like one of the last levers that you really pull because it's so much work. It incrementally gets smaller and smaller in what moves the needle. \>\> What do you think are the metrics that matter the most when you're evaluating a paywall experiment? \>\> That depends entirely on the business. I used to use ARPU as my North Star metric, but ARPU doesn't necessarily give you all the answers. Your ARPU may be high, you may have three or four dollar ARPU, but the reason you may have three or four dollar ARPU is because you have weekly products, and so your churn may be 90 to 95% per month. Even though ARPU is high and it looks good, it doesn't tell you the full picture. I typically look at paywall percentage, how many people are actually looking at the paywall that installed the app. If it's above 80%, you're doing good. If it's 90% or above, you're crushing. I look at trial to paid conversion rate, LTV, D1, D7, D30, churn, and then based on the kind of customer that they are, I'll suggest different things. If you're vibe coding an app and you just want to build something and launch it and get as many users as possible, then you're going to be focusing on ARPU as the key metric. But, if you're building like a long-term business, you want to maximize revenue while still balancing churn, then optimize for LTV and retention. We take your paywall and use that as a control, and then we would design four to five paywalls to go against it. For all of our clients so far, we are able to beat the control in the first week for every app except two. It ended up taking until the second or third experiment to really see the statistically significant win for them. When you're doing experimentation, you just have to be patient also. It's not always going to work out. \>\> How about the paywall touch \[music\] points? How important is it to test them? \>\> All the different touch points are extremely important. Onboarding paywalls, gated paywalls that gate some kind of feature, paywalls in the settings page, paywalls for if the user wants to cancel their account, you can win them back showing them some kind of discounted offer. Uh a paywall for when they're about to delete the app. You'll say, "Before you go or before you delete, we'd love for you to try one last time." When it comes to what is the most used paywall, it's the after onboarding paywall. \>\> In fact, 78% of iOS apps on Mobbin show the paywall after onboarding. \>\> Now, do you create an account before or after? That you have to test actually because I have tested it multiple times and I still have inconclusive results and I think it's just because it's all been in different app categories. I like to create an account first and then show the paywall. That way I can tie a user ID to the person that's actually subscribing. So, you have to think about the entire life cycle of the customer. It's literally the only part of the app that makes you money. Having a steep discount in your win back campaign, I think is okay. I don't really like it when apps immediately go for the 80% off discount after onboarding because you could be cannibalizing revenue by showing them such a discounted offer before they've even had a chance to go back and see a paywall a few more times. But, if they're subscribed already and they're thinking about canceling, showing them a lower rate before you do a bunch of price testing is the cool way for you to keep your customers that are thinking of churning anyway. \>\> What's a paywall best practice you completely disagree with? \>\> Is the \[music\] spin the wheel paywall. This is a predetermined spin the wheel lottery file that may land on some kind of discounted percentage. If you're optimizing for the longer-term business, that may not be a good paywall for you. But, if you're optimizing for a weekly price, and you want to maximize revenue, unfortunately, it works. The issue is that I think more and more users are getting comfortable closing paywalls because they know they're going to get some kind of offer afterwards. For the apps that want to build a really good business, just remember that this is a long-term game. \>\> Throughout this conversation, Jonathan kept coming back \[music\] to the same question. What kind of business are you trying to build? Neither of these are right or wrong, but \[music\] they're very different games. Next up, watch this paywall video on why some of them work \[music\] and some don't.