如何優化 App Tracking Transparency (ATT) 同意授權率?提升 ATT 權限體驗涉及提供清晰的前置權限脈絡、撰寫準確的 NSUserTrackingUsageDescription,並在使用者旅程中選擇合適的時間點來呈現系統授權請求。授權率的實際成效應透過實驗數據來評估。
廣告商識別碼 (IDFA) 是 Apple 提供的一種可重設裝置識別碼,用於 iOS 上的廣告歸因與評估。在 App Tracking Transparency (ATT) 架構下,應用程式必須在取得使用者透過
ATTrackingManager授權提示明確同意後,才能存取 IDFA。
| 名詞 | 定義 |
|---|---|
| IDFA | Apple 受 App Tracking Transparency 管制的平台級廣告識別碼。 |
| App Tracking Transparency | Apple 的隱私權架構,要求在跨應用程式與網站追蹤使用者之前必須取得使用者授權。 |
| ATTrackingManager | 用於請求追蹤授權的原生 AppTrackingTransparency API。 |
| 前置權限引導 (Pre-Permission Primer) | 在系統提示出現之前展示的自訂應用程式內畫面,用於說明為何請求授權。 |
IDFA 存取的經濟學與 ATT 同意優化
授權 IDFA 存取在現代 iOS 評估中的角色
當應用程式對追蹤資料的使用符合 ATT 及其廣告與評估合作夥伴的要求時,已授權的 IDFA 存取可支援使用者層級的廣告歸因與評估工作流程。若無法取得追蹤授權,仍需進行廣告評估的團隊可採用獨立允許的平台中介方法,例如 AdAttributionKit 或現有的 SKAdNetwork 整合。
獲得授權後,IDFA 會為支援的廣告聯播網整合提供一個確定性的連結金鑰,無需進行統計建模即可實現廣告活動層級的轉換對帳。若未獲授權,應用程式則會將評估轉移至平台原生架構。
立即於冷啟動時跳出提示的問題
在冷啟動時立即向使用者請求追蹤授權在技術上獲得 Apple 允許,但這可能無法為知情同意提供足夠的脈絡,因為使用者尚未體驗應用程式的功能:
- 缺乏產品信任:首次使用的使用者尚未對應用程式的功能、品牌價值或資料安全實務建立信心。
- 脈絡不明確: 原生系統對話框在沒有事先說明的情況下彈出,導致風險意識較高的使用者預設選擇「要求 App 不要追蹤」。
- 權限疲勞:在應用程式初始啟動期間堆疊多個系統權限對話框(例如推播通知、ATT 與位置資訊)會產生摩擦並增加新手引導的放棄率。Apple API 文件指出,若現有的權限警示已經處於暫掛狀態,後續的授權請求將不會顯示。

以實驗數據評估同意率成效
可達成的同意率會因應用程式類別、受眾信任度、提示時機與文案清晰度而異。團隊應透過受控的 A/B 測試來評估優化變體,而不是假設固定的產業基準。
參見:IDFA ──> 行動歸因模型
AppTrackingTransparency 架構的技術機制
四種授權狀態
對 IDFA 的存取受到 ATTrackingManager.AuthorizationStatus 列舉的嚴格管轄:
notDetermined(0): 尚未向使用者顯示授權對話框。restricted(1): 裝置受家長監護、教育設定描述檔或企業 MDM 限制;無法授予追蹤權限且設定開關呈現停用狀態。denied(2): 使用者拒絕請求後,應用程式沒有權限存取與追蹤相關的資料。authorized(3): 使用者授權追蹤。在支援的 iOS 與 iPadOS 裝置上,這通常允許存取非零的廣告識別碼。

單次系統提示規則
iOS 作業系統對 ATTrackingManager.requestTrackingAuthorization 實施單次呈現規則。一旦使用者透過選擇「允許」或「要求 App 不要追蹤」與原生互動視窗互動,系統就會記住已決定的狀態,並且在該次 App 安裝期間不會再次顯示提示。
雖然系統提示不會再次出現,但使用者隨時可以在 iOS 設定中手動調整他們的追蹤授權。
當追蹤授權被拒絕時,iOS 如何強制將識別碼歸零
在 iOS 14.5 及更新版本中,當未授予追蹤授權時,廣告識別碼通常會回傳全為零的數值(00000000-0000-0000-0000-000000000000)。開發人員應隨時按需驗證 ATT 授權狀態與回傳的識別碼數值,而不應假設快取的字串在應用程式啟動之間保持有效。
高轉換率 UX 架構:前置權限引導策略
有效脈絡引導頁面的結構:Apple HIG 約束
根據 Apple 關於隱私權的人機介面指南 (Apple HIG),如果需要額外的脈絡,應用程式可以在系統權限提示之前呈現自訂的預先警示畫面。然而,Apple 對這些前置權限引導頁面施加了嚴格的設計規則:
- 單一動作按鈕:前置權限畫面必須僅提供一個按鈕(例如「繼續」或「下一步」),直接引導至系統提示。它絕不能提供繞過或延遲系統警示的「取消」、「關閉」或「稍後再說」按鈕。
- 不得模仿 UI:引導畫面絕對不能在視覺上模仿原生 iOS 系統警示方塊或顯示標示為「允許」的模擬按鈕。
- 禁止視覺強迫:介面不得使用旨在操縱或引導使用者在隨後的系統提示中選擇「允許」的圖形、箭頭或高對比度樣式。
遵守 App Store 審查指南 5.1.2
根據 Apple App Store 審查指南第 5.1.2 節,Apple 對權限請求強制執行明確的界線:
- 禁止利誘追蹤:嚴禁應用程式以提供財務獎勵、虛擬貨幣、付費內容或折扣作為換取 ATT 同意授權的交換條件。此舉違反指南 5.1.2,並可能導致應用程式遭到拒絕上架。
- 不得鎖定核心功能:若使用者拒絕追蹤授權,應用程式不得封鎖核心功能、阻止建立帳號或降低應用程式效能。
- 使用者選擇優先:使用者的實際追蹤選擇必須始終在 Apple 原生系統提示中做出。

階段 1: 使用者新手引導 / 核心價值實現
│
▼
階段 2: 脈絡化前置權限引導畫面
(單一「繼續」動作 ── 解釋用途)
│
▼
階段 3: 原生 iOS ATTrackingManager 系統互動視窗
(使用者選擇「允許」或「要求 App 不要追蹤」)
│
┌────────────┴────────────┐
▼ ▼
[.authorized] [.denied]
ATT 已授權 平滑降級至平台 API
(IDFA 通常可用) (AdAttributionKit / SKAN)
優化 NSUserTrackingUsageDescription 字串
設定 Info.plist 以達到目的透明度
Info.plist 中的 NSUserTrackingUsageDescription 鍵定義了直接顯示在 Apple 原生 ATT 系統警示內的說明字串。根據 Apple 文件,此字串必須簡潔、具體,並準確解釋追蹤資料的使用方式。
在不改變底層揭露的情況下測試清晰的目的字串變體
在測試字串變體時,每個測試過的變體都必須準確且完整地描述應用程式的實際追蹤實務:
- 個人化焦點:解釋如何使用資料來客製化內容推薦與產品建議。
- 廣告相關性焦點:解釋如何使用資料來提供相關促銷並避免重複的廣告。
- 廣告活動評估焦點:解釋如何使用資料來評估廣告合作夥伴的成效。
以下的設定展示了一個 NSUserTrackingUsageDescription 的範例。請僅在該措辭準確描述應用程式的實際追蹤實務時使用它:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSUserTrackingUsageDescription</key>
<string>您的資料將用於提供個人化的產品推薦、相關的促銷優惠,並評估廣告活動成效。</string>
</dict>
</plist>
在使用者生命周期中規劃最佳的提示時機觸發點
使用者旅程中的時機考量
雖然在首次啟動時請求 ATT 授權在技術上是允許的,但在使用者體驗到初始產品效用後才呈現提示,可以為授權請求提供更多相關的脈絡:
- 新手引導後觸發:在使用者完成帳號設定並配置初始偏好後呈現提示。
- 脈絡化里程碑觸發:在完成核心使用者動作後呈現提示(例如在遊戲中完成新手教學、在購物應用程式中儲存喜愛的商品,或在內容應用程式中將文章加入書籤)。
在 Swift 中實作 ATTrackingManager
處理應用程式活躍狀態與執行緒安全
根據 Apple API 文件,ATTrackingManager.requestTrackingAuthorization 僅在應用程式狀態為 .active 時顯示互動對話框。如果另一個權限提示處於活動狀態或暫掛中,系統警示將不會出現,且作業系統不會將並行請求排入佇列。

以下的實作將授權狀態管理與示範性的自訂前置權限檢視區隔開來:
import UIKit
import AppTrackingTransparency
import AdSupport
final class ATTManager {
static let shared = ATTManager()
private init() {}
/// 評估目前的授權狀態
var currentStatus: ATTrackingManager.AuthorizationStatus {
return ATTrackingManager.trackingAuthorizationStatus
}
/// 判斷是否可以呈現追蹤授權
var canRequestAuthorization: Bool {
return currentStatus == .notDetermined
}
/// 透過應用程式活躍狀態驗證來請求追蹤授權
/// - Parameter completion: 回傳解析後授權狀態的閉包
func requestAuthorization(completion: @escaping (ATTrackingManager.AuthorizationStatus) -> Void) {
guard canRequestAuthorization else {
completion(currentStatus)
return
}
// 在呼叫 requestTrackingAuthorization 之前驗證應用程式是否為活躍狀態
guard UIApplication.shared.applicationState == .active else {
print("已略過 ATT 請求:應用程式不是活躍狀態。若狀態仍為 notDetermined,請於恢復活躍後再次呼叫。")
completion(currentStatus)
return
}
DispatchQueue.main.async {
ATTrackingManager.requestTrackingAuthorization { status in
DispatchQueue.main.async {
switch status {
case .authorized:
// 隨時按需讀取目前的廣告識別碼;切勿持久化快取的 IDFA。
let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
print("ATT 已授權 - 可取得 IDFA:\(idfa)")
case .denied:
print("ATT 已拒絕 - 廣告識別碼回傳零數值")
case .restricted:
print("ATT 受系統描述檔限制")
case .notDetermined:
print("ATT 狀態未解析")
@unknown default:
print("遇到未知的 ATT 狀態")
}
completion(status)
}
}
}
}
}
/// 適用於符合 HIG 規範之前置權限引導頁面的示範性自訂 UIViewController
final class ATTPrimerViewController: UIViewController {
private let continueButton = UIButton(type: .system)
private let titleLabel = UILabel()
private let descriptionLabel = UILabel()
var onContinueTapped: (() -> Void)?
override func viewDidLoad() {
super.viewDidLoad()
setupUI()
}
private func setupUI() {
view.backgroundColor = .systemBackground
// 以模態方式呈現時防止互動式滑動關閉,以確保單一路徑導航
isModalInPresentation = true
titleLabel.text = "協助我們為您打造個人化體驗"
titleLabel.font = .boldSystemFont(ofSize: 20)
titleLabel.textAlignment = .center
titleLabel.numberOfLines = 0
descriptionLabel.text = "我們使用資料來量身打造產品推薦並提供相關的促銷優惠。在下一個畫面上,您將看到 Apple 的標準權限提示來確認您的選擇。"
descriptionLabel.font = .systemFont(ofSize: 15)
descriptionLabel.textAlignment = .center
descriptionLabel.textColor = .secondaryLabel
descriptionLabel.numberOfLines = 0
// Apple HIG 指引要求單一「繼續」或「下一步」動作
continueButton.setTitle("繼續", for: .normal)
continueButton.titleLabel?.font = .boldSystemFont(ofSize: 17)
continueButton.addTarget(self, action: #selector(handleContinue), for: .touchUpInside)
let stack = UIStackView(arrangedSubviews: [titleLabel, descriptionLabel, continueButton])
stack.axis = .vertical
stack.spacing = 20
stack.translatesAutoresizingMaskIntoConstraints = false
view.addSubview(stack)
NSLayoutConstraint.activate([
stack.centerXAnchor.constraint(equalTo: view.centerXAnchor),
stack.centerYAnchor.constraint(equalTo: view.centerYAnchor),
stack.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 32),
stack.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -32)
])
}
@objc private func handleContinue() {
// 呈現與關閉機制僅為示範性質,應根據應用程式的導航架構進行調整。
dismiss(animated: true) { [weak self] in
self?.onContinueTapped?()
}
}
}
拒絕後的恢復:在不違反政策的情況下引導使用者前往系統設定
何時導入次要設定工作流程
當使用者選擇「要求 App 不要追蹤」時,授權狀態會解析為 .denied。後續對 requestTrackingAuthorization 的呼叫會回傳 .denied 而不會顯示對話框。然而,如果使用者隨後啟動了一個明確受惠於追蹤的功能(例如在其帳號個人檔案中請求個人化廣告設定),應用程式可以提供通往 iOS 設定的非強迫性路徑。
使用 UIApplication.openSettingsURLString
若要引導使用者前往應用程式的設定頁面,請使用 UIApplication.openSettingsURLString:
if let settingsURL = URL(string: UIApplication.openSettingsURLString),
UIApplication.shared.canOpenURL(settingsURL) {
UIApplication.shared.open(settingsURL, options: [:], completionHandler: nil)
}
請注意,此 API 會開啟應用程式專屬的設定頁面;它不會提供直接深度連結至全域 設定 > 隱私權與安全性 > 追蹤畫面的捷徑。
App Store 政策界線
- 禁止持續囉嗦提醒:切勿顯示定期橫幅提示使用者在設定中啟用追蹤。
- 禁止功能鎖定:絕不能因為追蹤在設定中保持停用狀態而停用核心功能。
對比決策矩陣:前置權限策略與冷啟動提示
| 維度 | 預設冷啟動提示 | 強制閘道權限互動視窗 | 符合 HIG 規範的前置權限引導頁面 |
|---|---|---|---|
| 提示前的使用者脈絡 | 低(無產品互動) | 不一定(封鎖存取) | 脈絡化(於相關互動後呈現) |
| Apple UI/權限指引 | 當請求與資料使用合規時允許 | 當存取或補償取決於追蹤時不允許 | 當遵循 HIG 前置警示約束與追蹤規則時允許 |
| Apple 前置警示 UI 約束 | 不適用 | 不適用 | 單一繼續/下一步動作;無偽造警示 |
| 權限中斷時機 | 啟動時立即發生 | 封鎖式 | 脈絡化里程碑 |
| 觀察到的同意授權率 | 必須透過實驗數據評估 | 不允許 | 必須透過實驗數據評估 |
常見問題 (FAQ)
應用程式可以提供應用程式內貨幣或折扣來換取 ATT 權限授權嗎?
如果使用者最初選擇「要求 App 不要追蹤」,應用程式可以顯示第二次 ATT 提示嗎?
前置權限引導頁面是否違反 Apple 的 App Store 指南?
總結與決策架構
提升 ATT 權限體驗需要清晰的目的揭露與具備脈絡意識的時機掌控。當需要額外說明時,符合 HIG 規範的前置權限引導頁面可以在系統提示之前提供脈絡,同時將權限體驗與 Apple 公布的追蹤及介面指引保持一致。
如果在 ATT 拒絕後仍需要歸因或新手引導脈絡,應用程式可以使用獨立允許的機制,例如 AdAttributionKit、現有的 SKAdNetwork 整合,或是在 Apple 追蹤規則範圍內運作的真正第一方脈絡化路由。
若需了解特定產品的脈絡化路由與歸因行為,請參閱 OpoInstall 文件並根據適用的 Apple 追蹤要求評估實作方式。
相關資料
-
概念:App Tracking Transparency、IDFA 優化、前置權限引導頁面、同意漏斗
-
技術:StoreKit Framework、AppTrackingTransparency Framework、OpoInstall Mobile SDK
-
標準:Apple 隱私權人機介面指南、App Store 審查指南第 5.1.2 節
-
API:
ATTrackingManager.requestTrackingAuthorization、UIApplication.openSettingsURLString、ASIdentifierManager
官方文件
Share this article



