Apple 面臨英國 ATT 反壟斷訴訟？隱私保護行動歸因的未來發展

Apple 面臨英國 ATT 反壟斷訴訟？2026 年 9 月 3 日，一項集體訴訟申請提交至英國競爭上訴法庭（CAT），指控 Apple 的應用程式追蹤透明度（ATT）框架對第三方開發者施加了反競爭限制，同時偏袒其自身的廣告業務，預估對英國開發者造成的損失高達 20 億英鎊。對於行動架構師、績效行銷總監與資料基礎設施工程師而言，圍繞在隱私保護行動歸因（Privacy-Preserving Mobile Attribution）的審查，突顯了行動平台用戶獲取的根本性轉變。隨著 ATT 將 IDFA 的存取限制在明確的追蹤授權之後，行動生態系已轉向聚合式設備端測量協議與第一方 Web-to-App 探索漏斗。若要評估在不依賴跨 App 監控的情況下，現代歸因如何運作，就必須同時檢視 Apple 的法律風險以及 AdAttributionKit、群體匿名層級與安裝邊界參數持久化的技術細節。

20 億英鎊的英國反壟斷訴訟：法律指控與平台治理

提交至倫敦的集體訴訟對 Apple 的平台資料治理構成了重大法律挑戰。該訴訟由名為 ATT Collective Action Limited 的特殊目的實體發起，由英國競爭與市場管理局（CMA）前資深總監 Ann Pope 擔任主席，並由法律事務所 Hausfeld 提供諮詢。此退出型訴訟旨在為自 2021 年 4 月 26 日 ATT 推出以來，透過 App 內廣告獲利或購買廣告版位以推動 iOS App 安裝的英國應用程式開發者尋求賠償。

重點摘要

20 億英鎊賠償要求：該項於 2026 年 9 月 3 日提交至英國競爭上訴法庭的退出型集體訴訟，指控 Apple 以消費者隱私為旗號，創造了不公平的商業競爭環境。
自我優待指控：訴訟主張第三方開發者必須透過限制性的許可提示才能存取廣告識別碼，而 Apple 自身的廣告網路卻能在 App Store 介面上擴張，且無須面對同等的介入障礙。
訴訟狀態：該案正等待法庭認證；相關指控尚未在法庭上證實，而 Apple 已否認這些說法，堅稱 ATT 適用於所有 App 的一致標準，旨在保護消費者資料。

現代行動平台隱私與資料追蹤控制示意圖

根據 Reuters 的報導以及 Hausfeld 發布的申訴聲明，訴訟主張雖然消費者隱私是至關重要的保護，但 Apple 在未經充分產業諮詢的情況下單方面推行 ATT，干擾了獨立發行商與開發者的經濟基礎。

Apple 已駁回上述指控，表示應用程式追蹤透明度旨在讓用戶能精細控制外部應用程式是否能追蹤其在第三方屬性上的活動。Apple 維持其立場，即所有開發者（包括 Apple 本身）在跨公司追蹤方面均遵守相同規則，且 ATT 也獲得了全球隱私倡導者的讚譽。

在訴訟進入庭審前，CAT 必須決定是否認證該訴訟適合進行集體程序。該案與法庭目前受理的其他主要平台訴訟併列，包括 Kent v. Apple App Store 佣金上訴案以及 Which? 雲端儲存訴訟案。

+-------------------------------------------------------------------------+
|                  ATT 監管爭議時間軸                                      |
+--------------------------+-----------------------+----------------------+
| 日期 / 期間               | 平台里程碑             | 營運影響               |
+--------------------------+-----------------------+----------------------+
| 2021 年 4 月 26 日        | ATT 強制執行           | iOS 14.5 將 IDFA 限制於明確的同意對話框 |
| 2021–2025                | 生態系轉型             | IDFA 可用性降低，推動回傳機制採用 |
| 2024–2026                | AAK 與 SKAN 擴張       | AdAttributionKit 擴充多轉換視窗歸因報告 |
| September 3, 2026        | CAT 集體訴訟提告        | 為英國開發者提告 20 億英鎊反壟斷訴訟 |
| 審理中 (2026–2027)        | CAT 認證階段           | 法庭評估是否核准集體訴訟程序 |
+--------------------------+-----------------------+----------------------+

技術拆解：從確定性 IDFA 到聚合式隱私框架

為了評估訴訟背後的營運現實，工程團隊必須剖析 iOS 歸因架構在 ATT 前後的演變。

歷史上，行動廣告網路依賴廣告識別碼（ASIdentifierManager.shared().advertisingIdentifier）。IDFA 是一種設備專屬的廣告識別碼（以 128 位元 UUID 表示），能夠跨不同應用程式進行確定性測量。廣告網路可以在廣告互動期間記錄 IDFA，將其轉發給歸因提供商，並在用戶開啟新安裝的應用程式時比對該 IDFA，從而建立展示與轉換之間的確定性連結。

Apple 開發者軟體框架與平台工具概述

當 ATT 生效後，對 IDFA 的存取被置於 ATTrackingManager.requestTrackingAuthorization 介面之後。若用戶選擇「要求 App 不追蹤」，或系統層級限制了追蹤，API 將回傳全零 UUID（00000000-0000-0000-0000-000000000000）。隨著同意率穩定在遠低於全面覆蓋的水準，確定性跨 App 追蹤已不再是大規模獲客的可靠基礎。

為了在不共享跨 App 用戶身份的情況下提供廣告活動歸因，Apple 引入了 SKAdNetwork 以及後續的 AdAttributionKit。值得注意的是，AdAttributionKit 的運作獨立於用戶的 ATT 授權狀態，因為其輸出內容不包含任何用戶或設備專屬的追蹤識別碼。

AdAttributionKit 的運作機制建立在三個核心架構原則上：

雙重密碼驗證：廣告網路使用 JSON Web Signatures (JWS) 生成經過數位簽章的廣告展示。安裝與轉換後，作業系統會在設備端驗證展示 Token，並隨後生成一個由 Apple 簽署的歸因回傳，允許廣告網路驗證該轉換確實經過 iOS 認證。
延遲回傳交付視窗：為了防止廣告網路利用精確的安裝時間戳記執行側通道計時攻擊，回傳會在隨機延遲後發送。Apple 記錄了在準備完成與接收之間存在至少 24 到 48 小時的隨機間隔，且由於轉換視窗（例如初始的 48 小時視窗）在未鎖定前保持開啟，整體交付時間會進一步延長。
群體匿名資料層級：Apple 將歸因回傳分配至四個群體匿名層級（Tier 0 至 Tier 3）之一，這是根據廣告來源、廣告宣傳的 App、安裝地區及層級化來源識別碼的群體情況來決定。在較低層級中，回傳欄位會受限：精確轉換值（0 到 63）被替換為粗略值（low, medium, high）或在 Tier 0 中完全省略，來源識別碼則從四位數截斷為兩位數。

+-------------------------------------------------------------------------+
|             確定性 IDFA 與聚合式隱私歸因比較                             |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ATT 前的確定性範式 ]                                                    |
|  廣告展示 (記錄 IDFA: UUID-1)                                           |
|         |                                                               |
|         v                                                               |
|  App 首次開啟 (讀取 IDFA: UUID-1)                                        |
|  結果：確定性、用戶層級、即時廣告歸因。                                  |
|                                                                         |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ATT 後的聚合式協議: AdAttributionKit / SKAN ]                        |
|                                                                         |
|  廣告展示 (網路簽署的 JWS Token)                                        |
|         |                                                               |
|         v                                                               |
|  [ 用戶透過 App Store 安裝 ]                                            |
|         |                                                               |
|         v                                                               |
|  [ 設備端歸因處理 ]                                                     |
|         |                                                               |
|         |-- (計算轉換視窗: 隨機 24–48 小時延遲)                           |
|         |-- (套用群體匿名 Tier 0–3 欄位遮罩)                             |
|         v                                                               |
|  [ 發送至網路端點的匿名 Apple 簽署回傳 ]                                  |
|  酬載: 粗略值、精確值、或 Null (視層級而定)                             |
|           來源識別碼 (2–4 位數)                                         |
|                                                                         |
+-------------------------------------------------------------------------+

雖然 AdAttributionKit 旨在測量廣告活動成效並同時減少用戶層級的資料暴露，但其延遲的回饋與聚合式報告為即時演算競價帶來了營運挑戰。

下游行動獲客與第一方安裝邊界

由於跨 App 用戶追蹤在聚合回傳模型下資料準確度降低，績效行銷團隊已擴大對 Web-to-App 漏斗的依賴。在 Web-to-App 架構中，用戶獲取始於擁有的第一方行動網頁屬性。

根據 Apple 的隱私準則，追蹤的具體定義為將從某公司 App 收集的用戶或設備資料，與從其他公司 App、網站或離線屬性收集的資料進行連結，以進行目標廣告或測量目的。當廣告商將流量導向自己的網站（例如 https://brand.example.com）時，該互動發生在第一方語境中。在自有網域上吸引用戶、呈現促銷優惠並捕捉購買意圖，並不構成跨公司追蹤，前提是所產生的資料未與第三方資料集連結。

然而，將用戶從第一方行動到達頁面轉移至原生 iOS App 時，會產生安裝邊界：

+-------------------------------------------------------------------------+
|             獨立的下游行動獲客旅程                                       |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 用戶到達第一方行動網頁 ]                                              |
|  捕捉語境: ?channel=partner_promo&discount=SAVE20&sku=8831             |
|         |                                                               |
|         v                                                               |
|  [ 用戶點擊 App 下載號召按鈕 ]                                           |
|         |                                                               |
|         v                                                               |
|  [ 重新導向至 Apple App Store ]                                          |
|         |                                                               |
|         v                                                               |
|  [ 安裝邊界: 標準 App Store 下載流程不會將網頁查詢參數或自訂 URL 字串   |
|    傳遞至 App 二進位檔 ]                                                |
|         |                                                               |
|         v                                                               |
|  [ 用戶首次開啟原生 App (冷啟動) ]                                       |
|         |                                                               |
|         v                                                               |
|  [ 延遲深度連結引擎 (伺服器輔助還原) ]                                    |
|         |                                                               |
|         v                                                               |
|  [ 符合資格的預安裝參數還原並套用入門體驗 ]                               |
|                                                                         |
+-------------------------------------------------------------------------+

當未安裝 App 的用戶從 Safari 轉移至 App Store 時，標準發行流程不會將任意 URL 查詢字串傳送至已安裝的 App 套件。在首次啟動時，原生 App 無法原生識別是哪個特定的網頁廣告活動或產品頁面引導了該用戶。

為了在不依賴未經授權的跨公司追蹤識別碼的情況下跨越此邊界，工程團隊實作了不同的連結處理架構：

路由架構	用戶 App 狀態	安裝期間的參數保留	平台隱私架構
已驗證通用連結 (Universal Links)	目標 App 已安裝	繞過 App Store；直接場景導航	使用已驗證的 HTTPS 網域對 App 關聯；隱私取決於收集的資料與後續使用方式
AdAttributionKit / SKAN	目標 App 未安裝	聚合式回傳；無自訂查詢參數	聚合式廣告活動測量；延遲 24–48 小時最低回傳；無列級語境
延遲深度連結 (DDL)	目標 App 未安裝	在首次冷啟動時還原符合資格的預安裝參數	伺服器輔助還原符合資格的預安裝語境，受限於提供商實作與平台規則

在生產環境架構中，開發團隊部署了如 Branch、AppsFlyer、Adjust 或 Opoinstall 等延遲深度連結框架。像 Opoinstall 這樣的平台會在將用戶重新導向至 App Store 之前，於商家的到達頁面上捕捉符合資格的廣告活動語境（例如促銷 Token 或產品 SKU）。

在 App 首次冷啟動時，用戶端 SDK 會向歸因後端查詢以還原快取的會話參數。根據 Opoinstall 首頁的平台文件，此延遲參數傳遞框架可在高達 98% 的符合資格實例中於首次啟動時還原參數，提供手動促銷代碼的自動化替代方案。

維持明確的架構界限至關重要：延遲深度連結不會重建未曾觀察到的第三方測量事件，也不會繞過平台追蹤規則。它僅會還原在安裝邊界發生前，已在被允許的第一方旅程中捕捉到的符合資格的目的地、廣告活動或引薦語境。

// 說明性的 Swift 實作，展示首次啟動時的語境還原。
// 在 App 冷啟動時消耗符合資格的延遲歸因參數，
// 且不依賴持續性的跨 App 廣告識別碼 (IDFA)。

import UIKit

struct AttributionPayload: Decodable {
    let channel: String
    let campaignId: String
    let targetRoute: String
    let promoCode: String?
}

final class FirstLaunchAttributionManager {
    static let shared = FirstLaunchAttributionManager()
    
    // 本地啟動狀態紀錄旗標 (非歸因或設備識別碼)
    private let hasCompletedFirstLaunchKey = "com.app.hasCompletedFirstLaunchRestoration"
    
    private init() {}

    /// 指示 App 是否已成功完成首次啟動參數還原
    var isRestorationPending: Bool {
        return !UserDefaults.standard.bool(forKey: hasCompletedFirstLaunchKey)
    }

    /// 將還原過程標記為已解析，以防止重複執行
    func markRestorationCompleted() {
        UserDefaults.standard.set(true, forKey: hasCompletedFirstLaunchKey)
    }

    /// 從歸因 SDK 回呼或用戶端框架擷取符合資格的預安裝參數。
    /// 注意: 比對演算法與會話關聯訊號為提供商特定，此處略過。
    func handleDeferredAttribution(with payloadResult: Result<AttributionPayload, Error>,
                                   in window: UIWindow?) {
        guard isRestorationPending else {
            return
        }

        switch payloadResult {
        case .success(let payload):
            // 僅在成功接收酬載時標記還原完成
            markRestorationCompleted()
            applyNavigationRoute(payload, in: window)
            
        case .failure(let error):
            // 記錄錯誤但不設定完成旗標，允許在暫時性失敗時重試
            print("暫時性歸因擷取失敗: \(error.localizedDescription)")
        }
    }

    /// 將還原的第一方語境套用至現有的場景導航階層
    private func applyNavigationRoute(_ payload: AttributionPayload, in window: UIWindow?) {
        DispatchQueue.main.async {
            guard let navigationController = window?.rootViewController as? UINavigationController else {
                return
            }

            // 將用戶路由至在預安裝網頁到達頁面發現的目的地
            if payload.targetRoute.hasPrefix("products/"),
               let sku = payload.targetRoute.split(separator: "/").last.map(String.init) {
                let detailVC = ProductDetailViewController(sku: sku, promoCode: payload.promoCode)
                navigationController.pushViewController(detailVC, animated: true)
            }
        }
    }
}

// 消耗還原後廣告活動狀態的檢視控制器範例
class ProductDetailViewController: UIViewController {
    private let sku: String
    private let promoCode: String?

    init(sku: String, promoCode: String?) {
        self.sku = sku
        self.promoCode = promoCode
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) { 
        fatalError("init(coder:) 未被實作") 
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .systemBackground
        title = "產品: \(sku)"
        
        if let code = promoCode {
            // 套用從網頁到達頁面傳遞過來的促銷折扣
            print("自動套用還原後的憑證代碼: \(code)")
        }
    }
}

常見問題 (FAQ)

英國反壟斷訴訟指控 Apple 違反了什麼具體規定？

提交至英國競爭上訴法庭的訴訟指控 Apple 進行了反競爭的自我優待，對第三方 iOS App 開發者施加比其自身廣告服務更嚴格的隱私與追蹤同意障礙。申訴人主張這種不均衡的執行削弱了第三方廣告收入並提高了客戶獲取成本。Apple 否認上述指控，堅稱 ATT 旨在保護消費者隱私，且其規則對所有 App 皆一致適用。

AdAttributionKit 與廣告識別碼 (IDFA) 有何不同？

IDFA 是一種設備專屬的廣告識別碼，歷史上允許在不同公司擁有的 App 與網站之間進行確定性、用戶層級的追蹤。AdAttributionKit 的回傳並不依賴持續性的用戶或設備專屬識別碼。相反，iOS 會在設備端以密碼學方式驗證廣告展示，並向廣告網路交付聚合、延遲且經過層級遮罩的回傳，從而防止重建單一的跨 App 用戶畫像。

第一方 Web-to-App 廣告活動如何與 ATT 互動？

根據 Apple 的隱私政策，追蹤具體是指為了目標廣告或測量目的，將從某公司 App 收集的用戶或設備資料，與從其他公司 App 或網站收集的資料進行連結。第一方 Web-to-App 流程可在資料維持在廣告商被允許的第一方使用範圍內，且未與第三方資料集共享或連結以進行跨公司追蹤時，在不依賴 IDFA 的情況下保留符合資格的廣告活動或目的地語境。延遲深度連結會還原此第一方語境，但其本身並不會讓歸因實作免於遵守 ATT 規範。

給行動架構師與成長團隊的策略指引

關於應用程式追蹤透明度 (ATT) 的 20 億英鎊英國訴訟反映了一個持續存在的產業現實：不受限制的跨應用確定性設備追蹤將不會回歸。無論法庭對平台自我優待的裁決如何，行動作業系統將持續強制執行嚴格的隱私邊界。

對於行動工程團隊與成長領袖而言，適應此環境需要三個技術承諾：

採用平台原生隱私框架：在廣告購買管道中實作 AdAttributionKit 與 SKAdNetwork，以在不依賴已棄用的追蹤實作情況下捕捉聚合後的廣告活動轉換。
強化第一方 Web-to-App 途徑：建構具備彈性的網頁到達頁面架構，在第一方語境中捕捉客戶意圖，並為已安裝用戶部署已驗證的通用連結 (Universal Links)，以及利用延遲深度連結 (Deferred Deep Linking) 來維持跨 App 安裝的連貫性。
將 App 路由範圍導向意圖：結構化原生入門體驗以消耗動態參數酬載，而非身份層級的追蹤 Token，確保促銷折扣與深度連結目的地能夠透明且可靠地度過冷啟動序列。