Firebase 之后，怎么配置 Universal Links 和 App Links

如果旧的 page.link 还躺在二维码、广告、邮件、下载页或 referral 流程里，你现在要解决的已经不是“找个 Firebase 替代品”这么简单。你真正要解决的是：怎么把公开链接继续维持住，同时不把 App 打开、fallback 和活动追踪搞坏。

因此，先把 Firebase Dynamic Links 以前打包在一起的几件事拆开来看：

1. 对外分发的品牌链接
2. 已安装 App 的原生打开
3. 去 App Store、Google Play 或网页的 fallback
4. UTM 和活动参数保留

根据官方 Firebase Dynamic Links FAQ，它已经在 2025 年 8 月 25 日 停止服务。如果这些旧链接还活在活动投放、二维码、短信、EDM 或产品流程里，最稳妥的做法不是找个“长得差不多”的工具，而是把链接层重新理顺。

Universal Links 和 App Links 各自负责什么

Apple Universal Links

Apple Universal Links 的作用，是让普通 HTTPS 链接在 iOS 上直接打开已安装的 App。成立条件通常包括：

• 域名正确关联到 App
• capability 设置正确
• apple-app-site-association 配置有效
• App 本身能处理收到的 path

Android App Links

Android App Links 是 Android 侧的对应机制。它依赖：

• 已验证的域名
• 正确的 manifest 配置
• 有效的 assetlinks.json
• App 端路径处理

它们本身不能解决什么

即使你把 Universal Links 和 App Links 都配好了，下面这些问题也不会自动消失：

• 桌面端去哪里
• 没装 App 的用户去哪
• 品牌短链接怎么统一分发
• 按设备或环境分流
• UTM 怎么保留
• 活动期间的临时切换怎么做

这些仍然需要一层 redirect / routing 去接。

Firebase 之后更实用的结构

对大多数团队来说，更可维护的结构通常长这样：

go.yourbrand.com/promo
  -> Edge 判断设备
  -> iPhone 且已装 App：Universal Link
  -> iPhone 且未装 App：App Store
  -> Android 且已装 App：App Link
  -> Android 且未装 App：Google Play
  -> Desktop：落地页、文档页或 QR 交接页

这个结构的好处很直接：

• 域名掌握在自己手里
• fallback 行为清清楚楚
• 市场团队对外只发一条干净链接
• mobile、growth、产品可以测试同一条真实路径

真正常卡住团队的，是验证文件

很多团队不是卡在“理解这个概念”，而是卡在：

• apple-app-site-association
• assetlinks.json

尤其当主站跑在 Shopify、Wix、Webflow 或限制较多的 CMS 上时，根路径和 .well-known 文件并不好处理。

这也是 UrlEdge 能帮上忙的地方。custom response 可以把这些文件直接从 Edge 返回出来，不用为了两个验证文件再额外造一条部署链。

实际落地步骤

1. 先把所有公开链接盘出来

重点看：

• 投放中的广告
• 二维码
• 下载按钮
• lifecycle 邮件
• 帮助中心或支持页面
• 社媒 bio
• referral 流程

2. 把“打开 App”和“fallback”分开定义

对每条关键链接，都回答这几个问题：

1. 如果 App 已安装，是否应该直接打开？
2. 如果没安装，应该去商店还是网页？
3. 桌面端应该看到什么？
4. UTM 或活动参数要不要保留？

3. 选定公开分发的主域名

常见做法是：

• go.yourbrand.com
• app.yourbrand.com
• links.yourbrand.com

这样可以避免公开链接层长期绑死在第三方 hostname 上。

4. 校验关联文件

一定要对着官方文档核：

• Apple Universal Links
• Android App Links

如果这一步没配对，即使 redirect 看起来正常，原生打开 App 的体验也会一直不稳定。

5. 把 fallback 写成明确规则

例如：

• iOS 已装 App -> App
• iOS 未装 App -> App Store
• Android 已装 App -> App
• Android 未装 App -> Google Play
• Desktop -> 落地页或 QR 交接页

不要把这部分留到上线时临时决定。

6. 在真实场景里测试

至少要测：

• iPhone Safari
• Android Chrome
• 社媒 App 的内置浏览器
• Desktop
• 手机扫码
• 带 UTM 的链接

这里最容易暴露出“链接能跳”和“用户体验真的对”之间的差距。

常见错误

以为设备导流就等于 Universal Links / App Links

不是。设备导流是选目的地，Universal Links / App Links 负责操作系统层面的可信原生打开。

忘了桌面端

桌面 fallback 一旦没想清楚，支持文档、销售材料、二维码场景都会很容易断。

把 UTM 弄丢

如果链接来自广告、邮件、二维码或社交渠道，参数保留要明确设计，不要指望平台“默认会帮你保住”。

中间层堆太多

短链服务、中转页、旧 redirect 层越多，排障越慢，也越容易出现多跳。

UrlEdge 适合放在哪一层

当你希望把下面这些能力放在同一层管理时，UrlEdge 很合适：

• 品牌公开链接
• 设备分流
• 商店 / 网页 fallback
• UTM 保留
• 点击分析
• 验证文件的 Edge 返回

它并不等于完整的移动归因平台，但它能帮你重新掌控最外层、最影响用户和市场团队的那部分：公开链接和 fallback 行为。

最后总结

Firebase Dynamic Links 之后，最好的答案通常不是再找一个新的黑盒，而是把结构重新搭清楚：

• 品牌域名
• 设备导流
• 配好的 Universal Links 和 App Links
• 明确的 fallback
• 保留下来的活动参数

少一点魔法，多一点可控性。