Firebase 之後，怎麼設定 Universal Links 與 App Links

如果舊的 page.link 還留在 QR Code、廣告、Email、下載頁或 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 日 停止服務。如果這些舊連結還活在活動投放、QR、簡訊、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 端 path handling

它們自己不能解決什麼

即使 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. 先把所有公開連結盤出來

重點檢查：

• 投放中的廣告
• QR Code
• 下載按鈕
• lifecycle Email
• 支援頁面
• 社群 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 一旦沒想清楚，支援文件、銷售素材、QR 場景都很容易斷。

把 UTM 弄丟

如果連結來自廣告、Email、QR 或社群，參數保留要明確設計，不要指望平台「預設會幫你保住」。

中間層堆太多

短網址服務、中轉頁、舊 redirect 層越多，排障越慢，也越容易出現多跳。

UrlEdge 適合放在哪一層

當你希望把下面這些能力放在同一層管理時，UrlEdge 很合適：

• 品牌公開連結
• 裝置分流
• 商店 / 網頁 fallback
• UTM 保留
• 點擊分析
• 驗證檔的 Edge 回傳

它不是完整的行動歸因平台，但它能幫你重新掌控最外層、最影響使用者與市場團隊的那部分：公開連結與 fallback 行為。

最後總結

Firebase Dynamic Links 之後，最好的答案通常不是再找一個新的黑盒，而是把結構重新搭清楚：

• 品牌網域
• 裝置導流
• 配好的 Universal Links 與 App Links
• 明確的 fallback
• 保留下來的活動參數

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