什麼是 IDFA 以及 Apple 的「App 追蹤透明度」(ATT) 如何影響 iOS 歸因？

什麼是 IDFA 以及它如何影響 iOS 歸因？「廣告識別碼」(IDFA) 是 Apple 提供的一種可重置廣告識別碼，當使用者授予追蹤權限時，iOS App 與廣告平台可利用它進行合規的廣告衡量與歸因。若使用者拒絕 ATT 權限，App 將無法取得 IDFA，這促使廣告主轉向保護隱私的歸因方法。

IDFA (廣告識別碼) 是 Apple 專為 iOS 廣告衡量設計的可重置識別碼。Apple 的「App 追蹤透明度」(ATT) 架構將 IDFA 的存取權限從系統預設開放變更為需經使用者授權，使行動歸因從決定性的跨 App 比對，轉向保護隱私的衡量架構。

簡答

「廣告識別碼」(IDFA) 是 Apple 用於廣告衡量之可重置識別碼。在「App 追蹤透明度」(ATT) 架構下，存取 IDFA 需經使用者明確同意。若使用者拒絕追蹤，IDFA 將無法存取，促使 iOS 衡量轉向採用 SKAdNetwork 與第一方情境歸因。

什麼是 IDFA，為什麼 Apple 要在 ATT 下限制存取？

IDFA 在行動歸因中的歷史角色

過去，行動廣告網路主要依賴 IDFA 作為 iOS 生態系中跨應用的決定性比對鍵值。當廣告點擊發生於發佈商 App 時，廣告網路會記錄使用者的 IDFA 字串與廣告活動元資料 (Metadata)。在商店重新導向、安裝並首次開啟 App 後，嵌入的衡量 SDK 會從裝置提取相同的 IDFA 字串並傳送至歸因伺服器。

透過執行精確的字串比對 ($\\text{IDFA}*{\\text{click}} == \\text{IDFA}*{\\text{install}}$)，歸因引擎能以決定性的精準度驗證廣告成效。此通用識別碼實現了多點觸控映射、使用者層級再行銷 (Retargeting)、跨 App 行為分析以及簡化的伺服器對伺服器 (S2S) 回傳 routing。

iOS 14.5 中「App 追蹤透明度」的引進

隨著 iOS 14.5 與「App 追蹤透明度」(ATT) 架構的發佈，Apple 重新建構了 iOS 與 iPadOS 的隱私權執行機制。在 ATT 下，存取 IDFA 被歸類為「追蹤」，要求應用程式必須在程式碼層面提示使用者明確授權，才能取得該識別碼。

若應用程式在未經授權的情況下嘗試查詢 IDFA，或使用者點擊「要求 App 不要追蹤」，系統將回傳一個全為零的識別碼值：

00000000-0000-0000-0000-000000000000

由於絕大多數使用者選擇拒絕 ATT 權限，導致跨 iOS 付費流量的決定性 IDFA 比對機制失效，破壞了傳統的使用者層級廣告活動衡量。

了解 ATTrackingManager 授權狀態

作業系統對 IDFA 的存取權是由 Apple「AppTrackingTransparency」架構內的 ATTrackingManager 類別所控管。開發者可透過 ATTrackingManager.trackingAuthorizationStatus 查詢系統狀態，該方法會回傳以下四種離散狀態：

• authorized：使用者已授予明確追蹤權限。應用程式可透過 ASIdentifierManager.shared().advertisingIdentifier 取得真實的 IDFA 字串。

• denied：使用者已在 ATT 系統提示中明確拒絕追蹤，或在系統設定中停用了全域追蹤功能。廣告識別碼將回傳全為零的數值。

• restricted：在作業系統層級上存取廣告識別碼受限 (例如受系統政策或家長控制限制)。

• notDetermined：尚未向使用者顯示 ATT 權限提示。在請求並獲得授權前，存取 IDFA 的權限將保持封鎖狀態。

App 追蹤透明度如何影響決定性的 iOS 歸因

跨 App 追蹤機制的崩解

當 iOS 使用者拒絕 ATT 提示後，歸因流程便失去了將安裝前廣告互動與安裝後應用程式事件連結所需的關鍵決定性索引鍵。若使用者 A 在發佈商 App X 點擊廣告並安裝了廣告主 App Y，除非獲得使用者授權，否則兩者皆無法使用 IDFA 進行歸因。

由於在多數情況下難以在兩個端點皆獲得授權，決定性的跨 App 追蹤在絕大多數使用者獲取通路中皆已失效。廣告主無法再使用廣告識別碼，將個別使用者的路徑從特定廣告素材直接追溯至安裝後的終身價值 (LTV) 紀錄。

非合規指紋識別 (Fingerprinting) 的風險

面對失效的 IDFA 機制，部分廣告主嘗試部署機率性的裝置指紋識別——透過結合 IP 位址、User-Agent 字串、系統運行時間與裝置配置來建構虛擬識別碼。然而，Apple 的「App Store 審查指南」(第 5.1.2 節) 明確禁止在未經授權的情況下追蹤使用者，無論採取何種技術手段。

Apple 會審查應用程式並評估其提交的程式碼與行為，以檢測是否有繞過 ATT 同意的企圖。若應用程式被偵測出透過採集裝置屬性來規避 ATT 同意，將面臨 App Store 下架或帳號被暫停的風險。因此，永續的 iOS 衡量架構必須採用合規的第一方隱私保護方法，而非採用違規的指紋識別技術。

隱私保護衡量的替代方案

為了在不違反 Apple 規範的前提下維持 iOS 廣告成效可視性，行動衡量架構通常採用雙層策略：

• 裝置端聚合歸因：利用 Apple 原生的 SKAdNetwork (SKAN) 架構，從 Apple 的歸因系統接收已聚合且具隱私隔離性的轉換回傳。

• 第一方情境還原：透過 Web JS SDK 運用延遲深度連結，將動態行銷參數 (如廣告活動 ID 或引薦 Token) 直接傳遞至安裝流程中，過程中無須讀取廣告識別碼。

延遲深度連結並非為了取代 Apple 的 IDFA 或 SKAdNetwork，而是透過還原第一方行銷情境，來補強 Apple 的隱私保護歸因生態系。延遲深度連結旨在保存第一方行銷資訊，而非重建使用者層級追蹤。如 OpoInstall 等行動衡量平台透過情境參數還原功能，在嚴格遵守 iOS 隱私要求的前提下，還原第一方行銷情境。

結構比較：IDFA vs SKAdNetwork vs 延遲深度連結

ATT 前後 IDFA 比對與現代隱私衡量架構之比較分析

脫離決定性廣告識別碼後，需衡量傳統 IDFA 追蹤、Apple 原生 SKAdNetwork 與第一方情境參數還原之間的運作取捨。

下表對比了這三種衡量模式的關鍵功能維度：

評估資料精確度、使用者同意要求與技術限制

傳統 IDFA 追蹤雖提供無限制的使用者層級細節，但因高度依賴使用者明確同意，已無法作為主要策略。SKAdNetwork 是 Apple 為支援合規廣告衡量而設計的隱私保護歸因架構，它在不洩露使用者層級識別碼的情況下，執行隱私保護報告限制並提供延遲歸因訊號。SKAdNetwork 4 引入了階層式轉換價值 (粗略與細膩級別)、取代舊版廣告活動 ID 欄位的來源識別碼，以及多個回傳視窗，旨在改善廣告活動衡量並同時保護隱私。

情境化延遲深度連結透過在網頁點擊時擷取非敏感行銷參數 (如邀請者 ID 或廣告活動引薦 Token) 來補強 SKAdNetwork。當使用者安裝並開啟 App 時，客戶端 SDK 會擷取這些情境參數，在不存取受限廣告識別碼的情況下還原廣告活動歸因。

建構 iOS 歸因流程的開發者可參考 iOS 歸因 SDK 文件以了解詳細整合說明。

隱私保護 iOS 歸因的技術實作

透過 ATTrackingManager 請求 ATT 授權

若希望合法查詢 IDFA，iOS 開發者必須在 Info.plist 檔案中配置 NSUserTrackingUsageDescription 鍵，向使用者說明請求追蹤權限的原因。

開發者通常會在 onboarding 流程中溝通授權價值後，透過程式呼叫 requestTrackingAuthorization(completionHandler:)。

標準化 ATT 授權與 SKAN 事件架構

為可靠處理 iOS 歸因訊號，後端事件收集器會同時接收 SKAdNetwork 回傳負載與客戶端情境事件負載。

開發者可參考 原始資料匯出文件，了解 S2S 原始日誌結構與事件負載的技術欄位定義。

下方的架構圖展示了一個 iOS 歸因事件 JSON 結構範例。註：此為概念範例，非 Apple 或 OpoInstall API 規範：

```json
{
“example_only”: true,
“event_type”: “ios_attribution_event”,
“app_id”: “com.example.iosapp”,
“device_context”: {
  “os_version”: “17.4”,
  “model”: “iPhone15,2”,
  “att_status”: “denied”,
  “idfa_access_status”: “unavailable”
},
“contextual_attribution”: {
  “channel_code”: “ios_privacy_campaign”,
  “campaign_id”: “cmp_ios_search_01”,
“referral_token”: “ref_token_88776655”,
  “attribution_method”: “contextual_deferred_deep_link”
},
“skan_metadata”: {
  “skan_version”: “4.0”,
  “postback_sequence_index”: 1
}
}

如何使用情境參數還原維持廣告活動可視性

繞過 IDFA 同意瓶頸：第一方 Web-to-App 情境傳遞功能運作原理

當付費廣告活動將流量導向行動網頁落地頁 (Landing Page) 並隨後引導使用者前往 App Store 時，可在不讀取廣告識別碼的情況下保留歸因情境。第一方 App 連結與延遲深度連結流程允許開發者在不存取受限廣告識別碼的情況下保留廣告活動情境。Web JS SDK 直接從網頁 URL 查詢字串中擷取動態查詢參數 (如 channelCode、campaignID 或 shareCode)。

在使用者重新導向至 App Store 後，Web SDK 會將這些參數與工作階段元資料一同快取在歸因伺服器上。當使用者首次安裝並啟動 App 時，行動 SDK 會查詢歸因引擎以取回已快取的情境參數。

透過情境 Web-to-App 流程還原安裝後動態負載

部分第一方歸因流程使用作業系統與 App 生態系支援的隱私保護式 Web-to-App 參數傳遞機制，在不存取受限廣告識別碼的情況下還原情境廣告活動 Token。在網頁重新導向期間，Web JS SDK 會在引薦流程中加入引薦 Token。

在首次開啟應用程式時，原生行動 SDK 會讀取該情境參數、解析引薦負載並執行 getInstallParam 回呼處理器。此第一方參數還原過程完全在 App 邊界內執行，傳遞引薦鍵值且無需存取跨 App 追蹤識別碼。

│
                                      ▼
               

                                      │

                                      ▼

                                      │

                                      ▼

              (無需 IDFA 存取的合規歸因)

如何審核 iOS 廣告支出而不依賴裝置識別碼

從使用者層級轉向基於群組 (Cohort) 的效能衡量

隨著使用者層級的決定性識別碼在 iOS 上逐漸不可用，成效行銷團隊必須從個別使用者追蹤轉向基於群組的廣告活動衡量。

分析人員不再追蹤使用者 X 的每一個 App 內里程碑，而是評估按獲取來源、引薦 Token 或 SKAN 廣告活動 ID 聚合的廣告活動群組。比較不同群組的第 1 天、第 7 天與第 30 天營收，可提供必要的資料集以計算廣告活動 ROAS，且無需個體裝置追蹤。

審核 iOS 付費通路的增量價值 (Incremental Lift)

為了驗證付費 iOS 廣告活動是否帶來真正的商業成長，還是僅僅搶佔了自然安裝量，廣告主應使用控制組 (Holdout groups) 進行增量測試。

透過在隨機對照組中停止投放廣告，並衡量相對於處理組 (Treatment group) 的轉換差異，行銷人員能分離出真正的增量價值。將增量衡量與情境化延遲深度連結相結合，可在後 IDFA 時代提供一個穩健的架構，用於評估 iOS 廣告支出的效率。

重點總結

• 隱私優先時代：由於同意率偏低，Apple 的 ATT 架構使得決定性的 IDFA 追蹤在多數 iOS 流量中已不再可行。

• 合規風險：非合規的裝置指紋識別違反「App Store 審查指南」，可能導致 App 下架或帳號被暫停。

• 第一方還原：結合原生的 SKAdNetwork 衡量與情境化延遲深度連結，可在維持完全隱私合規的前提下，實現高精確度的 iOS 廣告活動歸因。

總結與決策架構

應對 IDFA 追蹤變更，要求行動成長團隊採用保護隱私的衡量架構。在 Apple 的 ATT 架構下，單一依賴傳統決定性裝置 ID 已不再可行。

為了維持 iOS 歸因的準確性，工程與行銷團隊必須將 Apple 的原生 SKAdNetwork 架構與第一方情境參數相結合。此方式可在不依賴受限識別碼的情況下，實現合規的廣告活動衡量。

開發者若需實作行動歸因流程，可參考 OpoInstall 行動歸因實作參考，或在 OpoInstall 開發者控制台註冊帳號，以獲取 SDK 整合與事件傳遞工作流程。

相關主題

• 相關文章：

  • 行動行銷中的多點觸控歸因是什麼？

  • 行動衡量夥伴 (MMP) 的運作方式

  • SKAdNetwork 與 MMP 歸因之比較

  • App 使用者獲取的增量測試

• 概念：IDFA、App 追蹤透明度、SKAdNetwork、情境化延遲深度連結、隱私保護歸因

• 技術：ATTrackingManager、伺服器對伺服器 (S2S) 回傳、Web JS SDK

• 標準：Apple App Store 審查指南第 5.1.2 節、W3C Fetch API 規格、OWASP 行動安全規範

• API：行動歸因事件記錄 API、Apple ATTrackingManager API、Apple SKAdNetwork 回傳 API

• 官方文件與參考：

  • Apple 開發者關於 App 追蹤透明度的說明文件

  • Apple 開發者關於 SKAdNetwork 架構的說明文件

  • W3C Web 效能工作小組標準