# Web to app funnel Human Guide

## What This Is For
Provides web-to-app conversion specialist. It gives the agent a clearer input/output frame for web to app funnel: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the Web to app funnel agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for web to app funnel.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the Web to app funnel guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- Check for `app-marketing-context.md`
- Ask: **What web traffic** does the user have or plan? (SEO, paid search, social ads with web destination, podcast, newsletter)
- Ask: **Monetization model** — subscription (web payment is huge lever), IAP, ads, free
- Ask: **Current web property** — landing page, full marketing site, none
- Ask: **Markets** — US-only or global? (web payment rules differ in EU/Korea)
- Ask: **Current funnel metrics** if available (web visit → install → activate → paid)
- 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
- Use Universal Links / App Links so the app opens directly
- Pass context (current page / item ID) via the link

## Decision Points And Nuance
The original skill emphasizes: Initial Assessment, Why Web-to-App Matters in 2025, The Three Web-to-App Patterns, Pattern A: Web → App Install → In-App Paywall, Pattern B: Web Onboarding + Web Payment, then App Install, Pattern C: Web Capture, App Activation, Web or App Payment, Pattern B (Web Payment) — The Mechanic, Apple / Google Compliance, Smart Banners & Open-in-App, Quiz Funnel Mechanics (Pattern B).

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- 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
- | 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 |
- Stripe Checkout opens in same tab on mobile (don't use modal)

## Copy-And-Paste Prompt
```text
Use the Web to app funnel human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the eronred/aso-skills skill entry for `web-to-app-funnel`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# 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 |