Deferred Deep Link：是什么、如何运作及在开发中的应用

什么是 Deferred Deep Link？

Deferred Deep Link 是一种分两个阶段工作的深度链接：首先用户在安装应用前点击链接，然后系统在安装完成后恢复上下文。普通 deep link 仅在应用已安装时才能打开应用，而 deferred 会保留所有跳转参数并在首次启动时传递它们。

随着移动营销的兴起，这项技术变得尤其受欢迎，因为广告活动通常针对尚未安装应用的用户。如果没有 deferred deep link，每次这样的跳转只会简单地下载应用而没有任何上下文——用户将进入主屏幕而不是目标屏幕。

与普通 deep link 的区别

普通 deep link 在已安装的应用中打开目标内容。如果应用未安装，浏览器会显示错误。Deferred Deep Link 通过一个中间服务器工作，该服务器将用户重定向到商店，并在安装后通知应用有关已保存的参数。这样，延迟链接不需要事先安装应用，并确保从广告到内容的无缝用户体验。

Deferred Deep Link 如何运作

延迟深度链接的处理过程包括三个阶段。在第一阶段，用户点击链接——服务器确定应用是否已安装。如果没有，它会生成一个唯一的会话标识符，保存跳转参数，并将用户重定向到 App Store 或 Google Play 并带上该标识符。

在第二阶段，用户从商店安装应用。安装并首次启动后，平台的 SDK 连接到服务器，发送设备标识符并接收已保存的跳转参数。在第三阶段，应用处理接收到的数据并自动将用户重定向到目标屏幕。

延迟链接的生命周期

为了在点击链接和安装之间保存参数，使用了不同的机制。在 iOS 中，这是钥匙串（iCloud Keychain）或剪贴板；在 Android 中，是 Install Referrer API。Firebase Dynamic Links 使用浏览器的 localStorage 和商店的推荐链接的组合来传递会话标识符。Branch.io 采用自己的协议，在多个存储中备份数据。

iOS 中的 Deferred Deep Link

在 iOS 中，延迟深度链接是通过 Universal Links 和 Shared Web Credentials 的组合实现的。当用户在应用的网站上点击 Universal Link 时，Safari 浏览器将跳转参数保存到与应用域名关联的 iCloud Keychain 中。从 App Store 安装应用后，iOS 会检查已保存数据的存在，并在首次启动时将其传递给应用。

Apple 不提供用于延迟深度链接的内置 API——实现完全依赖第三方 SDK。Firebase Dynamic Links 使用 passive deferred 机制，其中数据保存在浏览器 cookie 中，并在应用首次启动时通过重定向到特​​定 URL 进行恢复。

iOS 中的限制

从 iOS 14 开始，Apple 加强了隐私规则，这影响了延迟深度链接机制。剪贴板不能再在没有用户明确许可的情况下用于读取数据。iCloud Keychain 也有数据量的限制——每次写入不超过 4 KB。这使得具有唯一会话标识符的服务器解决方案成为上下文传递的首选方法。

Android 中的 Deferred Deep Link

Android 通过 Install Referrer API 为延迟深度链接提供了更灵活的能力。当用户通过链接进入 Google Play 时，商店会记录 referrer——一个带有跳转参数的字符串。安装后，应用通过 Install Referrer API 接收该字符串并从中提取目标上下文。这是 Android 上最可靠的延迟深度链接机制。

对于非通过 Google Play 分发应用，Android 支持推荐 BroadcastReceiver。开发人员可以在安装后发送带有参数的自定义 Intent，应用通过清单中注册的 BroadcastReceiver 接收它。然而，这种机制不太可靠，因为它依赖于安装程序的实现。

Install Referrer API

Install Referrer API 提供有关安装来源的信息，包括 referrer URL、跳转时间和安装时间。referrer 字符串的最大长度为 8 KB，足以传递所有必需的 deep link 参数。该 API 在装有 Google Play Store 8.3.73 及以上版本的设备上可用，并支持 Android 5.0（API 21）。

通过 Firebase Dynamic Links 实现

Firebase Dynamic Links 是在两个平台上实现延迟深度链接的最流行的免费工具。Firebase 自动管理延迟跳转的所有阶段：在应用不存在时重定向到商店，在 Firebase 服务器上存储参数，并在应用首次启动时将其传递给 SDK。

为了实现，只需将 Firebase SDK 集成到项目中，通过 Firebase Console 创建一个 Dynamic Link，指定深度链接和活动参数。Firebase SDK 在应用启动时自动调用，并通过 getDynamicLink() 方法检查传入的 Dynamic Link 是否存在。

处理配置示例

在 Kotlin 的 Activity 中处理延迟 Firebase Dynamic Link 的示例。代码在应用启动时对冷启动和热启动都有效。

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        checkDeferredLink()
    }

    private fun checkDeferredLink() {
        FirebaseDynamicLinks.getInstance()
            .getDynamicLink(intent)
            .addOnSuccessListener link ->
                val deferredLink = link?.link.toString()
                if (deferredLink.isNotEmpty()) {
                    navigateToContent(deferredLink)
                }
            }
    }
}

getDynamicLink() 方法返回带有 DynamicLink 对象的 PendingTask。如果应用是在点击链接后安装的，监听器将接收带有参数的数据。如果应用在点击前已安装，该方法将返回与普通 deep link 相同的数据。链接参数中的 minimumAppVersion 标志允许设置用于处理的应用最低版本。

Deferred Deep Link 的优势和限制

Deferred Deep Link 为营销活动提供了显著的优势：用户在安装后无需额外操作即可获得目标内容，从而提高了转化率和留存率。对于推荐计划，延迟链接可以明确地将邀请与安装和新用户的操作联系起来。

然而，该技术也有局限性。延迟深度链接在阻止第三方 cookie 的浏览器中无法工作，在 iOS 14 及以上版本需要额外配置才能与 iCloud Keychain 一起工作。此外，从点击链接到安装之间可能经过 几天，并非所有 SDK 都能保证在此期间的数据保存。

何时使用延迟深度链接

延迟深度链接对于针对新用户的广告活动、带有邀请的电子邮件和推荐计划是必需的。对于已安装的用户，普通 deep link 就足够了。如果应用不使用营销活动和推荐机制，则不需要延迟深度链接——Universal Links 和 App Links 就足够了。

在选择实现时，请考虑 成本：Firebase Dynamic Links 是免费的，但分析功能有限。Branch.io 和 AppsFlyer 提供高级归因，但需要订阅。对于小型项目，Firebase 是最佳解决方案；对于拥有数十个广告渠道的企业，则是商业 MMP。