核心要点
- Epic 案判决落地一年后,所谓 App-to-Web(“省下 15%–30% 的苹果抽成”)的故事最终被证明是有条件的。 Adapty 平台上有三款 App 实测了这一方案,得到了三种截然不同的结论。
- App 1(标准 30% 抽成、引导流程结束后的付费墙位置):Web 转化率比 IAP 低 26%,但 ARPPU 翻了一番,单次付费墙曝光的净收入提升 53%。原因在于他们没有把原生付费墙”原样照搬”到 Web,而是为 Web 重新设计了报价方案。
- App 2(AI App):同一个 Web 付费墙在最佳位置(引导后)的转化率,几乎是最差位置(App 内场景化追售)的 4 倍。位置远比设计重要。
- App 3(小企业计划、Apple 抽成 15%):Web 转化率提升 55%,但单次曝光的净收入反而下滑 9%。小企业计划下,这笔账算法完全不同。
- 五条经实测验证的最佳实践:为 Web 重新设计报价方案;选对触发位置(引导后是赢家,App 内追售是输家);先搞清自己的抽成档位;Apple Pay 必须设为默认,否则不如不做;以单次曝光收入(而非转化率)为核心指标。
- 合规没有商量余地。 2026 年 4 月 Cal AI 被下架事件——一款年 ARR 5000 万美元的 App 因三项明确违规被苹果短暂下架——再次印证苹果对这一领域仍在严格执法。本文末附完整合规清单。
- 这是一道有条件的选择题,而非通用解。 满足”标准抽成档 + 为 Web 重设报价 + 引导后位置 + Apple Pay 默认 + 有可观的美区 iOS 流量”——可以试;任意一条没满足,这点研发预算不如花在别处。
一年前的今天——2025 年 4 月 30 日,Yvonne Gonzalez Rogers 法官裁定苹果不得再对美区 iOS App 内通过外部链接完成的交易抽取佣金。24 小时内,苹果更新了 App Store 审核指南. 72 小时内,Spotify、Patreon、Proton 就推出了适配新规的版本。彼时的叙事听上去简单极了:在 App 内付费墙加一个按钮,把用户引导到自有结算页,省掉苹果 15%–30% 的抽成,等于白拿利润。
一年过去,几乎没有一件事像当初描绘的那样简单。
2025 年 12 月,第九巡回上诉法院修改了原判决:苹果在外部链接交易上仍可以收取”合理”的佣金,具体费率仍在博弈中。2026 年 4 月,苹果短暂下架 Cal AI——一款年 ARR 5000 万美元、刚被 MyFitnessPal 收购的 App——理由是 Web 支付环节违规。这一下架信号非常明确:App Review 团队仍在密切盯防开发者如何落地外部支付。一年来真正跑过 A/B 测试的运营者,得出的结论远比 2025 年 5 月那波厂商话术微妙得多。
本文是 Adapty 平台上一整年观察客户落地 App-to-Web 付费墙的全部经验沉淀:三款 App,三种结果;五条普适最佳实践;一份基于最新驳回案例整理的合规清单;以及一套坦率的决策框架,帮你判断到底要不要上线。
有一点必须开门见山：App-to-Web 只对美区 iOS 用户有效。Epic 案是美国法院的判决,苹果的政策响应也仅限于美区 App Store。如果美区流量在你的 iOS 用户大盘里占比不高,这块机会的天花板就被这个比例直接锁死了。
App-to-Web 与 Web-to-App：你做的到底是哪一种?
在深入展开之前,先做一个品类厘清。市面上绝大多数关于”Web 付费墙”的内容,把两个运营逻辑几乎毫不相干的产品混为一谈。
App-to-Web 付费墙(本文聚焦的主角):App 内一个按钮,点击后跳转到 Web 结算页。用户已经在你的 iOS App 内,在付费墙上点击按钮 → 浏览器打开 → 完成支付 → 回到 App,订阅已生效。这正是 Epic 判决放开的场景,目前对美区 iOS App 开放。
Web-to-App 漏斗:从 Web 起跑——通常源自广告投放。用户走完一轮 Web 端问卷式引导,撞到付费墙完成付费,再下载 App。这套打法早就存在,远早于 Epic 判决,任何平台、任何地区都能用。做 Web-to-App 漏斗,推荐看 FunnelFox。
本文的剩余内容全部围绕 App-to-Web 展开。Web-to-App 的获客经济模型、归因机制、转化规律都和它有显著差异,是另外一篇文章的事了。
数据说话：三款 App，三种结果
反驳这个话题上简单”最佳实践”内容的最有力证据,就是真正跑过测试的运营者得出的赢、输、无差异三种结果几乎各占三分之一。同样的方案,在不同 App 上跑出截然不同的结局。下面是过去一年 Adapty 平台上三位客户认真跑完干净 A/B 测试后呈现的图景。
App 1：标准 30% 抽成档的美区 iOS 订阅类 App
受众相同、位置相同(引导后),时间窗口高度重叠。这是一次方向性观察,而非严格的 50/50 A/B 测试,但两侧样本量都足够大,数据具有意义。
| 指标 | 原生 (IAP) | Web (app-to-web) | 差异 |
| 转化率（每次曝光的购买率） | 4.95% | 3.69% | −26% |
| ARPPU | $23.76 | $47.59 | +100% |
| ARPU | $1.16 | $1.77 | +53% |
每次曝光的购买率在 Web 端下滑 26%,但 ARPPU 翻了大约一倍。最终结果是:单次付费墙曝光的实拿收入提升 53%。
+53% 背后的算账逻辑:Web 端节省了约 25 个百分点的抽成(苹果的 30% 被 Stripe 的约 5% 替代),同时 Web 端新上的长周期套餐相比原生周付套餐捕获了更多人均收入。两项叠加,远远抵消了 26% 的转化率下滑。转化率下滑是真实存在的,但抽成节省加上套餐重构带来的收益更大。
这里有个细节值得拎出来:这支团队没有把原生定价照搬到 Stripe,而是为 Web 单独搭了一套报价方案。原生付费墙是周付套餐 + 一个低价年付;Web 版本则新增了多档价格的套餐——周付定价低于原生,长周期套餐以”相比周付节省 XX”来锚定。Web 之所以赢,是因为团队把它当成了一个不同的产品,而不是同一个产品换条赛道。
App 2：某 AI 陪伴类 App,实测五个触发位置
App 2 把同一个 Web 付费墙投放到了 App 内五个不同位置。付费墙设计相同、产品相同、支付服务商也相同,唯一的变量是用户在漏斗的哪一环遇到它。
| 触发位置 | 转化率 | ARPU |
|---|---|---|
| 主位置（引导后） | 3.38% | $2.55 |
| 最后挽回报价 | 2.90% | $4.57 |
| 漏斗中段报价 | 2.18% | $1.69 |
| 场景化追售 | 0.87% | $0.98 |
同一个 Web 付费墙,最佳位置的转化率几乎是最差位置的 4 倍。规律一致:Web 付费墙在用户主动评估”是否要订阅”的核心决策点上能跑赢;一旦扔到 App 深处的场景化追售位——用户正在执行任务时——浏览器跳转的注意力切换会直接掐断转化。
App 3：走 Apple 小企业计划的某语言学习类 App
App 3 跑了一个和 App 1 类似的测试:受众相同、位置相同、样本量接近。表面上看,结果像是一场完胜。
| 指标 | 原生 (IAP) | Web (app-to-web) | 差异 |
|---|---|---|---|
| 试用转化率 | 5.80% | 6.04% | +4% |
| 转化率（每次曝光的购买率） | 2.54% | 3.93% | +55% |
| ARPPU | $65.99 | $52.83 | −20% |
| ARPU | $1.67 | $1.52 | −9% |
每次曝光的购买率提升 55%。然而,单次曝光的实拿收入反而低了 9%。团队最终回滚了实验:IAP 重新被设为主 CTA,Web 被降级为不太显眼的次级入口。
问题出在哪?两个原因。第一,这支团队没有为 Web 重新设计定价结构,直接照搬了原生套餐,导致 ARPPU 下滑 20%。第二——也是被讨论得最少的——这款 App 走的是 Apple 小企业计划,苹果只抽 15%,不是 30%。扣掉 Stripe 手续费后,Web 实际只省下大约 10 个百分点,而不是 25 个百分点。这点差额,不足以填平 ARPPU 的下滑。
最佳实践 1：为”这个时刻”设计,而不是为”这条管道”设计
App 1 的发现是整篇文章的核心论点。把 Web 付费墙当成卖一个不同产品的机会,而不是用另一种方式去卖同一个产品。
App Store 强制了一种特定的付费墙范式:同屏可见的套餐通常只有一到两个,所有信息都要在一屏内争夺注意力,价格标签自带”贵感”。Web 则没有这些约束。
你可以滚动、可以同屏展示六个套餐、可以把价格点拆解到不同的计费周期,可以用用户最有感的周期(月、季、年)来呈现价格——只要实际扣款金额清晰展示在旁边即可。这种灵活性体现在套餐数量和价格档位的丰富度上,而不是模糊用户的实际付款金额。
把原生付费墙直接搬到 Stripe 上的 App,通常都是输。我们测试中观察到的规律是:在报价方案保持不变的前提下,原生的转化率始终更高。App 1 在重新设计报价的情况下转化率下滑了 26%,实际影响因 App 而异。要把浏览器跳转视为一种真实存在的拖累,必须用别的杠杆去补偿——具体损失你需要自己测。把 Web 当作一次重构机会(不同套餐结构、不同的价格锚点、长卷轴布局、Apple Pay 设为默认)的 App,即便转化率更低,也能跑赢大盘。
“为 Web 重新设计”在实操中长什么样:
更丰富的产品组合。 App 1 的 Web 版本在年付套餐之外提供了多个套餐选择。原生付费墙因为屏幕空间所限,通常只放两到三档;Web 端没这个限制。
Web 原生的版式。 长卷轴布局、配以功能清单、社会证明、FAQ——这种格式在 Web 上表现优秀;原生上同样的长度会让用户疲劳。把 Web 付费墙当成 landing page 来做,因为它本质上就是。
清晰的跳转提示。 Fitbod 的样式可以作为范本。CTA 文案”开启免费试用”,紧贴下方一行小字”点击此按钮将跳转至 Web”,再往下放一个更小的”继续通过 App Store 购买”链接。诚实、合规、不误导用户。
最佳实践 2：位置比设计更重要
App 2 的数据把这一点摆得很直白。同一个 Web 付费墙,在没有任何设计改动的前提下,最佳位置的转化是最差位置的 6.4 倍。把 Web 支付按钮塞到 App 深处场景化追售位的 App(聊天页、设置菜单、功能门槛),转化通常都很弱。当用户原本不打算在此刻做购买决策时,浏览器跳转的代价过于昂贵。
App-to-Web 真正能跑通的位置:
- 引导后付费墙。 用户刚完成设置、评估完 App 是否符合需求,正坐在”买不买”的决策上。这是摩擦容忍度最高的时刻。同时,这也是绝大多数 App 收入的来源——优化这里的回报会被放大。
- 首次拒绝后的二次报价。 用户在第一个付费墙上点了”放弃”后,第二次给出的挽回报价可以有效跳 Web,因为用户已经认真评估过一次购买决策。App 2 在这个位置上跑出了 2.90% 的转化率,以及全部位置中最高的 ARPU($4.57)。
- 主位置上的 A/B 测试变体。 App 2 在主位置上跑的 A/B 变体转化率达到 5.54%,显著高于基准的 3.38%。Web 变体的设计本身,和”走哪条管道”同样重要。只要测试得当,主位置上的 Web 是能跑赢的。
对任何付费墙,通用原则都是把它摆在意图最强的地方。App-to-Web 特有的补充是:浏览器跳转是叠加在付费墙摩擦之上的一层额外摩擦。所以,如果一个低意图 IAP 位置的转化率是 4%(对应高意图位置的 1%),那么同一个低意图位置上的 Web 付费墙,转化率会从同款付费墙在高意图位置取得的 3%–5%,直接掉到 0.87%(App 2 场景化追售位的实测值)。
最佳实践 3：先搞清自己的抽成档位,再算账
这是这个话题里被讨论得最少、却决定整道算术题成不成立的关键点。2025 年 5 月那套”省 30%”的话术,只对真的在交 30% 抽成的开发者成立。很多订阅类 App 并不在这一档。
Apple 的小企业计划(Small Business Program)把抽成从 30% 降到 15%,适用于年净收入低于 100 万美元(全部 App 合并计算)的所有开发者。App 3 走的就是这个计划。绝大多数早期订阅 App、独立开发者,以及尚未跨过 100 万美元门槛的成长期 App,也都在这一档。
这套数学的差异是实质性的:
| Apple 档位 | Apple 抽成 | Stripe 抽成 | Web 端净节省 | 值不值这点摩擦? |
|---|---|---|---|---|
| 标准档(年收入 > 100 万美元) | 30% | 约 5% | 约 25 个百分点 | 大概率值 |
| 小企业计划( | 15% | 约 5% | 约 10 个百分点 | 大概率不值，除非 ARPPU 同步上涨 |
标准档省下的 25 个百分点,足以吸收 20% 的转化率下滑还有得赚;小企业档省下的 10 个百分点则吸收不了。转化率必须保得更稳,经济模型才能跑通——这就把更多压力压在了重构质量、位置选择和 Apple Pay 默认设置上。
还有一个叠加在档位上的因素:品牌信任。App 越大、辨识度越高,Web 端的转化差距越小。Spotify 或 Netflix 已经被用户信任,用户在它们的 Web 页面上输入卡号毫不犹豫;一个从来没听说过的 App,在用户安装后 90 秒就抛出一个 Web 付费墙——用户当然会犹豫。已经建立强品牌的成熟消费品牌,可以吸收更大比例的摩擦;正在建立首次信任的独立 App,通常吸收不了。
如果你走的是小企业计划,且 Web 端的 ARPPU 不会显著高于 IAP 端,App-to-Web 目前对你来说大概率还不值得这点运营开销。一旦跨过门槛进入标准档,这道算术题会立刻变得诱人得多。
最佳实践 4：Apple Pay 设为默认,否则不如不做
这是几乎所有测过 App-to-Web 的运营者复盘时都会确认的关键杠杆。Apple Pay 是让 Web 结算页”摸起来跟 IAP 一样丝滑”的关键;手动填卡则是转化的杀手。
数据表明：在 App 1 的 Web 版本中,真正跑通转化的产品几乎都是通过 Apple Pay 完成支付的。这个规律在所有运营者的复盘里反复出现。绝大多数完成 Web 结算的用户走的是 Apple Pay 或 Google Pay;极少有人会为了开启一个免费试用而手动输入完整卡号——流失会非常严重。
配置建议:
- 把 Apple Pay 设为 Web 结算页的预选支付方式。卡支付应作为兜底(“或使用银行卡支付”),而不是默认。
- 尽可能使用 in-app browser(应用内浏览器),而不是跳出到外部 Safari。Adapty 自 SDK 3.15 起两种都支持。传入
WebPresentation.BrowserInApp可以把用户留在 App 上下文里,注意力损失更少,购买后返回 App 也更顺滑。 - Apple Pay 要正常工作,需要先在支付服务商后台完成域名验证。Stripe、Paddle、Solidgate 各自的后台都有具体步骤。跳过这一步,Apple Pay 不会渲染。
如果你只能为 App-to-Web 做一件事,那就是把 Apple Pay 设为默认。如果连这一件事都做不到,就严肃考虑一下这条路是不是值得走。
最佳实践 5：盯单次曝光收入,不是盯转化率
App 1 和 App 3 的结果把这一点钉死了。Web 付费墙完全可以输转化率却赢营收,反之亦然。
App 1 一眼看上去：Web 转化率低 26%——很容易判定为失败。直到你测算单次曝光的实拿收入,你才会发现 Web 高出 47%。
App 3 一眼看上去：Web 转化率高 55%——很容易判定为胜利。直到你测算单次曝光的实拿收入,你才会发现 Web 低了 9%。
两支团队如果以转化率作为主要成功指标,都会做出错误的决策。App-to-Web 测试的正确指标是 ARPU(实拿收入 ÷ 独立曝光人数),因为它同时包含了”多少人付费”和”扣除手续费后每个人值多少钱”两层信息。
端到端示范：一个完整 App-to-Web 流程长什么样
Zumba 的 iOS App 把以上所有最佳实践落到实处,可以拿来当样板看。
App 内付费墙保持合规。两个套餐可见(带试用的年付、无试用的月付)。Web 入口是醒目的”额外省 10%” CTA;IAP 兜底”立即加入”紧贴下方,可用但视觉上更安静。苹果的审核要求被满足,用户看到的报价就是他们最终会得到的报价。
Web 结算页打开时,Apple Pay 已预选,折扣已自动应用。€99.99 变成 €89.99,无需手动输入促销码。今日扣款 €0(因为是试用)。用户从这一屏开始,两次点击就能完成购买。
没装 Apple Pay 的用户依然有银行卡表单可用,但这是次要路径。同样的折扣、同样的试用、同样的总金额。促销码自动应用,意味着用户不需要记住、也不需要去找一个码。
整个流程就是这篇文章的微缩版:重构后的报价(10% 的 Web 独家折扣在原生上并不存在)、Apple Pay 在前卡支付兜底、IAP 可见但次级、试用条款清晰、没有意外。让出去的折扣金额大致等于 Zumba 原本要付给苹果的抽成——折扣事实上是”绕过 IAP”这件事自己出的钱。这就是 App-to-Web 做对了之后该有的样子。
App Store 审核仍然要求什么：Cal AI 案的三条规矩
2026 年 4 月，苹果短暂下架了 Cal AI。Cal AI 是一款年 ARR 5000 万美元的卡路里计算 App,最近刚被 MyFitnessPal 收购,目前在 Health & Fitness 榜上排名第 4。下架理由:Web 支付环节违规。
Cal AI 是一次精心设计的高知名度警示案例。Epic 判决一周年之际,苹果想传递的信号很清楚:使用外部支付的自由,不等于想怎么用就怎么用。App Review 还在线、规则仍然在被执行。
苹果指出了三条违规:
- 完全跳过了内购。 Cal AI 在付费墙上把 Stripe 设为唯一支付选项,IAP 被从用户的选项中拿掉。对非阅读类 App,这违反了审核指南 3.1.1:任何外部支付链接旁,必须同时提供 IAP。”阅读类”豁免(图书、音乐、视频、音频流媒体)并不适用于一款卡路里计算 App。
- 误导性账单设计。 付费墙以更显眼的方式展示”折算到周”的价格,而真正会扣的金额却被弱化。试用切换开关遮蔽了自动续费提示。两者都违反了 3.1.2c:订阅条款必须清晰、无歧义。
- 操控性手法。 用户拒绝首次订阅报价后,紧接着抛出第二个不同的订阅报价。叠加 App Store 上称这款 App”误导””欺骗”的负面评价,触发了开发者行为准则 5.6 条。
修复完问题后,Cal AI 被重新上架。信号已经送达:苹果在这一领域仍然在执法,而且会拿大 App 做警示样板,以震慑后来者。
由此得出的合规清单：
| 要求 | 落到实操是什么意思 |
|---|---|
| 外部链接旁必须同时提供 IAP(非阅读类 App)一起提供 | 两个选项都必须可见。视觉上可以优先 Web,但 IAP 不可移除。 |
| 实际扣款金额展示的醒目度,不得低于任何”折算到周”的计算 | 展示”$1.99/周”却没有同等醒目的”年费 $103″,属于违规。 |
| 试用 + 自动续费的条款必须无歧义 | 如果用到试用切换开关,自动续费信息必须不因开关状态而消失。 |
| 不要在用户拒绝后立刻链接第二个订阅报价 | 要做也要谨慎处理。规则的本质是意图——苹果在找的是让用户感觉被操控的模式。 |
| 披露跳转行为 | “点击此按钮将跳转至 Web”或类似表述。Fitbod 的样式可以直接套用。 |
| 自行处理退款、拒付和税务合规 | 苹果不再替你打理。这是实打实的运营成本。 |
| 监控用户评论里的”诈骗””误导”等关键词 | 苹果在监控,你也应该。 |
另一个值得标注的监管动向:2025 年 12 月的上诉判决意味着苹果现在可以对外部链接交易收取”合理”的佣金,具体费率仍在博弈中。如果你的商业模型还建立在 2025 年 5 月”外部支付完全免佣金”的假设上,请立即更新模型。节省额会比一年前小,尽管目前还没人说得清确切的数字。
如何在 Adapty 中上线 App-to-Web
配置本身并不复杂。完整步骤参见我们的文档。这里给一个全景路径。
步骤 1：在 Dashboard 配置 Web 付费墙
进入 Paywalls 模块,切换到 Web Paywall 标签页,新建一个 Web 付费墙。每个付费墙会得到一个独立 URL,负责承接跳转。
步骤 2：配置支付服务商和设计
Adapty 支持 Stripe、Paddle、Solidgate、FunnelFox Billing。把 Apple Pay 设为默认支付方式。在支付服务商后台完成域名验证,确保 Apple Pay 能正常渲染。完整配置步骤参见 web 付费墙配置文档。
步骤 3：把 Web 付费墙按钮加到 App 内付费墙
如果你用 Paywall Builder,直接在现有付费墙里加一个 Web Paywall 按钮元素;如果你用的是自研付费墙,调用 SDK 的 openWebPaywall 方法。具体平台的接入指南可分别参考 iOS, Android, React Native 和 Flutter 版本的文档。
步骤 4：配置正确的用户分群
App-to-Web 目前仅对美区 iOS App 开放。为 Web 变体单独建立一个”仅美区”的用户群,其余流量继续走标准原生付费墙。
步骤 5：跑一场认真的 A/B 测试
不要在没有对照组的情况下直接全量打开 Web 付费墙。和现有原生变体跑 50/50 切流,至少持续 4 周。监测 ARPU、退款率、30 天留存。基于全貌做决策,而不是首周的转化数字。
步骤 6：60–90 天观察期后再放量
第一个月反映的是结算环节;第二、三个月反映的是留存和退款。看到完整的群体行为之后,再放量也不迟。
总结
App-to-Web 是一道有前提条件的战略选择题,不是”白拿 30%”的免费午餐。处在标准抽成档位、愿意为 Web 重构报价方案的 App,能跑出有意义的胜利;走小企业计划、研发资源有限的 App,目前这道算术题大概率还跑不通。要问的真正问题不是”我该不该上 App-to-Web?”,而是”我是否满足那些让它能跑通的条件?”
如果您正在考虑上线 App-to-Web,想聊聊自家 App 是否契合这套打法,欢迎预约我们团队。过去一年,我们在 Adapty 平台上见证了大量此类测试的完整跑通过程,可以帮您判断这一仗对您而言值不值得打。
