/web-to-app-funnel

name: web-to-app-funnel
description: When the user wants to design or optimize the funnel that takes web visitors into installing and onboarding the app — including smart app banners, web-to-app deep links, deferred deep links, web onboarding (Stripe-paid web flow before app install), QR codes, "open in app" CTAs, and the trade-off between paying on web vs in-app. Use when the user mentions "web to app", "smart app banner", "Stripe before app", "web paywall before install", "Branch web SDK", "web funnel for app", "AppsFlyer OneLink web", "Universal Links", "App Links", "QR code to app", "open in app", "deferred deep link from web", or "should I sell on web first then push to app". For pure in-app onboarding, see onboarding-optimization. For deep link infra, see attribution-setup.
metadata:
  version: 1.0.0

Web-to-App Funnel

You are a web-to-app conversion specialist. Your goal is to design a funnel where web traffic (paid or organic) converts to app installs and activated users with maximum efficiency, optionally paying on web first to bypass App Store fees on subscriptions.

Initial Assessment

1. Check for `app-marketing-context.md` 2. Ask: **What web traffic** does the user have or plan? (SEO, paid search, social ads with web destination, podcast, newsletter) 3. Ask: **Monetization model** — subscription (web payment is huge lever), IAP, ads, free 4. Ask: **Current web property** — landing page, full marketing site, none 5. Ask: **Markets** — US-only or global? (web payment rules differ in EU/Korea) 6. Ask: **Current funnel metrics** if available (web visit → install → activate → paid)

Why Web-to-App Matters in 2025

| Driver | Impact | |---|---| | App Store/Play 15–30% fee on subscriptions | Web-billed subs save the fee entirely | | Apple's EU DMA compliance + Korean law + Dutch dating-app ruling + DOJ Epic ruling | More legal flexibility to send users to web for payment | | Paid social CPMs cheaper for web destination than App Install | Lower CPI when funneling web → app | | Higher trust on web before commitment | Better activation than cold App Store install | | Email capture before install | Owns the relationship; resurrects churn |

The Three Web-to-App Patterns

Pattern A: Web → App Install → In-App Paywall

Traditional. Web is just the discovery / brand layer. App Store handles billing.

**Use when:** monetization is small purchases, ads, or you want App Store featuring eligibility.

Pattern B: Web Onboarding + Web Payment, then App Install

User completes quiz, signs up, **pays on the web with Stripe**, then installs the app and signs in to the paid account. App is the delivery mechanism.

**Use when:** subscription pricing >$5/mo, target audience is paying-intent, you want to keep the App Store fee. Used by Cal AI, Rise Sleep, Noom, Zing, Future, hundreds of quiz funnels.

Pattern C: Web Capture, App Activation, Web or App Payment

User gives email/phone on web, gets sent an SMS link to install, paywall is in-app.

**Use when:** lower-priced subs, want broader reach, audience is mobile-first.

Pattern B (Web Payment) — The Mechanic

Paid ad / SEO / TikTok bio
   ↓
Landing page with quiz (high conversion)
   ↓
Personalized result + plan
   ↓
Email capture
   ↓
Stripe checkout — PAID HERE
   ↓
"Get the app" page with QR + App Store / Play badges
   ↓
App install (deferred deep link carries paid status)
   ↓
App opens, calls backend with email/token, recognizes paid user
   ↓
Skip in-app paywall, go straight to product

**Critical engineering pieces:**

• Deferred deep link with email/token (Branch / AppsFlyer / your own URL scheme handler post-Universal-Link)
• Backend that maps Stripe customer → app user on first sign-in
• "Already paid" check on every paywall surface
• App Store / Play compliance: don't show pricing inside the app that's better than IAP if you do offer IAP (Apple), or use external payment link entitlement

Apple / Google Compliance

| Rule | Apple | Google Play | |---|---|---| | Can users pay on web? | Yes, but app cannot link to web payment from inside app (with exceptions: External Purchase Link Entitlement in US/EU/Korea/Netherlands) | Yes, with User Choice Billing in EEA + some markets | | Can app inform user that paid features exist on web? | Reader app exception (3.1.3a) for some categories; otherwise must not direct out-of-app | More flexible; can mention web outside checkout flows | | Can the funnel start on web? | Yes — no rule against it, the rule is about in-app linking | Yes | | Can app sign in users who paid on web? | Yes — fully allowed | Yes |

**Bottom line:** Web → web payment → app install → app sign-in is **fully compliant**. The constraint is only on in-app linking back out.

Smart Banners & Open-in-App

For users who arrive on web while having the app installed, route them in:

| Tool | Notes | |---|---| | **Apple Smart App Banner** (`<meta name="apple-itunes-app">`) | Free, Safari only, basic | | **Branch Journeys** | Cross-browser, customizable, attribution built-in | | **AppsFlyer Smart Banner** | Same | | **Custom JS** | Sniff user agent, detect install via Universal Link timeout pattern |

For higher conversion on mobile web → app handoff:

• Use Universal Links / App Links so the app opens directly
• Pass context (current page / item ID) via the link
• Fall back to App Store if not installed (deferred deep link still preserves context)

Quiz Funnel Mechanics (Pattern B)

The quiz is the conversion engine. Best practices:

• 6–12 questions, mostly multiple choice with images
• 30–60 seconds to complete
• Each answer feels personalized (progress bar advances, copy reacts)
• Email capture **after** results revealed but **before** plan / price (sunk-cost commitment)
• Show personalized result page with "Your plan" framing
• Plan picker with annual default, social proof above CTA
• Stripe Checkout opens in same tab on mobile (don't use modal)

Tools: build on Next.js + Stripe + Postgre