UrlEdge
回到部落格
2026-03-16 UrlEdge 編輯部10 分鐘閱讀

Firebase Dynamic Links 替代方案：App 與活動連結要怎麼搬？

Firebase Dynamic Links 已於 2025 年 8 月 25 日停止服務。若你還有 App 安裝導流、QR Code、廣告或 EDM 連結依賴舊網址，現在該把需求拆清楚再重建。

代表 App 導流、Smart Link 與裝置分流遷移的手機與筆電

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

多數團隊真正需要的，其實只有三件事：

  1. 一條自己能控制的品牌 HTTPS 連結
  2. 能依裝置做正確分流的路由邏輯
  3. 桌機與手機都清楚可測的 fallback

反而不是每個團隊都需要完整的 deferred deep linking、安裝後還原路徑，或更複雜的 mobile attribution。這個差異很重要，因為它會直接決定你的替代方案是「輕量的裝置導流」，還是「需要另外搭配 App 端與歸因工具的完整堆疊」。

根據官方 Firebase Dynamic Links FAQ，Firebase Dynamic Links 已在 2025 年 8 月 25 日 停止服務。如果你的 QR Code、LINE 官方帳號活動連結、Instagram / Facebook 廣告、EDM、App onboarding 或下載頁還綁在舊網址上，現在最安全的作法是把連結層改建成你自己能掌握的組合：自訂網域、HTTP 轉址、原生 App Links / Universal Links，以及明確寫清楚的 fallback 目的地。

如果這波調整剛好碰上網域搬家、App 改版或官網改版，建議同步打開 網站搬家轉址檢查清單。Dynamic Links 遷移失敗的原因，和網站搬家其實很像：清單不完整、規則定義不清楚、上線前沒做真機測試。

多數團隊以前到底拿 Firebase Dynamic Links 做什麼？

當團隊說「我們需要 Firebase Dynamic Links 替代」，通常是指以下其中一種：

  1. iPhone 使用者導到 App Store，Android 使用者導到 Google Play
  2. 桌機訪客導到官網落地頁、下載頁或 QR Code 頁
  3. 用品牌化短連結取代冗長的商店網址
  4. 保留 UTM 或活動參數，讓成效追蹤不斷線
  5. 已安裝 App 的使用者可以直接打開 App

這些需求聽起來像同一件事，但其實不是。

例如：

  • 商店 fallback 與裝置分流，本質上是 HTTP 轉址問題
  • 已安裝 App 直接開啟，是 Android App Links 與 Apple Universal Links 的問題
  • 安裝後還原深層頁面，常常需要 App 端邏輯或另外的歸因平台配合
  • 活動參數保留，是轉址品質與 query string 保留問題，而不是「有沒有短網址」而已

[!TIP] 最快也最省成本的遷移方式，通常不是逐項複製 Firebase 原本所有功能，而是先確認你真正需要保留的是哪幾種行為。

先用這個判斷樹分類

如果你的需求是：

  • iOS -> App Store
  • Android -> Google Play
  • 桌機 -> 官網、下載頁或 QR 頁

那麼一層穩定的裝置導流通常就夠了。這正是 UrlEdge 裝置導流 這類工具最適合處理的範圍。

你需要已安裝 App 直接打開

如果你希望：

  • iPhone 上已安裝 App 時直接開啟 App
  • Android 上已安裝 App 時直接開啟 App
  • 未安裝者再回落到商店或 Web

那你需要同時完成兩件事：

  1. 一層能控制路由與 fallback 的連結平台
  2. App 與網域側正確設定的原生關聯檔

也就是說，你得把 AASA、assetlinks.json 與 App 端 path handling 都設完整。光換掉短網址服務，不會自動幫你把原生 deep link 行為修好。

你還需要 deferred deep linking 或歸因

如果你的成長團隊很依賴：

  • 安裝歸因
  • 安裝後打開指定畫面
  • 安裝前後的 campaign matching

那就不要假設任何通用轉址工具都能全部接手。這種情況更實際的做法通常是：把品牌連結與裝置路由交給可控的轉址層，歸因與安裝後狀態交給你的 mobile measurement / attribution stack。

一個比較實際的替代架構

很多團隊遷移後，最穩定的架構通常長這樣：

以品牌 Smart Link、裝置分流與商店 fallback 為核心的導流架構示意圖

smart.yourbrand.com/promo
  -> 在 Edge 偵測裝置
  -> iOS：導向 App Store 或 Universal Link 目標
  -> Android：導向 Google Play 或 App Link 目標
  -> Desktop：導向活動落地頁、說明頁或 QR handoff 頁

這種架構的好處是：

  • 網址與網域掌握在自己手上
  • fallback 可明確定義、可真機測試
  • 行銷連結 不再綁死單一廠商
  • 未來要加上 UTM、地區規則、短期覆寫 都更容易

對以台灣市場為主的 App 團隊來說，這很適合用在：

  • LINE 官方帳號貼文或選單導流
  • Meta / Google 廣告下載連結
  • EDM、會員推播、KOL 合作連結
  • 線下 QR Code 與海報下載頁
  • 官網下載按鈕與產品 onboarding

對香港也有流量的團隊來說，這種做法同樣好維護，因為你可以在同一條品牌網址下，另外再補上區域與語言差異，而不必再為每個市場重新散落多組連結。

遷移步驟建議

第 1 步：盤點所有還活著的 Dynamic Links

不要憑印象搬家。

至少從這些地方把現有連結拉出來：

  • 廣告投放清單
  • EDM 與 CRM 模板
  • LINE 官方帳號內容
  • 社群 Bio 與限時動態
  • QR Code 海報、包裝、簡報與展場素材
  • 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 Code、舊 EDM 或客服 SOP 裡默默被使用的網址。

第 2 步：依「行為」分類，而不是依「來源管道」分類

不要用「這是廣告連結」、「這是 EDM 連結」來分類，因為同一個管道裡也可能有完全不同的導流需求。

更實用的分法是：

  1. 只要商店 fallback
  2. 只要 Web fallback
  3. 需要原生 App 打開 + fallback
  4. 需要特殊活動、地區或裝置邏輯

這樣你才知道哪些連結只要轉址層就夠，哪些真的要動到 App 端。

第 3 步：把品牌連結搬到自己的網域

如果可以，遷移時不要再依賴平台提供的通用短網域。用你自己控制的品牌網域，通常有這些好處：

  • SSL 與 DNS 完全由你掌控
  • 長期品牌資產不被平台綁架
  • 比較容易管理活動、SEO 與法務風險
  • 未來換供應商時成本更低

常見做法像：

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

對多市場團隊來說，這也比把所有 App 連結混在主官網網域上更好治理。

第 4 步：把每個平台的 fallback 寫清楚

不要只寫「有 fallback」。

請具體到這種程度：

  • iPhone -> App Store
  • Android 手機 -> Google Play
  • 桌機 -> 官網下載頁或含 QR Code 的說明頁
  • 平板 -> 依產品實際情況決定導去商店還是 Web

如果你本來就知道不同裝置的目的地不一樣，直接用 裝置導流規則 會比把所有狀況塞進單一通用頁再跳一次來得乾淨。

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

如果需求包含「已安裝 App 要直接打開」，那就必須補完整個原生鏈路：

這是很多團隊最容易低估的部分。轉址層可以把流量送對地方，但它沒辦法代替你的 App 去理解或接手路徑。

第 6 步：用真機與真實場景測試

至少要測：

  • iPhone Safari
  • iPhone 內建 App 內瀏覽器
  • Android Chrome
  • Android 內建 App 內瀏覽器
  • 桌機 Chrome
  • 桌機 Safari

也要測這些狀態：

  • App 已安裝
  • App 未安裝
  • 帶有 utm_ 參數
  • 從 QR Code 掃描進入
  • 從 LINE、IG、Facebook 或 EDM 開啟

如果要除錯，像 轉址檢查工具 可以幫你先看清楚實際 hop 與狀態碼；但最終仍然要回到真機環境驗證體驗。

最常見的遷移錯誤

把所有需求混成一團

「導到商店」「打開已安裝 App」「安裝後回到指定頁」是三種不同層級的需求。混在一起會讓你不是買太多，就是做太少。

只顧手機，忘了桌機

很多 App 團隊把桌機 fallback 當成次要問題，但它其實直接影響廣告流量、客服導流、B2B 簡報、媒體報導與 QR 掃描前的理解成本。

沒有刻意保留活動參數

如果舊連結帶有 utm_source、utm_campaign、gclid、合作夥伴參數或 referral code，請明確測試保留結果。不要假設每個替代方案都會自動幫你帶過去。

上線後才開始監控

沒有監控的遷移很容易讓問題拖很久才被發現。至少要能看：

  • 哪些舊連結還有大量點擊
  • 哪些目的地失效
  • 哪些裝置 fallback 異常
  • 哪些廣告或 QR 活動突然掉轉換

這也是為什麼很多團隊會搭配 分析功能 與 壞連結監控 來處理遷移後的觀測。

UrlEdge 適合接手哪些部分？

如果你的核心需求是：

  • 品牌化自訂網域
  • App Store / Google Play fallback
  • 桌機 Web fallback
  • 裝置導流
  • 地區導流
  • query parameter 保留
  • 上線前驗證與上線後分析

那 UrlEdge 非常適合拿來擔任流量路由層。

它特別適合這些團隊：

  • 想把 App 導流規則從 App 發版週期中解耦
  • 需要同時管理廣告、QR Code、社群與官網下載連結
  • 不想再把短網址、裝置分流與活動規則散落在不同服務

但如果你的需求包含很重的 post-install attribution 或 deferred deep linking，就應該誠實承認範圍，讓 UrlEdge 負責可控的路由層，再與原本的 mobile stack 分工。

FAQ

我可以保留一條品牌網址，讓所有裝置共用嗎？

可以，這正是最常見的遷移模式之一。一條品牌網址就能把 iOS 導去 App Store、Android 導去 Google Play，桌機導去官網或 QR handoff 頁。

需要。HTTP 轉址與原生 App 關聯處理的是不同層級的問題，兩者不能互相取代。

通常不會。很多情況只需要裝置導流、清楚的 fallback，以及 query parameter 保留，就能順利接手。

要一條一條手動搬舊連結嗎？

不建議。如果數量一多，最安全的方式是先盤點、分類，再批次定義目的地與例外規則。

相關 UrlEdge 指南

權威參考資料

準備好整理你的轉址了嗎？

開始使用 UrlEdge，在 Edge 上管理網址轉址、品牌連結與流量規則。

開始使用

相關文章

查看全部
象徵網域導流、路徑保留與 Edge 基礎設施的伺服器網路線
2026-03-14

換網域時，怎麼保留路徑與 UTM 參數

網域轉址如果只導到首頁，會弄丟深層頁、活動網址與追蹤參數。用保留路徑、保留 query string 與一跳規則，讓舊流量安全抵達新網域。

8 分鐘閱讀