UrlEdge
回到部落格
2026年5月5日 UrlEdge Editorial4 min read

智慧轉址路由：地區、裝置、A/B 測試與條件規則

同一個活動連結，可能要依地區、裝置、語言、UTM、A/B 權重與 fallback 導向不同頁面。本文說明如何設計這層流量規則，而不是把它散落在網站程式裡。

一個連結在 Edge 上依地區、裝置、A/B 測試與 fallback 條件分流的暖色示意圖

如果所有點擊都要到同一個頁面，轉址很簡單。但活動頁、QR code、LINE、App 下載、跨境電商、廣告投放和聯盟連結放在一起時，一個網址常常需要多個判斷。

台灣使用者可能從 LINE 或 QR code 開啟；香港使用者可能需要另一個活動頁；iPhone 應該走 Universal Link 或 App Store；Android 可能走 Google Play 或 Web fallback；桌機使用者則應留在網頁。投放連結還必須保留 UTM、click ID、coupon 和 partner ID。A/B 測試也要讓同一個人維持在同一個版本。

智慧轉址路由就是讓一個公開 URL 背後有一套路由政策，而不是只有單一 destination。

UrlEdge 會把這套政策發布到 Edge。地區、裝置、語言、query、header、cookie、campaign、A/B 權重和 fallback 可以放在同一條規則裡，並搭配 analytics 和 rollback。

一個連結背後需要 policy

常見做法是逐步堆規則：

  • 地區轉址在 CDN
  • 裝置導流在網站或 App middleware
  • A/B 測試用 client-side script
  • UTM 由活動頁處理
  • QR 或 LINE fallback 放在表格
  • 舊轉址還留在主機、CMS 外掛或活動頁設定

活動一改，就很難知道哪一層規則真正生效。

Smart redirect routing policy with geo, device, experiment, and fallback branches

要決定的事為什麼重要
哪個來源符合？網域、路徑、wildcard、regex、活動 slug、QR
看哪些情境？地區、裝置、語言、OS、browser、query、header、cookie
哪個條件優先？safety、campaign、device、country、A/B、fallback
導到哪裡？商店、App Store、Google Play、活動頁、客服頁、fallback
怎麼分流？A/B 權重、灰度、campaign variant、canary
保留什麼？path、query、UTM、affiliate ID、coupon
如何復原？前一個 snapshot、fallback、暫停活動、通知 owner

地區轉址要服務意圖

情境較好的導流
跨境電商依市場提供庫存、幣別、物流和語言
地區活動台灣、香港、海外或 global fallback 分開
未支援地區等候名單、代理商頁或清楚說明
合規限制明確 allowed、blocked、fallback
說明文件真的有本地內容時才導向

Cloudflare Workers 可透過 request.cf 取得國家等 metadata。但技術上能判斷地區，不代表一定要強制轉址。SEO 上要避免 cloaking，canonical 和 fallback 也要清楚。

裝置導流：App、Web、QR 和 LINE

Device and geography decision map for app, store, web, and regional destinations

情境目的地
iOSUniversal Link，或 App Store / mobile web
AndroidAndroid App Link，或 Google Play / mobile web
桌機Web 活動頁、註冊頁或 QR handoff
平板多數情況用桌機 Web
App 內瀏覽器LINE 或社群 webview 可用 bridge page
未知裝置穩定 Web fallback

Firebase Dynamic Links 結束後，許多 App 團隊需要自己管理這層 fallback。UrlEdge 可處理裝置導流；原生 App 開啟仍需要 Universal Links 和 Android App Links。

A/B 轉址適合目的地測試

適合：

  • 活動頁 A vs B
  • 本地 offer vs global offer
  • 新 pricing page 給少量流量
  • 新 storefront canary
  • partner 或 affiliate 頁輪轉

它不是完整 experimentation platform。

A/B redirect split and staged rollout controlled before the page renders

決策建議
狀態碼臨時測試用 302 或 307
一致性回訪者維持同一 variant
SEO不給 crawler 不同體驗
Canonicalvariant URL 不同時要清楚
時間測完就結束
灰度逐步提高權重

Google 對網站測試建議避免 cloaking，將原 URL 導向 variant 時使用 temporary redirect。

條件需要優先順序

優先條件例子
1安全/法務未服務地區到說明頁
2活動覆蓋?campaign=partner 優先
3裝置/OSiOS、Android、desktop 分流
4地區/語言台灣、香港、海外、global
5A/B 權重合格流量才進測試
6fallback其他人到穩定頁

順序錯誤會讓 A/B 吃到應排除的流量，或讓裝置規則弄丟 UTM。

UTM 和 query 也是轉址的一部分

政策適用
全保留來源可信、歸因重要
allowlist只保留 UTM、click ID、affiliate ID
加預設值統一 campaign 或 channel
全刪除目標敏感
重寫參數決定 path 或目的地

歸因常常在轉址當下就壞掉，不是在 analytics 裡才壞。

上線前測整張矩陣

Rule QA and rollback workflow for smart redirect routing

測試地區、裝置、UTM 有無、廣告/LINE/QR/自然/聯盟、A/B 初訪與回訪、status、hop、priority、fallback、analytics 和 rollback。

UrlEdge 適合的位置

FAQ

什麼是智慧轉址路由？

依地區、裝置、語言、query、campaign、A/B 權重和 fallback，把同一 URL 導向不同目的地。

這等於地區轉址嗎？

不是。地區轉址只是其中一個條件。Smart routing 會把多個條件和優先順序一起管理。

A/B 轉址用 301 還是 302？

通常用 302。測試是臨時行為，不適合用永久轉址表示。

References

在 Edge 建立智慧轉址規則

依地區、裝置、語言、參數、A/B 權重與 fallback 導流，不把轉址邏輯埋在網站程式裡。

查看 Smart Routing

相關文章

查看全部