Wie lassen sich die Opt-In-Raten von App Tracking Transparency (ATT) optimieren? Die Verbesserung des ATT-Berechtigungsverfahrens umfasst die Bereitstellung eines klaren Kontexts vor der Berechtigung, das Verfassen einer präzisen NSUserTrackingUsageDescription sowie die Wahl eines passenden Zeitpunkts im Nutzerverlauf, um die Systemautorisierungsanfrage anzuzeigen. Die Auswirkung auf die Autorisierungsrate sollte empirisch gemessen werden.
Die Werbe-ID (IDFA) ist ein von Apple bereitgestellter, zurücksetzbarer Gerätedenkenzähler, der für die Attribuierung und Messung von Marketingaktivitäten unter iOS verwendet wird. Im Rahmen des App Tracking Transparency (ATT) Frameworks können Anwendungen nur dann auf die IDFA zugreifen, wenn sie eine ausdrückliche Nutzerinwilligung über die
ATTrackingManager-Berechtigungsabfrage erhalten haben.
| Begriff | Definition |
|---|---|
| IDFA | Apples plattformweiter Werbebezeichner, der durch App Tracking Transparency reguliert wird. |
| App Tracking Transparency | Apples Framework, das eine Nutzerautorisierung erfordert, bevor Benutzer über Apps und Websites hinweg nachverfolgt werden. |
| ATTrackingManager | Die native AppTrackingTransparency-API, die zum Anfordern der Tracking-Autorisierung verwendet wird. |
| Pre-Permission Primer | Ein benutzerdefinierter In-App-Bildschirm, der vor dem Systemdialog angezeigt wird, um zu erklären, warum die Autorisierung angefordert wird. |
Die Ökonomie des IDFA-Zugriffs und der ATT-Einwilligungsoptimierung
Die Rolle des autorisierten IDFA-Zugriffs in der modernen iOS-Messung
Ein autorisierter IDFA-Zugriff kann nutzerbasierte Marketing-Attribuierungs- und Mess-Workflows unterstützen, wenn die Verwendung von Tracking-Daten durch eine Anwendung mit ATT und den Anforderungen ihrer Mess- und Marketingpartner konform ist. Wenn keine Tracking-Autorisierung verfügbar ist, können Teams, die dennoch eine Marketingmessung benötigen, unabhängig erlaubte, plattformgestützte Ansätze wie AdAttributionKit oder bestehende SKAdNetwork-Integrationen nutzen.
Im autorisierten Zustand stellt die IDFA einen deterministischen Verbindungsschlüssel für unterstützte Werbenetzwerk-Integrationen dar, was eine Kampagnen-Konversionsabstimmung ohne statistische Modellierung ermöglicht. Wenn die Autorisierung verweigert wird, verlagern Anwendungen ihre Messungen auf plattformeigene Frameworks.
Das Problem mit sofortigen Abfragen beim Kaltstart
Das Anfordern der Tracking-Autorisierung unmittelbar beim Kaltstart ist von Apple technisch zulässig, bietet jedoch möglicherweise weniger Kontext für eine informierte Autorisierungsentscheidung, da der Nutzer die Funktionen der Anwendung noch nicht kennengelernt hat:
- Mangelndes Produktvertrauen: Erstnutzer haben noch kein Vertrauen in die Funktionen der Anwendung, den Markenwert oder die Datensicherheitsmaßnahmen aufgebaut.
- Unklarer Kontext: Der native Systemdialog erscheint ohne vorherige Erklärung, was risikoscheue Nutzer dazu veranlasst, standardmäßig „App-Tracking verbieten“ zu wählen.
- Berechtigungs-Müdigkeit: Das Stapeln mehrerer Systemberechtigungsdialoge (wie Push-Benachrichtigungen, ATT und Standort) während des initialen App-Starts erzeugt Reibung und erhöht die Abbruchrate im Onboarding. Die Dokumentation der Apple-API weist darauf hin, dass nachfolgende Autorisierungsanfragen nicht angezeigt werden, wenn bereits eine bestehende Berechtigungswarnung aussteht.

Empirische Evaluierung der Opt-In-Leistung
Die erreichbare Einwilligungsrate variiert je nach App-Kategorie, Zielgruppenvertrauen, Timing der Abfrage und Klarheit des Textes. Teams sollten Optimierungsvarianten mittels kontrollierter A/B-Tests evaluieren, anstatt von festen Branchen-Benchmarks auszugehen.
Siehe auch: IDFA ──> Mobiles Attribuierungsmodell
Technische Mechanik des AppTrackingTransparency Frameworks
Die vier Autorisierungsstatus
Der Zugriff auf die IDFA wird streng durch die ATTrackingManager.AuthorizationStatus-Enum geregelt:
notDetermined(0): Dem Nutzer wurde der Autorisierungsdialog noch nicht angezeigt.restricted(1): Das Gerät ist durch Kindersicherungen, Bildungsprofile oder Unternehmens-MDMs eingeschränkt; die Tracking-Berechtigung kann nicht erteilt werden und der Schalter in den Einstellungen ist deaktiviert.denied(2): Die App hat keine Berechtigung zum Zugriff auf appbezogene Daten für das Tracking, nachdem der Nutzer die Anfrage abgelehnt hat.authorized(3): Der Nutzer autorisiert das Tracking. Auf unterstützten iOS- und iPadOS-Geräten ermöglicht dies normalerweise den Zugriff auf eine von Null verschiedene Werbe-ID.

Die Regel für die einmalige Systemabfrage
Das iOS-Betriebssystem erzwingt eine Regel zur einmaligen Präsentation für ATTrackingManager.requestTrackingAuthorization. Sobald ein Nutzer mit dem nativen Modal durch Auswahl von „Erlauben“ oder „App-Tracking verbieten“ interagiert hat, merkt sich das System den festgelegten Status und zeigt die Abfrage während dieser App-Installation kein weiteres Mal an.
Obwohl die Systemabfrage nicht ein zweites Mal erscheint, können Nutzer ihre Tracking-Autorisierung jederzeit manuell in den iOS-Einstellungen anpassen.
Wie iOS das Nullsetzen von Kennungen erzwingt, wenn die Tracking-Autorisierung verweigert wird
Unter iOS 14.5 und neuer liefert die Werbe-ID normalerweise nur Nullen zurück (00000000-0000-0000-0000-000000000000), wenn keine Tracking-Autorisierung erteilt wurde. Entwickler sollten sowohl den ATT-Autorisierungsstatus als auch den zurückgegebenen Bezeichnerwert bedarfsabhängig überprüfen, anstatt anzunehmen, dass eine zwischengespeicherte Zeichenkette über Anwendungsstarts hinweg gültig bleibt.
UX-Architektur mit hoher Conversion: Die Strategie des Pre-Permission Primers
Anatomie eines effektiven Kontext-Primers: Apple HIG-Einschränkungen
Gemäß den Human Interface Guidelines von Apple zum Thema Datenschutz dürfen Anwendungen vor einer Systemberechtigungsabfrage einen benutzerdefinierten Vorab-Warnungsbildschirm anzeigen, wenn zusätzlicher Kontext erforderlich ist. Apple auferlegt diesen Pre-Permission Primers jedoch strikte Gestaltungsregeln:
- Einzelner Aktionsbutton: Der Vorab-Berechtigungsbildschirm darf nur eine einzige Schaltfläche (wie „Weiter“ oder „Nächstes“) bereitstellen, die direkt zum Systemdialog führt. Er darf keine „Abbrechen“-, „Schließen“- oder „Jetzt nicht“-Schaltfläche bieten, die den Systemhinweis umgeht oder verzögert.
- Keine UI-Nachahmung: Der Primer-Bildschirm darf niemals optisch das native iOS-Systemwarnfeld imitieren oder angebliche Schaltflächen mit der Aufschrift „Erlauben“ anzeigen.
- Keine visuelle Beeinflussung: Die Benutzeroberfläche darf keine Grafiken, Pfeile oder kontrastreichen Stile verwenden, die darauf ausgelegt sind, Nutzer zu manipulieren oder in Richtung der Auswahl von „Erlauben“ im nachfolgenden Systemdialog zu lenken.
Einhaltung der App Store Review-Richtlinie 5.1.2
Unter Abschnitt 5.1.2 der Apple App Store Review-Richtlinien setzt Apple klare Grenzen hinsichtlich Berechtigungsanfragen:
- Verbot von anreizbasiertem Tracking: Apps ist es strengstens untersagt, finanzielle Anreize, virtuelle Währungen, Premium-Inhalte oder Rabatte als Gegenleistung für die Erteilung der ATT-Einwilligung anzubieten. Dies verstößt gegen Richtlinie 5.1.2 und kann zur Ablehnung der App führen.
- Keine Sperrung von Kernfunktionen: Anwendungen dürfen Kernfunktionen nicht blockieren, die Erstellung von Konten verhindern oder die App-Leistung verschlechtern, wenn ein Nutzer die Tracking-Autorisierung ablehnt.
- Vorrang der Nutzerwahl: Die tatsächliche Tracking-Entscheidung des Nutzers muss stets im nativen Apple-Systemdialog getroffen werden.

Stage 1: User Onboarding / Core Value Realization
│
▼
Stage 2: Contextual Pre-Permission Primer Screen
(Single "Continue" Action ── Explains Purpose)
│
▼
Stage 3: Native iOS ATTrackingManager System Modal
(User Selects "Allow" or "Ask App not to Track")
│
┌────────────┴────────────┐
▼ ▼
[.authorized] [.denied]
ATT Authorized Graceful Fallback
(IDFA normally to Platform APIs
available) (AdAttributionKit / SKAN)
Optimierung der NSUserTrackingUsageDescription-Zeichenkette
Konfiguration von Info.plist für Transparenz beim Zweck
Der Schlüssel NSUserTrackingUsageDescription in der Info.plist definiert den erklärenden Text, der direkt im nativen Apple ATT-Systemhinweis angezeigt wird. Laut Apple-Dokumentation muss dieser Text prägnant, spezifisch sein und genau erklären, wie Tracking-Daten verwendet werden.
Testen von Varianten klarer Zweck-Texte ohne Änderung der zugrundeliegenden Offenlegung
Beim Testen von Textvarianten muss jede getestete Variante die tatsächlichen Tracking-Praktiken der Anwendung genau und vollständig beschreiben:
- Der Personalisierungsfokus: Erklärt, wie Daten verwendet werden, um Inhaltsempfehlungen und Produktvorschläge anzupassen.
- Der Fokus auf Werberelevanz: Erklärt, wie Daten verwendet werden, um relevante Angebote bereitzustellen und repetitive Werbung zu vermeiden.
- Der Fokus auf Kampagnenmessung: Erklärt, wie Daten verwendet werden, um die Leistung von Marketingkooperationen zu messen.
Die folgende Konfiguration veranschaulicht ein Beispiel für NSUserTrackingUsageDescription. Verwenden Sie sie nur, wenn der Wortlaut die tatsächlichen Tracking-Praktiken der App präzise beschreibt:
```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>Ihre Daten werden verwendet, um personalisierte Produktempfehlungen sowie relevante Werbeangebote bereitzustellen und die Leistung von Marketingkampagnen zu messen.</string>
</dict>
</plist>
Entwicklung des optimalen Timings für den Abfrage-Auslöser im Nutzerlebenszyklus
Überlegungen zum Timing im gesamten Nutzerverlauf
Obwohl das Anfordern der ATT-Autorisierung beim ersten Start technisch zulässig ist, kann die Anzeige der Abfrage nach dem Erleben des ersten Produktnutzens einen relevanteren Kontext für die Berechtigungsanfrage liefern:
- Post-Onboarding-Auslöser: Anzeige der Abfrage, nachdem der Nutzer die Kontoeinrichtung abgeschlossen und die initialen Einstellungen vorgenommen hat.
- Kontextueller Meilenstein-Auslöser: Anzeige der Abfrage nach Abschluss einer Kernaktion des Nutzers (z. B. Abschluss eines Onboarding-Tutorials in einem Spiel, Speichern eines Lieblingsartikels in einer Shopping-App oder Lesezeichensetzung in einer Content-App).
Technische Implementierung von ATTrackingManager in Swift
Behandlung des aktiven Anwendungszustands und der Threadsicherheit
Gemäß der Apple-API-Dokumentation zeigt ATTrackingManager.requestTrackingAuthorization den modalen Dialog nur dann an, wenn sich die Anwendung im Status .active befindet. Wenn ein anderer Berechtigungsdialog aktiv oder ausstehend ist, wird der Systemhinweis nicht angezeigt, und gleichzeitige Anfragen werden vom Betriebssystem nicht in eine Warteschlange eingereiht.

Die folgende Implementierung trennt die Verwaltung des Autorisierungsstatus von einer anschaulichen, benutzerdefinierten Pre-Permission-Ansicht:
import UIKit
import AppTrackingTransparency
import AdSupport
final class ATTManager {
static let shared = ATTManager()
private init() {}
/// Evaluates current authorization status
var currentStatus: ATTrackingManager.AuthorizationStatus {
return ATTrackingManager.trackingAuthorizationStatus
}
/// Determines if tracking authorization can be presented
var canRequestAuthorization: Bool {
return currentStatus == .notDetermined
}
/// Requests tracking authorization with application active state verification
/// - Parameter completion: Closure returning the resolved authorization status
func requestAuthorization(completion: @escaping (ATTrackingManager.AuthorizationStatus) -> Void) {
guard canRequestAuthorization else {
completion(currentStatus)
return
}
// Verify application is active before invoking requestTrackingAuthorization
guard UIApplication.shared.applicationState == .active else {
print("ATT request skipped: application is not active. Call again once active if status remains notDetermined.")
completion(currentStatus)
return
}
DispatchQueue.main.async {
ATTrackingManager.requestTrackingAuthorization { status in
DispatchQueue.main.async {
switch status {
case .authorized:
// Read the current advertising identifier on demand; do not persist a cached IDFA.
let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
print("ATT Authorized - IDFA available: \(idfa)")
case .denied:
print("ATT Denied - Advertising identifier returns zeroes")
case .restricted:
print("ATT Restricted by system profile")
case .notDetermined:
print("ATT State unresolved")
@unknown default:
print("ATT Unknown state encountered")
}
completion(status)
}
}
}
}
}
/// Illustrative custom UIViewController for a HIG-aligned pre-permission primer
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
// Prevent interactive swipe-to-dismiss when presented modally to ensure single-path navigation
isModalInPresentation = true
titleLabel.text = "Helfen Sie uns, Ihr Erlebnis zu personalisieren"
titleLabel.font = .boldSystemFont(ofSize: 20)
titleLabel.textAlignment = .center
titleLabel.numberOfLines = 0
descriptionLabel.text = "Wir verwenden Daten, um Produktempfehlungen anzupassen und relevante Werbeangebote bereitzustellen. Auf dem nächsten Bildschirm sehen Sie Apples standardmäßigen Berechtigungsdialog zur Bestätigung Ihrer Auswahl."
descriptionLabel.font = .systemFont(ofSize: 15)
descriptionLabel.textAlignment = .center
descriptionLabel.textColor = .secondaryLabel
descriptionLabel.numberOfLines = 0
// Apple HIG guidance calls for a single Continue or Next action
continueButton.setTitle("Weiter", 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() {
// Presentation and dismissal mechanics are illustrative and should be adapted to the app's navigation architecture.
dismiss(animated: true) { [weak self] in
self?.onContinueTapped?()
}
}
}
Wiederherstellung nach Ablehnung: Nutzer zu den Systemeneinstellungen leiten, ohne Richtlinien zu verletzen
Wann sekundäre Einstellungs-Workflows eingeführt werden sollten
Wenn ein Nutzer „App-Tracking verbieten“ auswählt, wechselt der Autorisierungsstatus zu .denied. Nachfolgende Aufrufe von requestTrackingAuthorization geben .denied zurück, ohne einen Dialog anzuzeigen. Wenn ein Nutzer jedoch später eine Funktion startet, die explizit vom Tracking profitiert (wie das Anfordern personalisierter Werbeeinstellungen in seinem Kontoprofil), kann die App einen nicht-koercitiven Pfad zu den iOS-Einstellungen bereitstellen.
Verwendung von UIApplication.openSettingsURLString
Um einen Nutzer zum Einstellungsbereich der App zu leiten, verwenden Sie UIApplication.openSettingsURLString:
if let settingsURL = URL(string: UIApplication.openSettingsURLString),
UIApplication.shared.canOpenURL(settingsURL) {
UIApplication.shared.open(settingsURL, options: [:], completionHandler: nil)
}
Beachten Sie, dass diese API die dedizierte Einstellungsseite der Anwendung öffnet; sie bietet keinen direkten Deep Link zum globalen Bildschirm Einstellungen > Datenschutz & Sicherheit > Tracking.
Grenzen der App Store-Richtlinien
- Kein permanentes Nachfragen: Zeigen Sie keine wiederkehrenden Banner an, die Nutzer dazu auffordern, das Tracking in den Einstellungen zu aktivieren.
- Keine Funktionssperren: Deaktivieren Sie niemals Kernfunktionen, nur weil das Tracking in den Einstellungen deaktiviert bleibt.
Vergleichende Entscheidungsmatrix: Pre-Permission-Strategien im Vergleich zu Kaltstart-Abfragen
| Dimension | Standard-Kaltstart-Abfrage | Hartes Berechtigungs-Modal | HIG-konformer Pre-Permission Primer |
|---|---|---|---|
| Nutzerkontext vor der Abfrage | Gering (Keine Produktinteraktion) | Variiert (Blockiert Zugriff) | Kontextbezogen (Wird nach relevanter Interaktion angezeigt) |
| Apple UI/Berechtigungs-Richtlinien | Zulässig, wenn Anfrage und Datennutzung konform sind | Nicht zulässig, wenn Zugriff oder Vergütung vom Tracking abhängt | Zulässig, wenn HIG-Vorab-Warnungsregeln und Tracking-Vorgaben eingehalten werden |
| Apple Vorab-Warnungs-UI-Einschränkungen | Nicht zutreffend | Nicht zutreffend | Einzelne Weiter/Nächstes-Aktion; keine gefälschten Warnungen |
| Timing der Berechtigungsunterbrechung | Unmittelbar beim Start | Blockierend | Kontextbezogener Meilenstein |
| Beobachtete Opt-In-Rate | Muss empirisch gemessen werden | Nicht zulässig | Muss empirisch gemessen werden |
Häufig gestellte Fragen (FAQ)
Kann eine App In-App-Währung oder Rabatte als Gegenleistung für die Erteilung der ATT-Berechtigung anbieten?
Kann eine App eine zweite ATT-Abfrage anzeigen, wenn der Nutzer sich anfangs für „App-Tracking verbieten“ entschieden hat?
Verstößt ein Pre-Permission Primer gegen die App Store-Richtlinien von Apple?
Zusammenfassung und Entscheidungsrahmen
Die Verbesserung des ATT-Berechtigungsverfahrens erfordert eine klare Offenlegung des Zwecks und ein kontextbewusstes Timing. Wenn zusätzliche Erklärungen erforderlich sind, kann ein HIG-konformer Pre-Permission Primer vor dem Systemdialog Kontext liefern und gleichzeitig das Berechtigungsverfahren mit den veröffentlichten Tracking- und Interface-Richtlinien von Apple in Einklang bringen.
Wenn nach einer ATT-Ablehnung weiterhin Attribuierungs- oder Onboarding-Kontexte erforderlich sind, können Anwendungen unabhängig erlaubte Mechanismen wie AdAttributionKit, bestehende SKAdNetwork-Integrationen oder echtes First-Party-Kontext-Routing verwenden, das im Rahmen der Tracking-Regeln von Apple bleibt.
Für produktspezifisches Kontext-Routing und Attribuierungsverhalten lesen Sie die OpoInstall-Dokumentation und evaluieren Sie die Implementierung anhand der geltenden Apple-Tracking-Anforderungen.
Verwandte Materialien
-
Konzepte: App Tracking Transparency, IDFA-Optimierung, Pre-Permission Primer, Einwilligungstrichter
-
Technologien: StoreKit Framework, AppTrackingTransparency Framework, OpoInstall Mobile SDK
-
Standards: Apple Human Interface Guidelines on Privacy, App Store Review Guidelines Section 5.1.2
-
APIs:
ATTrackingManager.requestTrackingAuthorization,UIApplication.openSettingsURLString,ASIdentifierManager
Offizielle Dokumentation
Share this article



