更新时间：2026年8月19日
用户点击广告、短信或社交媒体链接后，如果已经安装App，最好直接进入对应的商品、活动或订单页面；如果没有安装App，则可以先进入应用商店，并在完成安装后尽量恢复用户原本想访问的页面。
实现这类体验的核心技术就是Deep Link，也常写作Deeplink或Deep Linking。
简单来说：
Deep Link是一种能够让App识别目标内容，并打开指定页面的链接或路由机制。
它解决的是“用户进入App后应该去哪里”，但不会自动解决广告归因、安装匹配和数据分析问题。
Deeplink是如何工作的？
下面是一个自定义Scheme形式的Deep Link：myapp://product/123
链接中的信息可以拆分为：
- Scheme：myapp
- Route：product
- Content ID：123
App收到链接后，根据内部路由规则打开编号为123的商品详情页，如果使用HTTPS应用链接，格式可能是：https://www.example.com/product/123
用户已经安装App时，操作系统验证域名与App的关联关系，然后把链接交给App处理；未安装App时，则继续打开对应网页。
已安装App时的基本流程是：
用户点击链接 → 操作系统或浏览器识别链接 → 判断哪个App可以处理 → App接收URL和参数 → 内部路由解析→ 打开目标页面
Deep Link最大的价值，是让用户跳过App首页和多次查找，直接进入目标内容。
Deeplink的三种主要实现方式
移动App常见的Deep Link实现包括：
- Custom URL Scheme
- iOS Universal Links
- Android App Links
它们都能打开App页面，但识别机制、安全性和未安装App时的处理方式不同。
Custom URL Scheme
URL Scheme是较早期、也最简单的Deep Link方式。
格式如下：myapp://product/123?campaign=spring，开发者需要在App中注册 myapp 这个Scheme，并配置能够处理 product/123 的页面路由。
优点
- 实现相对简单；
- iOS和Android均可支持；
- 适合App之间的直接跳转；
- 可作为部分旧系统或特殊平台的兼容方案。
限制
自定义Scheme不是由域名所有权验证的。其他App可能注册相同Scheme，导致链接冲突、选择错误或被劫持。
浏览器、内置WebView和社交媒体App也可能限制自定义Scheme，例如必须由用户主动点击才能调用：
因此，新项目不建议只使用URL Scheme。更常见的方案是：
- iOS：Universal Links为主，URL Scheme为兼容方案
- Android：App Links为主，Intent或URL Scheme为兼容方案
Universal Links：iOS的HTTPS深度链接
Universal Links是Apple提供的HTTPS应用链接机制。
格式与普通网页链接相同：https://www.example.com/product/123
如果用户安装了关联App，iOS可以将该链接交给App处理；如果没有安装，则在浏览器中打开网站内容。
要启用Universal Links，需要同时配置：
- 在网站部署 apple-app-site-association 文件；
- 在App中开启Associated Domains；
- 在AASA文件中声明允许处理链接的App及路径；
- App接收链接并映射到内部页面。
AASA文件没有扩展名，网站域名与App中的Associated Domains配置必须一致。Apple会验证两者的关联关系
优势
- 使用标准HTTPS链接；
- App未安装时可以继续打开网页；
- 经过网站与App关联验证；
- 降低自定义Scheme冲突和劫持风险；
- 同一链接可以同时服务网站和App。
但它并不保证每次点击都一定打开App。用户设置、浏览器、当前访问环境及内置WebView都可能影响最终行为。
Android App Links
Android App Links是Android提供的已验证HTTPS深度链接机制。
格式同样是普通HTTPS链接：https://www.example.com/product/123
要启用App Links，通常需要：
- 在Android Manifest中配置URL Intent Filter；
- 设置 android:autoVerify=”true”；
- 在网站的以下位置部署验证文件：https://www.example.com/.well-known/assetlinks.json
- 在文件中配置App Package Name和SHA-256签名证书指纹；
- 在App中解析链接并执行页面路由。
Android会验证网站与App之间的关联。验证成功后，匹配的链接可以直接交给App处理，降低弹出应用选择窗口或被其他App接管的风险。
需要注意：
- assetlinks.json必须通过HTTPS访问；
- 不能经过301或302重定向；
- 使用Google Play App Signing时，需要填写实际发布证书的指纹；
- 不同域名和子域名可能需要分别配置；
- 用户仍可以修改默认打开方式；
- 部分浏览器、WebView和定制Android系统的行为可能不同。
Android 15及以上版本还支持通过 assetlinks.json 配置Dynamic App Links规则，从服务器调整路径、Fragment和Query匹配规则，减少仅为修改链接规则而发布新版App的需要。
Deep Link与Deferred Deep Link的区别
Deep Link适用于用户已经安装App的情况。
Deferred Deep Link通常翻译为“延迟深度链接”，用于用户点击链接时尚未安装App的场景。
- DeepLink（深度链接）：点击链接 → 打开已安装的App → 进入指定页面
- Deferred DeepLink（延迟深度链接）：点击链接 → 记录目标页面及点击信息 → 进入应用商店 → 用户安装App → 首次打开App → 恢复之前的链接数据 → 进入指定页面
两者的主要区别如下：
| 功能 | Deep Link | Deferred Deep Link |
|---|---|---|
| 点击时是否需要已安装App | 是 | 否 |
| 能否在安装后恢复目标页面 | 通常不能 | 可以，但取决于匹配结果 |
| 主要场景 | 用户召回、Push、短信、站内跳转 | 广告拉新、分享邀请、安装活动 |
| 实现难度 | 相对较低 | 较高 |
| 是否需要保存点击信息 | 不一定 | 需要 |
| 是否等于广告归因 | 否 | 否 |
| 匹配准确性 | 已安装时通常较高 | 受系统、渠道和隐私限制 |
Deferred Deep Link为什么更复杂？
Universal Links和App Links只能处理当前设备上已经安装的App。
当用户点击链接时尚未安装App，会发生一次流程中断：
浏览器→ 应用商店→ 安装→ 首次打开AppApp安装后，原来的浏览器URL通常不会自动传入App。因此，需要在安装前保存点击信息，并在首次打开时把新安装与之前的点击进行匹配。
- 对于Android：以通过Google Play Install Referrer API读取
- 对于iOS：可以使用 MMP实现，但会受到ATT、Private Relay、浏览器环境和广告平台数据开放程度的影响，因此不能承诺所有iOS安装都能100%恢复目标页面
Deeplink在营销中的作用
| 场景 | 作用 |
| 广告投放 | 点击广告后直接进入商品、优惠或活动页面 |
| 用户召回 | 从Push、短信或邮件进入指定App页面 |
| 分享邀请 | 打开分享内容，并传递邀请码或内容ID |
| 新用户安装 | 安装后尽量恢复用户原来的访问目标 |
| 跨端体验 | 让网站内容与App内容使用统一HTTPS地址 |
| 数据分析 | 记录链接接收、路由结果和后续转化 |
Deep Link能够缩短用户路径，但能否提升转化率仍需要通过实验和数据验证，不能把“使用Deep Link”直接等同于“转化率一定提高”。
总结
Deep Link是一种把用户带到App指定页面的链接和路由机制。
现代App推荐使用：
- iOS Universal Links；
- Android App Links；
- URL Scheme作为特定场景的兼容方式。
Deferred Deep Link则进一步处理“点击时没有安装App”的情况，需要保存安装前的目标信息，并在首次打开后完成匹配和路由。
需要特别区分：
Deep Link负责打开正确页面，Deferred Deep Link负责安装后恢复页面，广告归因负责判断安装或转化来自哪个渠道。
三者可以由同一个MMP协助实现，但不是同一个功能。实施时应同时考虑平台验证、Fallback、隐私限制、安全校验、数据埋点和完整测试流程。
