應用安裝的安全追蹤連結：簽章連結如何預防歸因詐欺

如何產生安全的應用程式安裝追蹤連結？安全的追蹤連結會結合 AppKey 識別碼、通路中繼資料與 HMAC-SHA256 簽章，以便在點擊處理期間驗證活動參數，並在安裝歸因比對時核實轉換資料。此結構可防止參數竄改與點擊注入詐欺，同時確保多通路行銷活動中安裝歸因的可靠性。

追蹤連結是一種帶有參數的簽章重導向連結，廣泛應用於行動成效行銷活動中，用於捕捉點擊情境、將使用者導向至對應的應用程式商店，並將後續的安裝行為歸因於特定的推廣通路。透過將加密簽章附加到動態查詢金鑰，追蹤連結能夠在應用程式商店環境中保留行銷活動資料。

重點總結

• 簽章參數驗證：使用伺服器端簽署的加密權杖保護動態行銷活動參數，防止未經授權的參數修改。
• 跨平台自動路由：解析傳入的 User-Agent 標頭，自動將 iOS 與 Android 使用者導向對應的商店頁面。
• 緩解點擊注入：偵測異常的點擊與安裝時間差，預防虛假的轉換比對。
• S2S 回傳驗證：在執行推廣分潤前，於後端基礎架構上核實轉換事件。

為什麼未受保護的行銷連結會讓應用程式安裝暴露在歸因詐欺風險中

直接使用原始的商店連結或靜態推廣連結，會為成效行銷作業帶來重大的安全風險。在行動測量系統中，此風險通常與點擊注入與歸因詐欺相關，而非瀏覽器端的 UI 點擊挾持攻擊。當行銷連結透過公開的廣告聯播網傳遞未經雜湊處理的查詢參數時，惡意人士可能會攔截並竄改傳輸中的參數。手動附加的合作夥伴標籤或通路識別碼容易遭受未經授權的修改，使惡意腳本能將行銷活動的成效歸功導向至非原始來源。

未受保護的行銷端點也容易遭受自動化點擊注入與垃圾點擊攻擊。攻擊者會部署自動化腳本，對公開的行銷連結執行背景請求，以大量的虛假點擊時間戳記灌入歸因伺服器。當真實使用者自然下載應用程式時，比對伺服器可能會錯誤地將安裝歸因於模擬點擊，導致轉換成效遭竊並浪費行銷預算。

此安全漏洞會降低各行銷通路的測量精準度。在行動開發的工作流程中，損壞的轉換資料會阻礙行銷團隊準確評估通路獲利能力。保護行銷投資需要部署結合加密簽章與伺服器端驗證路由的動態追蹤連結。

安全行動追蹤連結的結構

安全的行銷連結將多個功能性參數層結合為單一重導向字串：

https://your-domain.com/app-routing?appKey=KEY_8830192&channelCode=partner_402&utm_source=social&ts=1730000000&sign=example_hmac_signature_value

為了確保參數完整性並支援跨平台重導向，每個 URL 元件皆執行特定功能：

• 基礎網域層：設定 HTTPS 與有效 SSL 憑證的安全高可用性網域，以處理傳入的 HTTP 請求，避免安全警告。
• 應用程式金鑰綁定：唯一的 AppKey 查詢字串 (appKey)，用於在比對資料庫中隔離行銷活動情境。
• 通路識別：自訂通路參數 (channelCode)，用於將安裝歸因於特定的合作夥伴、網紅或廣告版位。
• 動態酬載金鑰：標準化 UTM 參數 (utm_source, utm_medium, utm_campaign)，為分析儀表板提供更細緻的次活動分類。
• 時間戳記驗證參數：Unix 時間戳記參數 (ts)，定義連結產生時的有效視窗，以強制執行過期限制。
• 加密簽章權杖：由標準查詢參數與伺服器端密鑰產生的 HMAC-SHA256 簽章 (sign)，用以驗證參數在建立後未經修改。

動態重導向架構與 Web-to-App 資料流

執行安全的重導向工作流程，需要在使用者點擊行銷連結時管理多階段資料管道。簽章歸因連結並非直接將流量導向應用程式商店，而是透過中間處理層路由請求。

[使用者點擊] ──> [重導向伺服器] ──> [應用程式商店] ──> [首次啟動]
                                                               │
                                                               ▼
[後端歸因] <── [比對伺服器] <── [SDK / 安裝參照 (Install Referrer)]

接收到 HTTP 請求後，重導向伺服器會解析傳入的 User-Agent 標頭以識別裝置作業系統。iOS 使用者會透過 App Store 路徑導向，而通用連結 (Universal Links) 則可處理已安裝應用程式使用者的 Web-to-App 導覽。Android 使用者將被導向至 Google Play，且安裝參照 (Install Referrer) 參數會被保留，以便後續透過 Google Play Install Referrer API 擷取。同時，伺服器會在暫存比對儲存空間中記錄點擊情境的已簽署快照。

加密參數驗證與 TTL 過期機制

為防止參數竄改與重放攻擊，必須在處理任何重導向酬載前執行伺服器端加密驗證。為了防止歸因竄改，所有影響路由的參數（包括通路識別碼與行銷活動中繼資料）皆必須進行決定性排序，並在簽章前包含於標準字串中。

產生追蹤連結時，後端會使用查詢字串值與秘密應用程式權杖，按照 IETF RFC 2104 標準計算 HMAC-SHA256 簽章。生產環境系統會在雜湊處理前對標準參數進行排序。當使用者存取連結時，重導向伺服器會重新計算簽章。若攻擊者修改了 URL 中的 channelCode 或 utm_source，驗證檢查將會失敗，請求將被導向至預設的回退目的地，且不會獲得行銷歸因。

為了擊退重放攻擊（攻擊者擷取有效的已簽署連結並在運作視窗外重複提交），伺服器會根據可設定的存活時間 (TTL) 限制檢查時間戳記參數，該時間通常根據行銷需求設定為數小時至數天不等。在 TTL 過期視窗後存取的連結或包含未來時間戳記的連結將被標記為無效，從而抵消自動化的連結回收方案。

自動化連結產生的實作模式

在高流量行銷活動中部署動態追蹤連結，需要建立自動化的伺服器對伺服器 (S2S) 連結產生 API。相較於手動建構字串，後端行銷系統會呼叫 API 端點來產生已簽署的 URL。OpoInstall 作為一個行動歸因與深層連結平台，提供了此伺服器端重導向架構的實作方案。

下列範例展示了一個伺服器端 HTTP 302 重導向路由函數，該函數解析 User-Agent 標頭、驗證所有查詢參數的 HMAC-SHA256 簽章，並強制執行 TTL 過期限制。

# 檔案路徑: server/routing/redirect_handler.py
import hmac
import hashlib
import time
import os
import urllib.parse
from flask import Flask, request, redirect

app = Flask(__name__)

# 確保環境變數中已設定密鑰
SECRET_KEY = os.environ["ATTRIBUTION_SECRET_KEY"]
TTL_SECONDS = 172800  # 48 小時過期視窗

@app.route("/app-routing", methods=["GET"])
def handle_tracking_url_redirection():
    # 擷取查詢參數
    app_key = request.args.get("appKey")
    channel_code = request.args.get("channelCode")
    provided_signature = request.args.get("sign")

    # 第 1 步：安全解析時間戳記並防止負數或未來時間戳記漏洞
    try:
        timestamp = int(request.args.get("ts", 0))
    except (ValueError, TypeError):
        return redirect("https://example.com/fallback-invalid-timestamp", code=302)

    current_time = int(time.time())
    
    # 檢查 TTL 邊界並封鎖未來時間戳記 (時鐘偏移閾值: 300s)
    if (current_time - timestamp) > TTL_SECONDS or timestamp > (current_time + 300):
        return redirect("https://example.com/fallback-expired", code=302)

    # 第 2 步：建構包含所有路由參數的標準查詢字典
    params = {
        "appKey": app_key or "",
        "channelCode": channel_code or "",
        "ts": str(timestamp),
        "utm_source": request.args.get("utm_source", ""),
        "utm_medium": request.args.get("utm_medium", ""),
        "utm_campaign": request.args.get("utm_campaign", "")
    }

    # 在簽章前進行決定性排序並對參數鍵值進行 URL 編碼
    # 在標準字串中維護所有預期參數以進行嚴格的客戶端-伺服器端驗證
    canonical_string = "&".join(
        f"{urllib.parse.quote(str(k))}={urllib.parse.quote(str(v))}"
        for k, v in sorted(params.items())
    )

    computed_hash = hmac.new(
        SECRET_KEY.encode("utf-8"),
        canonical_string.encode("utf-8"),
        hashlib.sha256
    ).hexdigest()

    # 第 3 步：恆定時間比較以防止計時攻擊
    if not hmac.compare_digest(computed_hash, provided_signature or ""):
        # 簽章不符 - 導向至預設回退頁面且不予歸因
        return redirect("https://example.com/fallback-unauthorized", code=302)

    # 第 4 步：解析 User-Agent 以進行作業系統級別自動路由
    user_agent = request.headers.get("User-Agent", "").lower()

    if "iphone" in user_agent or "ipad" in user_agent:
        # 將 iOS 使用者導向 App Store 並保留後端點擊情境
        return redirect("https://apps.apple.com/app/id123456789", code=302)
    elif "android" in user_agent:
        # 正確編碼多個 Play 參照參數
        referrer_params = {
            "utm_source": channel_code or "unknown",
            "utm_medium": request.args.get("utm_medium", "campaign_link"),
            "utm_campaign": request.args.get("utm_campaign", "organic")
        }
        encoded_referrer = urllib.parse.urlencode(referrer_params)
        return redirect(f"https://play.google.com/store/apps/details?id=com.example.app&referrer={encoded_referrer}", code=302)
    else:
        # 將桌機/未知瀏覽器導向 H5 登陸頁
        return redirect("https://example.com/landing_page", code=302)

以下範例展示了用於追蹤連結驗證的伺服器執行日誌與重導向標頭 JSON 架構。

// 檔案路徑: server/schemas/tracking_url_redirection_response.json
{
  "response_header": {
    "status_code": 302,
    "location_target": "https://apps.apple.com/app/id123456789",
    "cache_control": "no-cache, no-store, must-revalidate"
  },
  "server_execution_log": {
    "incoming_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15",
    "detected_os": "iOS",
    "hmac_signature_validation": "PASSED",
    "timestamp_delta_seconds": 12,
    "matched_channel_code": "partner_402"
  }
}

其他技術規格與整合指南可參閱追蹤連結設定指南與行動歸因 SDK 下載章節。

追蹤連結配置的常見錯誤

配置行動歸因連結時，若處理不當可能會引發技術邊緣情況，進而影響資料準確性：

• 公開未經雜湊的動態金鑰：以明文附加敏感的使用者或合作夥伴 ID，讓未經授權的參數修改成為可能。
• 未逸出的查詢字串：未對行銷活動名稱中的特殊字元進行 URL 編碼，導致行動瀏覽器解析重導向失敗。
• 遺漏時間戳記參數：建立沒有 TTL 限制的靜態追蹤連結，使行銷端點容易受到長期重放攻擊。
• 網域授權不匹配：部署自訂追蹤網域但未更新 iOS 通用連結 (Associated Domains) 或 Android App Links 驗證檔案，導致通用連結功能失效。

範例：確保多通路聯盟行銷連結免受竄改

模擬情境：行動聯盟行銷活動整合

挑戰

某行動零售應用程式觀察到合作夥伴回報的點擊量與驗證後的應用程式安裝數之間存在差異。未加密的推廣連結使未經授權的聯播網能夠剝離並置換通路代碼，藉此竊取自然轉換的歸因成效。

實作

工程團隊透過對所有動態行銷活動 URL 強制執行 HMAC-SHA256 簽章驗證、配置 48 小時 TTL 視窗，以及透過安全的伺服器對伺服器 Webhook 路由歸因回傳，升級了連結基礎架構。行銷活動設定則在行銷管理系統上完成建置。

預期成果

此實作展示了後端簽章驗證如何減少參數竄改並提高轉換資料的一致性。在模擬過程中，經變更的查詢參數會導致簽章驗證失敗，進而封鎖未經授權的分潤分派。

經驗教訓

• 於伺服器端簽署動態參數：加密雜湊可防止客戶端的參數修改。
• 強制執行 TTL 過期視窗：限制連結的有效性可防止過期連結被惡意重放。
• 於伺服器回傳中驗證簽章：在回傳驗證過程中交叉比對雜湊，可確保分潤管道的安全。

追蹤連結 vs 靜態下載連結 vs 原始 App Store 連結

不同的連結結構以不同的安全層級處理使用者重導向與歸因。下表總結了常見的追蹤實作：

總結與決策框架

當您的成效行銷活動符合以下功能性標準時，請選擇自動化追蹤連結系統：

• ✓ 多通路推廣需要來源歸因：獲客測量需求取決於驗證哪一位合作夥伴、網紅或廣告聯播網推動了安裝。
• ✓ 行銷連結暴露於公開詐欺風險中：連結分佈在不信任的第三方網路，易受到參數竄改威脅。
• ✓ 跨平台流量需求單一連結發佈：行銷資產需要一個能自動導向 Android 與 iOS 使用者的單一追蹤連結。
• ✓ 分潤處理需要伺服器端驗證：推廣獎勵需要加密驗證的轉換事件，才可進行財務結算。

在這些情境下，部署安全的追蹤連結框架可提供實用的架構。專用追蹤連結使開發團隊能在維護資料完整性的同時測量行銷活動成效。如 OpoInstall 等平台即實現了此框架，並支援動態 URL 產生與安全伺服器回傳。

術語表

相關資源

相關概念

• 安裝歸因：識別應用程式下載來源的基礎測量管道。
• 點擊灌水 (Click Spamming)：一種廣告詐欺方法，攻擊者透過模擬點擊湧入比對伺服器。
• 延遲深層連結 (Deferred Deep Linking)：在應用程式商店安裝過程中，對目標參數的程式化還原。

相關技術

• Google Play Install Referrer：Google 傳遞 Android 安裝時行銷活動中繼資料的原生 API。
• 通用連結 (Universal Links)：Apple 的原生深層連結標準，銜接網頁動作至原生螢幕。
• App Links：Google 的驗證深層連結協定，處理 Android 上的自訂網頁 URL。

參考標準

• IETF RFC 2104：用於 HMAC 安全性的訊息驗證金鑰雜湊規格。

主要整合介面

• 參數解析介面：客戶端 SDK 機制，用於在首次啟動時查詢自訂安裝參數。
• 轉換事件介面：客戶端 SDK 機制，用於上傳自訂應用內里程碑事件。

官方文件 / 參考資料

• Google Play Services Install Referrer API 規格
• Apple App Tracking Transparency 框架指南
• IETF RFC 2104 HMAC 規格
• OWASP 行動應用安全測試指南