不用 SDK 的延迟深度链接：底层到底是怎么运作的
不嵌入归因 SDK，也能把链接意图带过应用安装这道坎。本文讲清 Android 和 iOS 上什么能真正穿过商店边界、什么会断掉，以及每种变通方案的隐私代价。
上下文死在商店边界
有人点了指向 /product/42 的链接。应用未安装，你的重定向把他送进商店。他安装、打开应用，落在一个通用首页上。承载他意图的那个 HTTP 请求终结在商店页面：刚装好的应用启动时没有 URL、没有 cookie、没有 referrer。点击留下的东西一样都没活下来。
把这份上下文带过安装，就是延迟深度链接（deferred deep linking），标准答案是"嵌一个 MMP SDK"。很多团队不想要这个答案——Apple 开发者论坛的 772811 号帖子只是众多"不用第三方 SDK 怎么做"提问中的一个——而 2026 年 8 月 AppsFlyer 把延迟深度链接移出免费套餐后，问的人更多了。那么自己能不能做？Android 上可以，干净且官方。iOS 上勉强可以，靠的是有实际代价的变通方案。
先说明范围：延迟深度链接是什么、什么时候值得做，我们在另一篇文章里讲。本文只谈管道工程：哪种运输方式能把一个令牌偷渡过安装，以及每一种能信到什么程度。
什么能活过安装，什么不能
Android：Install Referrer API 是实打实的好消息
Google Play 原生解决了这个问题。Play 商店 URL 接受一个 referrer 查询参数，Play 把这个字符串随安装一起保存，应用在首次启动后可以通过 Install Referrer API 原样读回。机制就这么多：没有指纹、没有剪贴板、不用猜。
严格说不算"零代码"：读取该值需要 com.android.installreferrer 库——一个只在本地与设备上的 Play 商店应用通信的小构件。它不向任何人发起网络请求，不是往外打电话的分析 SDK，除了你自己怎么处理这个字符串，不给你的隐私声明增加任何负担。
参数里放什么由你决定：链接 ID、活动名、编码后的深度链接目标。保持简短并做 URL 编码——play.google.com/store/apps/details?id=com.example&referrer=tok_8f2 中的 referrer 会原样返回。
端到端的完整闭环
- 1链接被点击时，重定向在 Play URL 上追加 referrer=<token>，令牌指向存在你服务器上的点击上下文。
- 2首次启动时，应用连接 InstallReferrerClient 并读取 installReferrer 字符串。
- 3应用用令牌到你的 API 换回保存的上下文——深度链接路径、活动信息——并路由用户。
- 4服务器把令牌标记为已消费。referrer 字符串会留在设备上，所以一次性使用必须在服务端强制执行。
限制窄而可预期：该 API 只覆盖真正经由 Google Play 完成的安装。侧载、华为应用市场和其他商店不携带 Play referrer；该值应在首次启动后不久读取一次，而不是当作永久存储。
iOS：没有官方等价物，三条变通路径按序排列
Apple 没有提供任何类似 Install Referrer 的东西。App Store 商品页不会把任意参数带过安装；下面的一切都是建立在这个空缺上的变通方案。从最不坏到最小众：
剪贴板传递
01 · 中等可靠性，受权限限制链接落地页把一个短令牌写入剪贴板——放在按钮点击后面，因为 Safari 要求用户手势才能编程复制——然后跳转 App Store。首次打开时，应用读取剪贴板，找到令牌并向你的服务器兑换。
麻烦从 iOS 16 开始：读取剪贴板会触发系统粘贴弹窗。用户在三十秒前才装好的应用的第一个屏幕上看到"允许从 Safari 粘贴吗？"，很多人会拒绝。拒绝是无声的损失——你无法把它和"本来就没有令牌"区分开。UIPasteboard.detectPatterns 可以不弹窗地检查模式，但读不到值。而且从点击到首次打开之间，剪贴板还可能被覆盖。它确实常常有效，但硬币的另一面清晰可见。
概率（指纹）匹配
02 · 低到中等可靠性，对隐私不友好点击时服务器记录 IP、从 user agent 提取的设备型号和系统版本，以及时间戳。首次打开时应用调用你的端点，端点在一个短窗口（通常不到半小时）内寻找信号吻合的点击。全程没有令牌在移动：匹配就是猜测。
我们描述它是因为有厂商在卖，不是建议你去做。信号在退化：iCloud Private Relay 掩盖 IP，运营商级 NAT 把成千上万用户挤在一个地址后面，设备型号是粗粒度的桶。Apple 明确不鼓励指纹识别，在 privacy manifest 时代，为匹配而收集这些信号是 App Review 可能要求你解释的事。准确率逐年下降，而误匹配会把真实用户送到错误的页面。
App Clip 及其他小众路径
03 · 可靠但狭窄从你的链接唤起的 App Clip 能拿到完整 URL，并在安装后通过共享容器把上下文交给完整应用。在它的适用范围内，这是 iOS 上最可靠的路径——但需要构建和维护一个 App Clip，且只适合轻量即时体验说得通的流程。Shared web credentials 解决的是登录连续性这个相邻问题，不是一般的链接上下文。值得了解，很少是答案。
与机制无关、始终成立的设计模式
无论令牌由什么运输——referrer 字符串、剪贴板，甚至概率匹配 ID——服务端架构都是同一套，而把它做对比选哪种运输更重要。不要把整个深度链接塞进通道：把点击上下文存在服务器上，只移动一把短命的钥匙。
用随机令牌为上下文建档
点击时以短随机令牌为键写入 {deep_link, campaign, timestamp}，通道里只放令牌。负载保持小巧，活动数据不会散落在剪贴板和 referrer 日志里，而且"上下文"的含义可以随时调整而不动客户端。
激进地过期
30 到 60 分钟的 TTL 足以覆盖真实的点击到安装旅程。点击一周后才解析的延迟路由，错的次数比对的多。
强制一次性使用
首次兑换即消费令牌。referrer 字符串留在设备上，剪贴板可以被读两次；没有一次性约束，重装或第二台设备就能重放别人的上下文。
失败时回落到默认，而不是去猜
没有令牌、令牌过期、粘贴弹窗被拒——让用户落在正常首页。通用的首次打开只是小小的遗憾；被路由进别人的购物车是一张工单。
可靠性，说实话
来自在生产环境跑这些机制的团队的粗略数字。你的流量来源组合、安装延迟和受众的 iOS 版本都会让每个数字移动。
| 机制 | 平台 | 可靠性 | 备注 |
|---|---|---|---|
| Play Install Referrer | Android | 高 | 官方 API，延迟安装也能存活，无用户弹窗。仅限 Play 安装。 |
| 剪贴板令牌 | iOS | 中 | 受 iOS 16+ 粘贴弹窗限制；拒绝是无声的；剪贴板易失。 |
| 概率匹配 | iOS | 低–中 | IP + 型号 + 时间窗。在 Private Relay 和 CGNAT 下持续退化；Apple 不鼓励。 |
| App Clip 交接 | iOS | 高但狭窄 | 确定性强，但只适合值得为其构建 App Clip 的流程。 |
这对你的技术栈意味着什么
如果你的延迟路由需求只在 Android，你需要的东西很少：一条会追加 referrer 参数的链接、那个小库、一个兑换令牌的端点。一个下午的工作量，而且在真正要紧的意义上无 SDK——没有第三方代码在观察你的用户。
iOS 才是托管方案挣饭吃的地方，因为在那里变通方案本身就是产品：维护匹配基础设施、围绕粘贴弹窗做设计、追踪每一个改变地形的系统版本。这也是它按基础设施定价的原因——Appy 在 Enterprise 层级提供延迟深度链接，把这份维护变成供应商的问题而不是你的。
不过要诚实面对自己的问题是哪一个。如果你真正需要的是"已装应用的用户落到正确页面"，那是标准深度链接——不存在安装边界。Appy 的深度链接垫片在 Pro 套餐（每月 9.99 美元）覆盖这种场景，含商店回退，同样无 SDK。在购买更重的机器之前，先量一量漏斗里有多少是真正带上下文的新装。
常见问题
扫二维码也能用 Install Referrer 吗？
能，前提是二维码经由一条会把 referrer 参数追加到 Play URL 的链接解析。机制不关心点击怎么开始——扫码、点击还是 NFC——只关心 Play 打开时商店 URL 是否带着 referrer。直接指向裸 Play URL 的二维码什么都带不了。
我的剪贴板令牌方案为什么突然坏了？
几乎可以肯定是 iOS 粘贴弹窗。从 iOS 16 起，应用第一次读剪贴板会触发系统权限对话框，相当比例的用户会拒绝。你的代码没有退化；你的读取环节里现在多了一个人。看看令牌命中率是下降而不是归零——那就是它的签名。
iOS 上到底允不允许指纹匹配？
灰色地带，而且形势对它不利。Apple 的准则禁止以跟踪为目的的指纹识别，privacy manifest 要求申报你收集的信号及原因，App Review 也因此拒过应用。有些厂商仍在卖。自己构建就自己扛风险，并且无论如何都应假设准确率会继续下滑。
我到底需不需要延迟深度链接？
只有当安装后的落地页面对漏斗有实质影响时才需要。如果大多数安装来自没有具体目的地的通用投放，一个好的引导流程比延迟路由更值钱。先测量：数一数存在真实深度链接目标且应用未安装的点击。数字小，就把精力花在别处。
继续探索
延迟深度链接（deferred deep linking）：原理与使用时机
把原始链接意图带过安装环节，让新用户首次打开应用就直接进入对应页面，而不是默认首页。
iOS 和 Android 通用链接完整指南
关于通用链接、深度链接和 App Links 的完整指南，包含实现方法与移动营销实践。
iOS 26 链接跟踪保护：哪些 URL 参数能活下来？
Safari 会剥离 gclid、fbclid 等点击标识符，UTM 参数照常通过。了解这对应用安装归因的影响，以及第一方链接如何保住归因。
想看更多内容？浏览 博客全部主题.