在移动应用投放的世界里，“用户从哪里来” 是一切增长分析的起点。我们过去主要依靠 AppsFlyer 来投放广告、监控渠道表现、判断用户是否来自广告流量（非自然）还是自然流量（Organic）。

但在长期使用后，我们发现了一个很现实的问题：
虽然 AppsFlyer 的后台数据显示 90% 的用户来自广告，但在 App 内通过 onInstallConversionData 获取的回调数据中，只有约 50% 被识别为非自然用户。
也就是说，我们在客户端层面拿到的渠道识别并不精准，直接影响了后续的激励策略和活动效果。

1. 问题的核心：AppsFlyer 的数据延迟与匹配精度

AppsFlyer 本质上是广告归因平台，重点在于跨平台的广告效果分析。
它的数据主要依赖于广告平台的点击、安装上报，以及安装后的匹配模型。
但是这个链路依赖于多方对齐（广告→商店→安装→激活），所以存在延迟、丢失或匹配不上的情况。
换句话说，AppsFlyer 的 后台统计准确，但 客户端实时归因结果不稳定。

2. 新方案的思路：让 Branch 做链接，让 AppsFlyer 做分析

于是我们提出了一个组合方案：

投流依然使用 AppsFlyer 统计渠道数据，但广告链接由 Branch 生成。

这样每个广告渠道、甚至每个广告创意，都可以拥有独立的 Branch 链接。
用户点击广告 → 打开 Branch 链接 → 跳转到应用商店 → 下载并打开 App。
当用户第一次启动 App 时，Branch SDK 能精准拿到用户是从哪个链接进来的、携带了哪些参数。

最终效果：

  • Branch 提供安装前的链路追踪和参数传递；
  • AppsFlyer 继续提供广告层面的归因统计和投放效果分析。

两者结合，我们既能获得渠道层的投放数据，又能在客户端精准识别用户来源。

让人惊讶的是，Branch 能够在“商店安装”这道天然断层中，把信息传递到 App 内。
这背后的关键技术是 Deferred Deep Link（延迟深链）。

它的原理大致如下：

  1. 用户点击广告 → 跳转 Branch 链接；
  2. Branch 记录设备信息、指纹、Referrer 参数；
  3. 用户去商店安装 App；
  4. App 首次启动时，Branch SDK 主动向服务器请求匹配；
  5. Branch 根据安装时的 Referrer 与点击时记录的数据进行匹配，返回当初广告的参数。

因此，即便中间经历了应用商店、卸载再安装，Branch 仍能“记住”用户从哪个广告点进来的。
这也是它被认为是目前归因精度最高的 Deep Link 方案之一的原因。

4. 为什么 AppsFlyer 不用同样的方式？

实际上，AppsFlyer 也支持 Install Referrer API（Android 官方推荐机制），但它的重点在广告归因，而不是深链参数传递。
Branch 则反过来，它并不专注广告分析，而是专注 用户路径还原与参数落地。

简单来说：

  • AppsFlyer： 强在“谁带来了安装”；
  • Branch： 强在“安装后，用户从哪个链接进来、想干什么”。

因此，两者是天然互补的关系。

5. 最终方案总结

我们最终的判断是：

AppsFlyer 负责投放归因，Branch 负责落地追踪。

  • AppsFlyer 继续用于广告投放监测；
  • 每个广告链接由 Branch 生成；
  • App 内集成 Branch SDK，用来获取精准的来源参数；
  • 双方数据结合，既保证营销数据可量化，又能在产品端精确识别广告用户。

这样一来，我们既不放弃 AppsFlyer 的强大广告分析，又能通过 Branch 弥补客户端归因的不准确问题。

6. 小结

这次讨论让我们重新认识了一个事实：

“广告归因” 和 “深链识别” 虽然看似一体，其实是两套逻辑。

AppsFlyer 关注广告端的“谁带来安装”；
Branch 关注用户端的“点击到激活的路径”。

当两者结合，我们终于能完整地看到：
用户是从哪里来、经历了什么、又最终落到了哪里。

这才是真正完整的增长链路。