你买来了这一下点击。用户点了你的广告、你的推送、或朋友转发的链接，落到了对的商品、读到了对的文章。然后他点了「在 App 里打开」——却落在了你的首页信息流。他正在读的那篇文章、正要买的那件货、为这一下点击付了钱的那个活动：全没了。这就是「断裂的跳转」，它是流量 App 漏斗里最贵的一道泄漏，因为它发生在终点线上。
跳转，正是漏斗断裂的地方。 Web 转 App 的旅程有五步——提醒、点击、路由、安装、还原上下文——每一步都在跨越一道边界，而上下文在默认情况下是被丢弃、而非被保留的（deeplinkly）。第 3 步把本已装了 App 的用户照样送进商店；第 4 步（安装）是单点泄漏最大的一步；第 5 步（还原上下文）把一次全新安装甩到通用首页。一个为了读某篇具体文章而装 App 的用户，落地在信息流里，得自己再去找那篇文章——而大多数人不会找。Branch 与 Apptimize 测得，延迟深度链接带来的注册是通用落地的 1.8 倍、留存 1.9 倍、互动 2 倍。在一个直营消费品牌（DTC）的测试中，延迟深度链接把「安装到下单」从 4.1% 拉到 11.7%，把单笔获客成本从 $42 压到 $15（coinis）。Branch 2024《移动增长手册》称，带深度链接的活动转化是非深度链接的 2–4 倍，7 日留存提升 40%。落在对的屏幕、还是落在首页，这不是四舍五入的误差——这就是整个活动。
WebView 让跳转更糟，而不是更好。 当你的目标屏幕是以「App 内 WebView 文档」的形式提供的，两处失效会叠加。第一，WebView 屏幕没有一等公民的原生路由，于是「在 App 里打开」往往变成「去商店，或重载同一份文档」——原生目标屏始终收不到那些参数。第二，同一份内容如果是在社媒的内置浏览器里渲染的，用户是未登录状态、存储被隔离、referrer 被剥离；在这里登录和付款都更难，于是用户在转化前就放弃了（openup）。你为这次访问付了钱，却把它路由进了最难以完成的那一个环境。
而且，你此时还要依赖第三方才能修好它。 真正能保住上下文的延迟深度链接，需要一个掌握「安装→目标」映射关系的平台——历史上就是 Branch、AppsFlyer 或 Firebase Dynamic Links。Firebase Dynamic Links 已于 2025 年 8 月 25 日正式关停（coinis、Firebase 支持）。把跳转建在它之上的团队，一觉醒来发现链接不再解析。每一个外部深度链接依赖，都是日历上一个「你的漏斗可能断裂」的日期。
运行时从定义上就堵住了这道缝。 宿主自有 runtime 把你的小程序当作 App 内第一方、已签名的组件来跑。把网页或社媒访客路由进来的同一个链接，在 App 已安装时可以直接打开对的 runtime 屏；而因为目标是一个打包好的、带版本的单元、而非一份刚拉取来的文档，活动与商品参数能一路带过安装、在首次打开时就让用户空降到对的屏幕。没有会过期的第三方链接服务，没有要重新拉取并丢上下文的文档。跳转不再漏，是因为它跨越的那道边界，是你的。
WebView 文档 vs 宿主自有 runtime
| 维度 | WebView 文档 | 宿主自有 runtime |
|---|---|---|
| 「在 App 里打开」的结果 | 商店页，或同一份文档重载 | 直接打开对的 App 内屏幕 |
| 跨安装的上下文 | 丢在首页 | 带到对的屏幕 |
| 延迟深度链接 | 依赖外部 SaaS | 打包单元原生具备 |
| 依赖风险 | Firebase Dynamic Links 2025-08-25 已关停 | 无第三方链接服务 |
| 泄漏发生在 | 漏斗第 4–5 步 | 在边界处被堵住 |
