UrlEdge
回到博客
2026年3月16日 UrlEdge 编辑部10 分钟阅读

Firebase Dynamic Links 替代方案：App 下载、QR 码和活动链接怎么迁移

Firebase Dynamic Links 已于 2025 年 8 月 25 日停止服务。若你的 App 下载、QR 码、广告、WhatsApp 或 EDM 链接还依赖旧网址，现在该把需求拆清楚再重建。

代表 App 导流、智能链接与设备分流迁移的手机与笔电

如果你在 2026 年还在找 Firebase Dynamic Links 替代方案，第一步不是立刻找下一个工具，而是先把旧需求拆开。

多数团队真正需要的，通常只有三件事：

  1. 一条自己能控制的品牌 HTTPS 链接
  2. 能按设备做正确分流的路由逻辑
  3. 桌面与手机都清楚可测的回退目标

但不是每个团队都需要完整的延迟深度链接、安装后还原路径，或更复杂的移动归因。这个差异很重要，因为它会直接决定你的替代方案是「轻量的设备导流」，还是「需要另外搭配 App 端与归因工具的完整堆叠」。

根据官方 Firebase Dynamic Links FAQ，Firebase Dynamic Links 已在 2025 年 8 月 25 日 停止服务。如果你的二维码、WhatsApp 消息、EDM、LinkedIn、Meta / TikTok 广告、短信、App onboarding 或下载页还绑在旧网址上，现在最安全的做法是把链接层改建成你自己能掌握的组合：自定义域名、HTTP 跳转、原生 App Links / Universal Links，以及明确写清楚的回退目的地。

如果这波调整刚好碰上域名搬家、App 改版或官网改版，建议同步打开 网站迁移跳转检查清单。Dynamic Links 迁移失败的原因，和网站迁移其实很像：清单不完整、规则定义不清楚、上线前没做真机测试。

多数团队以前到底拿 Firebase Dynamic Links 做什么？

当团队说「我们需要 Firebase Dynamic Links 替代」，通常是指以下其中一种：

  1. iPhone 用户导到 App Store，Android 用户导到 Google Play
  2. 桌面访客导到官网落地页、下载页或 QR 码页
  3. 用品牌短链接取代冗长的商店网址
  4. 保留 UTM 或活动参数，让成效追踪不断线
  5. 已安装 App 的用户可以直接打开 App

这些需求听起来像同一件事，但其实不是。

例如：

  • 商店回退与设备分流，本质上是 HTTP 跳转问题
  • 已安装 App 直接开启，是 Android App Links 与 Apple Universal Links 的问题
  • 安装后还原深层页面，常常需要 App 端逻辑或另外的归因平台配合
  • 活动参数保留，是跳转质量与查询参数保留问题，而不是「有没有短网址」而已

[!TIP] 最快也最省成本的迁移方式，通常不是逐项复制 Firebase 原本所有功能，而是先确认你真正需要保留的是哪几种行为。

先用这个判断树分类

你只需要智能链接式分流

如果你的需求是：

  • iOS -> App Store
  • Android -> Google Play
  • 桌面 -> 官网、下载页或 QR 页

那么一层稳定的设备导流通常就够了。这正是 UrlEdge 设备导流 这类工具最适合处理的范围。

你需要已安装 App 直接打开

如果你希望：

  • iPhone 上已安装 App 时直接开启 App
  • Android 上已安装 App 时直接开启 App
  • 未安装者再回落到商店或 Web

那你需要同时完成两件事：

  1. 一层能控制路由与回退目标的链接平台
  2. App 与域名侧正确设置的原生关联档

也就是说，你得把 AASA、assetlinks.json 与 App 端路径处理都设完整。光换掉短网址服务，不会自动帮你把原生深度链接行为修好。

你还需要 deferred deep linking 或归因

如果你的成长团队很依赖：

  • 安装归因
  • 安装后打开指定画面
  • 安装前后的 campaign matching

那就不要假设任何通用跳转工具都能全部接手。这种情况更实际的做法通常是：把品牌链接与设备路由交给可控的跳转层，归因与安装后状态交给你的移动归因工具。

一个比较实际的替代架构

很多团队迁移后，最稳定的架构通常长这样：

以品牌智能链接、设备分流与商店回退为核心的导流架构示意图

smart.yourbrand.com/promo
  -> 在 Edge 检测设备
  -> iOS：导向 App Store 或 Universal Link 目标
  -> Android：导向 Google Play 或 App Link 目标
  -> Desktop：导向活动落地页、说明页面或 QR 码交接页

这种架构的好处是：

  • 网址与域名掌握在自己手上
  • 回退目标 可明确定义、可真机测试
  • 营销链接 不再绑死单一厂商
  • 未来要加上 UTM、地区规则、短期覆写 都更容易

对新加坡 / 马来西亚 / 海外华人市场的 App 团队来说，这很适合用在：

  • WhatsApp、EDM、LinkedIn 或短信导流
  • Meta / TikTok / Google 广告下载链接
  • EDM、会员推播、KOL 合作链接
  • 线下 QR 码与海报下载页
  • 官网下载按钮与产品 onboarding

对同时覆盖港澳或东南亚的团队来说，这种做法同样好维护，因为你可以在同一条品牌网址下，另外再补上区域与语言差异，而不必再为每个市场重新散落多组链接。

迁移步骤建议

第 1 步：盘点所有还活着的 Dynamic Links

不要凭印象迁移。

至少从这些地方把现有链接拉出来：

  • 广告投放清单
  • EDM 与 CRM 模板
  • WhatsApp、EDM 与 LinkedIn 内容
  • 社交主页、私域菜单与活动素材
  • QR 码海报、包装、简报与展场素材
  • App onboarding、邀请机制、Referral 流程
  • 合作伙伴文件或客服回复模板

建议做一张表，至少要有这些字段：

old_dynamic_link,owner,use_case,ios_destination,android_destination,desktop_destination,notes
https://xyz.page.link/sale,growth,app_download,https://apps.apple.com/app/...,https://play.google.com/store/apps/...,https://yourbrand.com/sale,春季活动

很多团队最容易翻车的地方，不是技术实现，而是迁移时只搬了“大家想得到的链接”，却漏掉还在 QR 码、旧 EDM 或客服 SOP 里默默被使用的 URL。

第 2 步：依「行为」分类，而不是依「来源管道」分类

不要用「这是广告链接」、「这是 EDM 链接」来分类，因为同一个管道里也可能有完全不同的导流需求。

更实用的分法是：

  1. 只要商店回退
  2. 只要网页回退
  3. 需要原生 App 打开 + 回退目标
  4. 需要特殊活动、地区或设备逻辑

这样你才知道哪些链接只要跳转层就够，哪些真的要动到 App 端。

第 3 步：把品牌链接搬到自己的域名

如果可以，迁移时不要再依赖平台提供的通用短域名。用你自己控制的品牌域名，通常有这些好处：

  • SSL 与 DNS 完全由你掌控
  • 长期品牌资产不被平台绑架
  • 比较容易管理活动、SEO 与法务风险
  • 未来换供应商时成本更低

常见做法像：

  • go.yourbrand.com
  • link.yourbrand.com
  • app.yourbrand.com

对多市场团队来说，这也比把所有 App 链接混在主官网域名上更好治理。

第 4 步：把每个平台的回退目标写清楚

不要只写「有回退」。

请具体到这种程度：

  • iPhone -> App Store
  • Android 手机 -> Google Play
  • 桌面 -> 官网下载页或含 QR 码的说明页面
  • 平板 -> 依产品实际情况决定导去商店还是网页

如果你本来就知道不同设备的目的地不一样，直接用 设备导流规则 会比把所有状况塞进单一通用页再跳一次来得干净。

第 5 步：把原生 App Links / Universal Links 设好

如果需求包含「已安装 App 要直接打开」，那就必须补完整个原生链路：

这是很多团队最容易低估的部分。跳转层可以把流量送对地方，但它没办法代替你的 App 去理解或接手路径。

第 6 步：用真机与真实场景测试

至少要测：

  • iPhone Safari
  • iPhone 内建 App 内浏览器
  • Android Chrome
  • Android 内建 App 内浏览器
  • 桌面 Chrome
  • 桌面 Safari

也要测这些状态：

  • App 已安装
  • App 未安装
  • 带有 utm_ 参数
  • 从 QR 码扫描进入
  • 从 WhatsApp、短信、LinkedIn、Meta 广告或 EDM 打开

如果要除错，像 跳转检查工具 可以帮你先看清楚实际 hop 与状态码；但最终仍然要回到真机环境验证体验。

最常见的迁移错误

把所有需求混成一团

「导到商店」「打开已安装 App」「安装后回到指定页」是三种不同层级的需求。混在一起会让你不是买太多，就是做太少。

只顾手机，忘了桌面

很多 App 团队把桌面回退当成次要问题，但它其实直接影响广告流量、客服导流、B2B 简报、媒体报导与 QR 码扫描前的理解成本。

没有刻意保留活动参数

如果旧链接带有 utm_source、utm_campaign、gclid、合作伙伴参数或推荐码，请明确测试保留结果。不要假设每个替代方案都会自动帮你带过去。

上线后才开始监控

没有监控的迁移很容易让问题拖很久才被发现。至少要能看：

  • 哪些旧链接还有大量点击
  • 哪些目的地失效
  • 哪些设备回退异常
  • 哪些广告或 QR 活动突然掉转换

这也是为什么很多团队会搭配 分析功能 与 坏链接监控 来处理迁移后的观测。

UrlEdge 适合接手哪些部分？

如果你的核心需求是：

  • 品牌化自定义域名
  • App Store / Google Play 回退
  • 桌面网页回退
  • 设备导流
  • 地区导流
  • query parameter 保留
  • 上线前验证与上线后分析

那 UrlEdge 非常适合拿来担任流量路由层。

它特别适合这些团队：

  • 想把 App 导流规则从 App 发版周期中解耦
  • 需要同时管理广告、QR 码、社交与官网下载链接
  • 不想再把短网址、设备分流与活动规则散落在不同服务

但如果你的需求包含很重的 post-install attribution 或 deferred deep linking，就应该诚实承认范围，让 UrlEdge 负责可控的路由层，再与原本的 mobile stack 分工。

FAQ

我可以保留一条品牌网址，让所有设备共用吗？

可以，这正是最常见的迁移模式之一。一条品牌网址就能把 iOS 导去 App Store、Android 导去 Google Play，桌面导去官网或 QR 码交接页。

需要。HTTP 跳转与原生 App 关联处理的是不同层级的问题，两者不能互相取代。

通常不会。很多情况只需要设备导流、清楚的回退目标，以及查询参数保留，就能顺利接手。

要一条一条手动搬旧链接吗？

不建议。如果数量一多，最安全的方式是先盘点、分类，再批次定义目的地与例外规则。

相关 UrlEdge 指南

权威参考数据

想用品牌网址接手 App 导流？

用一条品牌链接，把 iPhone 用户导到 App Store、Android 用户导到 Google Play，桌面则导到网页或 QR 码页。

查看设备导流

相关文章

查看全部