Apple ATT-Optimierungsleitfaden: So verbessern Sie die ATT-Einwilligungsraten

opoinstall
2026-08-20
5 min read

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.

ATT opt in permission journey and primer flow

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.

ATT authorization status and IDFA behavior

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.

ATT pre permission primer design rules



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.

ATT prompt timing and request conditions

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?
Nein. Abschnitt 5.1.2 der Apple App Store Review-Richtlinien verbietet ausdrücklich das Anbieten von Anreizen – wie virtuelle Währungen, zusätzliche Funktionen, Bargeld oder Rabatte – als Gegenleistung für die Einwilligung des Nutzers zum Tracking. Dies verstößt gegen die Richtlinien der Plattform und kann zur Ablehnung der App führen.
Kann eine App eine zweite ATT-Abfrage anzeigen, wenn der Nutzer sich anfangs für „App-Tracking verbieten“ entschieden hat?
Nein. iOS erlaubt, dass die native ATTrackingManager.requestTrackingAuthorization-Abfrage nur einmal pro App-Installation angezeigt wird. Wenn ein Nutzer die Berechtigung verweigert, geben nachfolgende Aufrufe .denied zurück, ohne einen Dialog anzuzeigen. Um die Berechtigung anzupassen, muss der Nutzer seine Tracking-Auswahl manuell in den iOS-Einstellungen aktualisieren.
Verstößt ein Pre-Permission Primer gegen die App Store-Richtlinien von Apple?
Apple erlaubt eine benutzerdefinierte Vorab-Warnungserklärung, wenn zusätzlicher Kontext erforderlich ist, vorausgesetzt, der Bildschirm entspricht den Human Interface Guidelines: Er muss eine einzige Weiter- oder Nächstes-Aktion verwenden, die direkt zum Systemdialog führt, darf keine Abbrechen- oder Schließen-Aktion auf dem Primer enthalten, darf die native Systemwarnung nicht imitieren und keine Wortlaute oder visuellen Hinweise verwenden, die Nutzer zur Auswahl von Erlauben drängen.

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