先试 App，再试应用商店，最后是网页
一条移动端链接为每个平台准备了三个答案：能打开 App 的地址、作为回落的应用商店页面，以及应付其余所有情况的网页。跳转按这个顺序依次尝试，间隔时长由你控制——因为要判断一个 App 是否已安装，唯一靠得住的办法就是试着打开它，再看这个页面之后是否还在。
Apple 和 Google 都支持经过校验的关联文件，让一个域名可以直接打开 App，中间不出现可见的中转页。平台会从你的跳转域名提供这些文件，并替你做诊断——内容类型不对、路径不对、缺少签名指纹——因为一份填错的关联文件只会悄无声息地失效，然后所有人都去怪那条链接。
- 逐平台设置 App scheme 或 universal link
- iOS 与 Android 各自的应用商店回落
- 面向桌面端和不受支持平台的网页回落
- 在你自己的域名上提供并诊断关联文件
- 可配置的尝试间隔
- 针对平板的明确行为设定
应用内浏览器是最难的一环，所以它被单独明确处理
多数移动端流量都是在另一个 App 的浏览器里到达的——社交信息流、即时通讯、邮件客户端。这些环境拦截打开 App 的尝试，方式还各不相同，一条在 Safari 里表现正常的链接，在信息流里可能毫无反应。
所以应用内这种情况是一项设置，而不是一次意外：照样尝试打开 App、直接跳过去打开网页，或者给出一句简短提示、请对方在系统浏览器里打开。这个行为逐条链接选择，平台会识别常见的应用内浏览器，而不是假装它们和普通浏览器没两样。
上下文能挺过安装过程
一个人点开了指向某件具体商品的链接，手机上没有这个 App，于是装了一个——然后落在一个千篇一律的首页上。延迟上下文解决的正是这件事：营销活动和目标会被保留下来，在 App 首次启动时交给它，于是这个人抵达的是链接原本所指的位置，而不是 App 默认打开的位置。
上下文是按设备特征匹配的，而不是靠任何能识别身份的东西，而且它很快就会过期：它存在的意义是衔接一次安装，而不是构建一份画像。
依然是你的品牌，依然是你的数据分析
中转页——在确实需要它的时候——由 edge 使用绑定在该域名上的 logo、颜色和客服邮箱渲染。里面不会出现底层平台的名字，链路上也没有任何第三方主机。
点击在跳转发生时就已记录，早于尝试打开 App：这次访问确实发生了，而设备之后拿它做了什么，从外部是观察不到的。正是这一点让点击量保持诚实，而不是悄悄少报移动端流量。
常见问题
要用这个功能，我需要改动自己的 App 吗？
要能打开 App，你需要一个自定义 scheme，或者经过校验的 universal link，而这两样多数 App 本来就有。要在安装之后接收延迟上下文，App 需要在首次启动时通过 API 把它读出来。除此之外的一切——应用商店回落、应用内浏览器处理、带品牌的页面——完全不需要改动 App。
在桌面端会怎样？
会使用网页回落。deep link 的配置绝不会破坏桌面端这条路径；一条带移动端设置的链接，在所有用不上这些设置的地方，表现得就和一条普通短链接一样。
为什么我有时会看到一张中转页？
因为只有这样，才能先尝试打开 App、再根据结果作出反应。在经过校验的关联文件生效的场景里，操作系统会直接打开 App，不会出现任何页面。而这张页面本身带的是你的品牌，并且远不到一秒就会消失。
如果 App 之后被卸载了，链接还能用吗？
能用。尝试失败，回落随即执行，这个人最终到达应用商店或网页。关于某台设备是否装有该 App，我们不缓存任何信息。