推荐订阅源

什么是延迟深度链接

延迟深度链接是一种特殊的技术，能够确保无论用户是否已经安装了对应的 App，都能在点击链接后，被引导到 App 内特定页面或内容，而不是仅仅打开 App 首页。

普通深度链接

普通深度链接适用于用于已经安装 App 的场景，核心目标是唤端和跳转。

sequenceDiagram participant User as 用户 participant App as 目标App participant Web as 网页/广告 Note over User, App: 前提：App已安装 User->>Web: 1. 点击一个深度链接 Note over Web: 链接格式为：<br>myapp://goods/123 Web->>App: 2. 系统直接唤醒App App->>App: 3. 解析链接参数 App->>User: 4. 直接跳转到指定页面

延迟深度链接流程图

延迟深度链接解决了用户未安装 App 的问题，核心目标是引导下载后并安装后，用户还会被引导到 App 内特定页面或内容。

sequenceDiagram participant User as 用户 participant App as 目标App participant Web as 智能落地页 participant Server as 后端服务器 participant Store as 应用商店 User->>Web: 1. 点击广告/链接 Web->>Server: 2. 上报设备信息<br>生成唯一Link ID Note over Server: 存储映射关系：<br>Link ID -> 目标页面 Server->>Web: 返回Link ID Web->>Web: 3. 检测App安装状态 alt 已安装 Web->>App: 3a. 直接唤醒并跳转 else 未安装 Web->>User: 3b. 引导下载 User->>Store: 4. 前往应用商店 User->>Store: 5. 下载并安装App end User->>App: 6. 首次启动App App->>Server: 7. 上报设备信息/Link ID Server->>Server: 8. 智能匹配<br>查询目标页面 Server->>App: 返回最初的目标链接 App->>App: 9. 解析链接 App->>User: 10. 跳转到指定页面

延迟深度链接技术关键点

1. 生成唯一标识：在用户点击链接时，系统会为该次点击创建一个唯一的ID（例如，与设备ID关联或临时存储在云端）。
2. 传递和存储：这个ID会随着用户跳转到应用商店、下载App的整个过程。
3. 首次启动时匹配：当用户安装后首次打开App时，App会向服务器发送这个ID，询问：“这个用户最初是想看什么内容？”
4. 执行跳转：服务器返回最初的目标页面信息，App再执行最终的页面跳转。

主要应用场景

1. 营销和广告：
   • 广告商推广一个具体产品。
   • 用户点击广告后，无论是否安装电商 App，最终都能直达该商品的购买页面，极大提升转化率。
2. 用户推荐和分享
   • 首次打开 App 时，会自动跳转到朋友分享的那条动态页面。
3. 邮件营销
   • 营销邮件中的“限时优惠”链接，能直接引导用户到 App 内的活动页。
4. 推送通知
   • 点击推送通知，直接进入相关的功能模块（比如优惠券页面）。

主流架构和流程

业界最主流和成熟的方案通常基于“指纹识别”和“唯一标识符传递”的组合。其核心思想和工作流程如下：

flowchart LR subgraph A [第一阶段 用户点击] direction LR A1[用户点击<br>延迟Deeplink链接] --> A2[浏览器打开<br>跳转着陆页] end subgraph B [第二阶段 身份关联] direction LR B1[收集设备指纹<br>e.g., IP, UA, OS] --> B2[生成唯一标识符<br>e.g., Fingerprint ID] end subgraph C [第三阶段 意图暂存] direction LR C1[将 Fingerprint ID<br>与目标页面URL<br>关联存储于服务器] end subgraph D [第四阶段 意图还原] direction LR D1[App首次启动<br>收集设备指纹] --> D2[发送指纹至服务器<br>查询匹配的URL] --> D3[服务器返回<br>目标URL] --> D4[App直接跳转<br>至目标页面] end A --> B B --> C C --> D

阶段一：用户点击与初步处理

1. 用户点击延迟Deeplink链接：这个链接通常是一个自定义方案链接或HTTP/HTTPS通用链接。
2. 操作系统路由：
   • 如果 App 已安装，系统会尝试直接打开它。
   • 重点：如果 App 未安装，系统会将其路由到一个预设的网页着陆页。这个网页是实现整个技术的关键枢纽。

阶段二：设备识别与身份关联（关键技术）

着陆页需要完成两项核心任务：

1. 收集设备指纹：通过 JavaScript 代码，尽可能多地收集能标识该设备的匿名信息，例如：

   • IP 地址
   • User-Agent（包含操作系统、浏览器版本）
   • 屏幕分辨率、时区、语言
   • 广告标识符（如 iOS 的 IDFA，Android 的 GAID）—— 在用户授权前提下。

2. 生成唯一标识符：

   • 将上述指纹信息组合，通过哈希算法生成一个唯一的 Fingerprint ID。
   • 同时，服务器会将该 Fingerprint ID 与用户想要访问的**目标页面 URL **关联存储起来，形成一个临时的映射关系。

阶段三：引导下载与意图暂存

1. 引导至应用商店：着陆页上会显示下载按钮，用户点击后跳转到App Store或Google Play。
2. 存储映射关系：在上一步中生成的 Fingerprint ID -> Target URL 的映射关系会被保存在服务器端，并通常会设置一个过期时间（例如24小时）。

阶段四：App首次启动与意图还原

这是实现“延迟”跳转的最后一步：

1. App首次启动：用户下载并安装完成后，首次打开App。
2. 再次生成指纹：App（通过SDK）会收集与网页端类似的设备信息，并采用相同的算法生成一个Fingerprint ID。
3. 查询服务器：App将这个Fingerprint ID发送到服务器，并询问：“这个设备之前有没有保存过一个目标URL？”
4. 执行跳转：
   • 服务器找到匹配的映射记录，将对应的Target URL返回给App。
   • App接收到URL后，解析其中的路径和参数，直接导航到对应的内部页面，完成整个延迟深度链接流程。

关键技术点和挑战

1. 指纹匹配的准确性
   • 挑战: 设备指纹不是100%唯一和稳定的。网络环境变化（如IP变化）、系统设置更新都可能导致指纹改变。
   • 解决方案: 采用概率匹配。系统不会只依赖一个指纹，而是综合多个特征来计算匹配概率。同时，优先使用高精度标识符（如IDFA/GAID）。
2. 标识符传递的备选方案
   • 剪切板: 在网页落地页将标识符复制到系统剪贴板，App首次启动时读取剪贴板内容。这是非常常见且有效的辅助方案。
   • Universal Links/App Links：苹果和安卓提供的原生方案能更好地处理已安装App的情况，但对于“未安装”场景，仍需回落至上述的落地页方案。
3. 安全性
   • 需要对传递的数据进行签名和验证，防止恶意伪造深度链接跳转。
4. 服务端设计
   • 需要设计一个高效、可扩展的kv存储，用于管理大量的临时 Fingerprint ID -> Target URL 映射，并要自动清理过期数据的机制。

业界通常借助成熟的第三方服务，例如 Branch.io、AppsFlyer、Adjust、Firebase Dynamic Links。

quadrantChart title 移动增长平台核心定位矩阵 x-axis "偏重归因与效果衡量" --> "偏重用户互动与体验" y-axis "偏重第三方视角" --> "偏重第一方视角" "Adjust": [0.2, 0.8] "AppsFlyer": [0.3, 0.75] "Branch.io": [0.7, 0.4] "Firebase Dynamic Links": [0.8, 0.2]

特性	AppsFlyer	Adjust	Branch.io	Firebase Dynamic Links
核心价值	归因与营销分析	归因与营销自动化	跨平台身份与用户体验	免费的深度链接
商业模式	第三方/SaaS	第三方/SaaS	第三方/SaaS	第一方/免费
强项	多渠道归因、反欺诈、数据深度	归因精度、自动化、iOS解决方案	延迟深度链接、用户身份图、有机增长	免费、简单、与Google生态集成
弱项	价格较高，功能复杂	价格较高	在纯付费广告归因领域，品牌知名度略低于前两者	功能单一，无独立归因
理想客户	大型买量广告主，寻求中立数据	注重技术和自动化的大型应用	所有注重用户体验和跨平台身份识别的应用	预算有限的开发者，Firebase用户

AppsFlyer 平台延迟深度链接

作为移动归因和营销分析领域的领导者，AppsFlyer 的解决方案非常成熟和典型，其核心是 ”基于链接的标识符传递与智能匹配“。

AppsFlyer 技术架构详解

通过 OneLink ID 来唯一关联一次点击事件。

flowchart LR subgraph A [第一阶段 点击与链接解析] A1[用户点击<br>含af参数的OneLink] --> A2[请求AppsFlyer服务器<br>生成唯一OneLink ID] end subgraph B [第二阶段 设备识别与引导] B1[服务器返回<br>跳转逻辑] --> B2{判断App安装状态} B2 -- 已安装 --> B3[直接唤醒App<br>并传递数据] B2 -- 未安装 --> B4[引导至应用商店<br>同时存储OneLink ID<br>与设备指纹的映射] end subgraph C [第三阶段 安装后首次启动] C1[App首次启动<br>AppsFlyer SDK初始化] --> C2[收集设备信息<br>并上报至AppsFlyer] end subgraph D [第四阶段 智能匹配与深度跳转] D1[AppsFlyer服务器<br>智能匹配OneLink ID] --> D2[服务器下发给App<br>原始的深度链接数据] --> D3[App执行最终<br>的深度跳转] end A --> B B --> C C --> D

阶段一：点击与链接解析

1. 专属链接：广告主创建一个 AppsFlyer 的 OneLink 链接。这个链接内嵌了丰富的参数，例如：
   • af_dp=yourapp://product/123：指定App内目标页面。
   • af_web_dp=https://example.com：指定App未安装时的网页备选方案。
   • pid=facebook：标记广告渠道。
   • c=campaign_name：标记广告活动。
2. 生成唯一标识：当用户点击此链接时，设备会向AppsFlyer服务器发起请求。AppsFlyer服务器会为这次点击生成一个全局唯一的 OneLink ID，并开始记录这次点击事件的所有数据。

阶段二：设备识别与引导

AppsFlyer服务器会根据设备情况做出智能路由：

• 情况A：App 已安装

  • 服务器识别到 App 已安装，会直接通过 Universal Links (iOS) 或 App Links (Android) 唤醒App。
  • AppsFlyer SDK 在 App 内接收并解析来自服务器的数据，并立即执行深度跳转。

• 情况B：App未安装

  • 引导下载：服务器将用户引导至应用商店（App Store/Google Play）。

    • 关键步骤：在此过程中，AppsFlyer会采用多种机制来临时存储 OneLink ID与设备信息的关联：
    1. Cookie/Device ID Matching：在跳转至应用商店的着陆页上，通过浏览器Cookie或收集设备指纹来记录 OneLink ID。
    2. 剪贴板：一个非常可靠的备选方案。在用户点击“下载”前，将 OneLink ID 和必要的链接数据以加密形式写入设备的系统剪贴板。
    3. 概率匹配：作为最后的保障，AppsFlyer会使用设备指纹进行概率性匹配。

阶段三：安装后首次启动与数据上报

1. SDK初始化：用户下载并首次打开App时，集成在App内的AppsFlyer SDK会自动初始化。
2. 收集并上报数据：SDK会收集设备信息，包括：
   • 广告标识符（IDFA, GAID）。
   • 设备型号、操作系统版本。
   • 从剪贴板中读取的数据。
   • 其他设备指纹信息。
3. 这些数据会作为一次“首次打开”事件上报给AppsFlyer服务器。

阶段四：智能匹配与深度跳转

这是实现“延迟”的魔法步骤：

1. 服务器端匹配：AppsFlyer服务器收到“首次打开”事件后，会利用上报上来的设备信息（特别是广告标识符和剪贴板内容）去寻找之前存储的、与之匹配的 OneLink ID 和完整的点击数据。
2. 数据下发给App：一旦匹配成功，服务器会立即将原始的深度链接数据下发给App端的SDK。
3. 执行跳转：AppsFlyer SDK接收到数据后，会通过回调函数通知App开发者。
   • 开发者需要在App中预先编写好处理这些数据的代码，解析 af_dp 等参数，并将用户导航到对应的商品详情页、活动页或内容页。

多触点归因

当用户点击了多个广告但未安装时，AppsFlyer需要解决一个关键的“多触点归因”问题，以确定是哪个广告最终导致了安装。

flowchart TD A[用户点击多个广告后安装App] --> B[AppsFlyer SDK<br>收集设备标识符] B --> C[AppsFlyer服务器执行<br>归因匹配分析] C --> D{Last-Touch归因<br>是否可用?} D -- 是<br>有确定的最后点击 --> E[成功归因<br>引导至对应广告的目标页面] D -- 否<br>无精确匹配 --> F[启用概率模型/聚合数据] F --> G[基于权重分配归因<br>e.g., 第一个和最后一个点击权重更高] G --> H[选择一个“最可能”的广告<br>并引导至其目标页面]

核心归因机制：Last-Touch（最后触点）归因

在理想情况下，AppsFlyer默认使用 “最后触点归因” 模型。这是行业标准，也是最直接的方法。

工作原理：

1. 记录点击流：
   • 即使用户没有立即安装，AppsFlyer也会通过设备标识符（在用户授权前提下）记录该设备最近点击的广告。
   • 关键的标识符包括：
     • iOS：IDFV（同一开发商App间标识符）或SKAdNetwork提供的匿名数据。
     • Android (海外)：GAID。
     • Android (国内)：OAID。
   • 每次点击都会更新这个“最后点击”记录。
2. 安装时的匹配：
   • 当用户安装App并首次启动时，AppsFlyer SDK会收集相同的设备标识符，并上报一次“安装”事件。
   • AppsFlyer服务器收到安装事件后，会用它携带的设备标识符去查询数据库：“这个设备最近点击了哪个广告？”
   • 匹配到的那“最后一个”点击，就会被认定为是引起安装的功臣。

举例说明：

• 用户周一点击了抖音的广告A -> AppsFlyer记录：设备123 的最后点击 = 广告A。
• 用户周三点击了百度的广告B -> AppsFlyer更新记录：设备123 的最后点击 = 广告B。
• 用户周五安装App -> AppsFlyer用 设备123 查询，找到最后点击是广告B。
• 归因结果：这次安装归因于百度的广告B。用户将被引导到广告B指定的目标页面。

然而，现实情况往往更复杂，AppsFlyer有相应的策略来处理。

1. 点击过期与回溯期

广告主可以设置一个 “归因回溯窗口期” （例如7天或30天）。AppsFlyer只会在这个时间窗口内寻找最后一次点击。

• 如果用户点击广告B的时间超出了这个窗口期（比如点击后第8天才安装），那么这次点击将不会被考虑。
• 系统会回溯寻找窗口期内的最后一次有效点击（在这个例子中，就是周一的广告A）。

2. 概率归因与建模

在无法使用精确设备标识符的情况下（例如用户在iOS上拒绝追踪），AppsFlyer会采用概率性归因。

• 工作原理：AppsFlyer利用从那些同意追踪的用户那里收集到的匿名、聚合数据来构建模型。
• 模型会分析：一个安装了App的用户，如果点击了广告A、B、C，他最终转化的概率分布是怎样的。通常会给予第一个点击和最后一个点击更高的权重。
• 应用：当一个无法精确追踪的用户安装了App，AppsFlyer会查看他点击过的广告（通过SKAdNetwork或其他聚合渠道得知），然后使用概率模型计算出哪个广告最有可能是促成安装的原因，并将归因结果和跳转指令分配给这个可能性最高的广告。

3. 基于SKAdNetwork的归因（iOS）

在iOS的隐私框架下，精确的、跨应用的归因已被禁止。AppsFlyer严重依赖Apple的SKAdNetwork。

• 工作原理：

  • 当用户点击广告时，广告网络（如Facebook、Google）会向AppsFlyer等归因平台发送一个“点击通知”。
  • 用户安装App后，AppsFlyer的SDK会通过SKAdNetwork从Apple接收一个加密的“安装验证帖子”。
  • AppsFlyer解密这个帖子，将其与之前收到的点击通知进行匹配。

• 如何关联目标页面？

  • 在SKAdNetwork流程中，广告网络可以在安装验证帖子中携带一个简短的 “签名” 或自定义字段。
  • 这个签名可以在安装后由AppsFlyer SDK读取，并映射回最初点击时设定的目标页面。这实现了在隐私保护框架下的延迟深度链接。

优势和特点

1. 多层匹配策略：
   • 首选匹配：基于高精度的标识符（IDFA/GAID）和剪贴板内容，准确率最高。
   • 概率匹配：当首选匹配失效时，使用设备指纹进行概率性匹配，确保尽可能高的匹配率。
2. 强大的数据承载能力：
   • OneLink不仅能传递目标页面，还能携带丰富的营销数据（渠道、活动、创意等），这些数据都会在归因报告中体现，帮助广告主分析效果。
3. 与归因无缝集成：
   • 这是AppsFlyer最大的优势。同一个 OneLink ID 既用于实现延迟深度链接，也用于完成安装归因。广告主可以清晰地知道，这个用户是由哪个渠道、哪个广告带来的，并且其后续行为（如购买、注册）都能被准确追踪。
4. 支持再归因与老用户唤醒：
   • 延迟深度链接不仅适用于新用户安装，也适用于已安装App的老用户。当老用户点击链接时，同样能唤醒App并跳转到指定内容，同时这次互动会被记录为“再互动”归因。

总结来说，AppsFlyer的延迟深度链接架构是一个以 OneLink ID 为核心、结合了多种设备识别技术和智能匹配算法的复杂系统。它不仅仅是一个跳转工具，更是一个集成了营销归因、用户行为分析的全链路解决方案，为移动广告的精准投放和效果衡量提供了坚实的技术基础。

国内深度链接实现方式

在国内，由于谷歌和苹果的原生服务（Google Play Services、IOS Universal Links）收到网络环境或本地化替代的影响，需要开发者采用一套适应国内生态的组合拳。

国内方案的核心挑战

• 谷歌服务缺失：安卓设备没有统一个 GMS，导致无法使用 Firebase Dynamic Links。
• 应用商店碎片化：国内存在华为、小米等多个主流应用商店，链接需要智能地跳转到正确的商店。
• 系统限制和厂商定制：国内安卓系统对后台进程、链接触发限制更为严格，影响了某些链接的触达率。
• 隐私合规要求：对设备标识符（IMEI、OAID）的采集和使用有严格规定。

主流技术架构和实现方案

国内实现延迟深度链接的技术核心是“多渠道标识符匹配 + 备用方案兜底”。

flowchart TD subgraph A [第一阶段 用户点击] A1[用户点击短链/二维码] --> A2[请求短链服务器<br>解析原始URL与参数] end subgraph B [第二阶段 环境探测与引导] B1[服务器或端探测设备环境<br>e.g., 操作系统, 是否安装App] --> B2[生成并存储<br>唯一链接ID] B2 --> B3{判断App安装状态} B3 -- 已安装 --> B4[通过App Scheme<br>或Universal Link唤醒] B3 -- 未安装 --> B5[引导至对应<br>应用商店下载] end subgraph C [第三阶段 安装后匹配] C1[App首次启动<br>SDK收集设备信息上报] --> C2[服务器进行智能匹配<br>e.g., 链接ID, 设备指纹] end subgraph D [第四阶段 意图还原与跳转] D3[匹配成功] --> D4[服务器下发<br>深度链接数据] D4 --> D5[App解析数据<br>并跳转至目标页面] end A --> B B --> C C --> D

阶段一：链接生成与点击

1. 使用短链：为了避免在社交平台分享长链接时被截断或显得不美观，国内普遍使用短链作为载体。
2. 参数编码：将所有目标页面信息、营销参数（如渠道、活动ID）编码在短链对应的原始URL中。

阶段二：环境探测与智能引导（关键技术）

当用户点击短链后，会访问一个智能跳转中间页。这个页面是技术核心，负责：

1. 环境探测：
   • 判断操作系统：是iOS还是Android。
   • 判断App安装状态：
     • 通过尝试发起自定义Scheme请求来探测。
     • 利用 Universal Links 进行探测。
     • 使用JS桥接方式检查。
2. 生成唯一标识：为本次点击生成一个唯一的Link ID，并与设备信息（指纹）一起暂存在服务器。
3. 智能引导：
   • 如果已安装App：通过Scheme或Universal Link直接唤醒App，并尝试传递数据。
   • 如果未安装App：
     • iOS：直接跳转到App Store。
     • Android：根据User-Agent等信息，判断设备品牌，然后智能跳转到对应的应用商店（如华为手机跳转到华为应用市场）。

阶段三：安装后匹配（“延迟”的实现）

这是实现“延迟跳转”的关键。当用户安装App后首次打开时，集成在App中的SDK会工作：

1. 收集设备标识：SDK会收集当前设备的可用标识符。
2. 上报服务器：SDK将这些标识符和SDK初始化事件上报到延迟深度链接的服务端。
3. 智能匹配：服务端利用上报的标识符，与阶段二存储的Link ID和设备指纹进行匹配。匹配成功后，即可确定用户最初想访问的目标页面。

阶段四：意图还原与跳转

服务端将匹配成功的深度链接数据（目标URL和参数）下发给App。App接收到数据后，解析并跳转到对应的内部页面。

关键技术点

1. 核心标识符：OAID

   • 由于国内限制获取IMEI，中国移动安全联盟推出了 OAID 作为替代设备标识符。这是国内安卓生态中进行设备匹配的最重要标识符。
   • 各大手机厂商和应用商店都支持OAID，SDK需要集成获取OAID的能力。

2. 备用方案：剪贴板

   • 剪贴板是国内实现延迟深度链接的王牌备用方案，可靠率极高。
   • 流程：在中间页引导用户下载时，将深度链接所需的参数（或一个Token）加密后写入系统剪贴板。App首次启动时，SDK第一时间读取剪贴板内容，并解析出参数，完成跳转。

3. 多渠道商店跳转

   • 中间页需要维护一个庞大的设备-应用商店映射表，以确保能准确跳转。

4. 自建 vs. 第三方服务

   • 自建：大型公司（如阿里、腾讯、字节）拥有自己的技术团队，会自建整套系统，以更好地与自身业务集成。

   • 第三方服务：中小型公司更倾向于使用成熟的第三方服务，例如

     • 友盟+
     • TalkingData
     • OpenInstall
     • MobTech

     这些服务提供了封装好的SDK，处理了复杂的匹配逻辑和应用商店跳转，开箱即用。

识别手机有没有安装目标应用（“唤端检测” 或 “App存在性检查”）

目前业界并没有一种百分之百完美的方法，而是采用一套分层、概率性的综合判断策略，其核心决策流程可以概括为下图所示的步骤：

flowchart TD A[用户点击广告] --> B[Landing Page<br>加载并执行检测] B --> C{尝试通过URL Scheme<br>唤醒App} C -- 成功 --> D[判断为“已安装”] C -- 超时/失败 --> E[判断为“未安装”] D & E --> F[执行相应操作<br>唤端或跳转商店] F --> G[上报检测结果<br>用于优化模型]

1. 前端异步探测（最核心、最常用）

这是目前最主流的方法，原理是利用自定义URL Scheme尝试唤醒App，并根据反应来判断。

• 原理：
  1. 在广告的落地页中，嵌入一段JavaScript代码。
  2. 这段代码会尝试创建一个隐藏的<iframe>或直接使用window.location，跳转到目标App的自定义URL Scheme（例如 yourapp://）。
  3. 同时，启动一个计时器（例如100ms到300ms）。
• 判断逻辑：
  • 如果App已安装：浏览器会尝试将跳转请求传递给操作系统，操作系统会唤醒App。这个过程会“挂起”浏览器的当前页面或导致页面失去焦点。
  • 如果App未安装：跳转会失败，浏览器会停留在当前页面。
  • 通过计时器判断：在设定的计时器结束时，检查页面是否仍然处于活动状态（或检查document.hidden等属性）。如果页面仍然活跃，则判断为“未安装”；如果页面在超时前就已失去焦点/被挂起，则判断为“已安装”。
• 优点：相对准确，速度快，用户体验较好。
• 缺点：
  • 误判（False Positive）：有些浏览器或移动端环境会拦截快速的Scheme跳转，导致即使App已安装，检测也失败，被误判为“未安装”。
  • 概率性：本质上是一种基于时间和行为反应的猜测，并非绝对可靠。

2. 通用链接与App Links探测

这是苹果和安卓提供的官方方案。

• 原理：
  • Universal Links：普通的HTTP/HTTPS链接。如果用户安装了App，点击此链接会直接打开App；如果未安装，则会在Safari中打开对应的网页。
  • App Links：安卓上的类似技术。
• 如何用于检测：可以通过JavaScript监听页面是否被加载，来判断用户是被跳转到了App（意味着已安装）还是留在了网页（意味着未安装）。
• 优点：是官方方案，体验最流畅，不会被浏览器拦截。
• 缺点：
  • 配置相对复杂。
  • 一旦用户点击了Universal Link，其后续行为就脱离了H5页面的控制范围，难以进行复杂的后续逻辑（如再归因）。

3. 本地存储查询

• 原理：在用户第一次成功唤醒App或完成其他操作后，在浏览器的LocalStorage或Cookie中做一个标记（例如 app_installed=true）。
• 判断逻辑：下次用户访问落地页时，先检查是否有这个标记。如果有，则直接尝试唤端。
• 优点：对于回头客非常准确和快速。
• 缺点：只对已经交互过的用户有效，无法解决新用户的检测问题。

4. 服务器端辅助判断

• 原理：利用服务器存储的历史数据进行概率性匹配。
• 判断逻辑：
  1. 当用户点击广告时，服务器记录其设备信息（如IP地址、User-Agent等，生成一个设备指纹）。
  2. 如果之后有来自相似/相同设备指纹的用户完成了App安装（通过归因SDK上报），服务器会记录这个设备“已安装”。
  3. 当同一个设备再次点击广告时，服务器就可以基于历史数据，高概率地判断其已安装，并直接建议前端进行唤端。
• 优点：能提高回头客和已知设备的准确率。
• 缺点：隐私政策限制越来越严格，设备指纹的准确性在下降；且无法解决全新设备的判断问题。

5. 综合策略与最佳实践

• 标准流程：

  • 首选方案：对于新用户，默认使用前端异步探测。

  • 官方方案辅助：同时配置Universal Links/App Links作为补充或主要唤端方式。

  • 本地缓存优化：对于检测到已安装的用户，在本地做标记，下次直接唤端，提升效率。

• 兜底方案：

  • 当判断为“未安装”时，显示下载按钮，引导用户去应用商店。

  • 在引导下载的过程中，使用剪贴板将深度链接参数复制下来，确保用户安装后打开App能直达目标页面，实现延迟深度链接。

• 数据反馈与优化：

  • 将前端检测的结果（无论成功与否）上报给数据分析平台。

  • 结合最终的归因数据（即用户是否真的安装了App），来不断校准和优化前端探测的超时时间等参数，形成一个闭环优化系统。

识别第一次安装

1. 使用本地存储标志（最常用、最基础的方法）

这是最简单、最直接的方式。原理是：在App的私有存储空间（如 SharedPreferences on Android, UserDefaults on iOS, 或本地文件）中，写入一个特定的标志位。

• 工作流程：
  1. 首次启动检查：App启动时，检查本地存储中是否存在一个特定的键值对（例如 is_first_launch）。
  2. 条件判断：
     • 如果不存在：则判定为第一次启动。然后App会立即将这个键的值设置为 true（或一个时间戳）。
  3. 执行首次逻辑：在设置标志位之后，执行只有首次启动才需要做的事情，如显示新用户引导页、初始化数据库、请求关键权限等。
  4. 后续启动：此后每次启动，检查该标志位都存在且为 true，App便知道这不是第一次运行，从而跳过引导页等逻辑。

2. 检查版本升级（识别“第一次安装新版本”）

有时我们不仅需要知道是不是App生命周期的“第一次”，还需要知道是不是当前这个新版本的第一次运行。这通过对比版本号实现。

• 工作流程：

  1. App在本地存储一个值，记录上一次启动时的App版本号（例如 last_version_code）。
  2. 启动时，获取当前安装包的版本号（current_version_code）。
  3. 对比这两个值：
     • 如果 last_version_code 不存在 → 全新安装。
     • 如果 last_version_code < current_version_code → 版本升级。
     • 如果 last_version_code == current_version_code → 常规启动。
  4. 根据判断结果，可以决定是显示全新的引导页，还是只显示这个版本的“新特性提示页”。

3. 利用归因SDK和服务器端验证（用于广告归因）

在广告投放场景下，识别“第一次安装”至关重要，这直接关系到广告效果的归因（判断用户是从哪个广告渠道来的）。这个能力主要由第三方归因SDK提供，如 AppsFlyer, Adjust, 友盟+ 等。

• 工作流程：
  1. SDK集成：在App中集成归因SDK。
  2. 首次启动上报：当App第一次安装并启动时，SDK会向它的服务器发送一个“首次打开”或“安装”事件。
  3. 设备标识符：SDK会收集设备的匿名标识符来唯一标识这次安装（在用户授权和合规前提下）：
     • iOS：IDFA 或 SKAdNetwork 数据。
     • Android (海外)：GAID。
     • Android (国内)：OAID。
  4. 服务器端匹配：归因服务器会检查这个设备标识符是否之前已经上报过。
     • 如果从未上报过 → 判定为全新的自然安装或可归因的广告安装。
     • 如果已经上报过 → 判定为重新安装或重复激活，通常不作为有效的新安装进行归因。

这种方式不仅能识别出是第一次安装，还能精确地告诉广告主，这次安装是来自于哪个广告渠道（例如：抖音、百度或Google Ads）。

第一作者：AI