App Tracking Transparency (ATT): iOS-Datenschutz-Prompts korrekt einbinden

1. Was App Tracking Transparency technisch ist

App Tracking Transparency ist ein von Apple seit iOS 14.5 verpflichtend vorgeschriebenes Framework, das jede App zwingt, vor dem Zugriff auf den Identifier for Advertisers, kurz IDFA, eine explizite Systemabfrage anzuzeigen. Ohne diese Zustimmung liefert das System für IDFA-Anfragen ausschließlich eine Nullkette zurück, wodurch geräteübergreifendes Tracking zu Werbezwecken technisch unmöglich wird.

Der Prompt selbst wird ausschließlich vom Betriebssystem gerendert, nicht von der App selbst, wodurch Entwickler weder Text noch Layout des eigentlichen Systemdialogs verändern können. Apple stellt damit sicher, dass die Formulierung app-übergreifend konsistent und für Nutzer eindeutig verständlich bleibt, unabhängig davon, welche App den Prompt auslöst.

2. Unterschied zwischen App-Tracking und geräteinternem Tracking

Der ATT-Prompt betrifft ausdrücklich nur Tracking, das Daten mit anderen Apps oder Websites Dritter verknüpft oder an Datenbroker weitergibt, um ein geräteübergreifendes Nutzerprofil zu erstellen. Klassisches First-Party-Analytics, das ausschließlich innerhalb der eigenen App bleibt und keine Daten mit Dritten zu Werbezwecken teilt, fällt nicht unter diese Zustimmungspflicht.

Diese Unterscheidung ist für die technische Implementierung wichtig, weil sie bestimmt, welche SDKs den Prompt tatsächlich auslösen müssen. Ein reines Crash-Reporting-Tool ohne geräteübergreifende Profilbildung benötigt in der Regel keine ATT-Zustimmung, während ein Werbenetzwerk-SDK, das Conversions über App-Grenzen hinweg zuordnet, klar in den Geltungsbereich fällt.

3. Praktische Einbindung mit react-native-tracking-transparency

In React Native lässt sich der Prompt über die Bibliothek react-native-tracking-transparency einbinden, die die native ATTrackingManager-API von Apple in eine JavaScript-Schnittstelle übersetzt. Der zentrale Aufruf requestTrackingPermission zeigt den Systemdialog an und liefert den gewählten Status als Promise zurück, sobald der Nutzer eine Entscheidung getroffen hat.

Zusätzlich muss der Info.plist-Eintrag NSUserTrackingUsageDescription gesetzt werden, der den erklärenden Text unterhalb des Systemtitels im Prompt liefert. Fehlt dieser Eintrag, stürzt die App beim Aufruf der Tracking-API ab, statt den Prompt einfach ohne Beschreibungstext anzuzeigen.

import { requestTrackingPermission } from 'react-native-tracking-transparency';

async function requestAttIfNeeded() {
  const status = await requestTrackingPermission();
  // status: 'authorized' | 'denied' | 'restricted' | 'unavailable'
  if (status === 'authorized') {
    initializeAdvertisingSdk();
  } else {
    initializeContextualAdsOnly();
  }
  return status;
}

4. Den richtigen Zeitpunkt für den Prompt wählen

Der Prompt darf pro App-Installation nur einmal angezeigt werden, ein erneuter programmatischer Aufruf nach einer bereits getroffenen Entscheidung öffnet den Systemdialog kein zweites Mal, sondern liefert direkt den zuvor gespeicherten Status zurück. Der Zeitpunkt des ersten Aufrufs beeinflusst die Zustimmungsrate daher erheblich und verdient bewusste Planung.

Ein Prompt direkt beim ersten App-Start, bevor der Nutzer überhaupt einen Mehrwert der App erlebt hat, führt in der Praxis zu spürbar niedrigeren Zustimmungsraten als ein Prompt, der erst nach einer kurzen Erklärungsseite oder nach dem ersten erfolgreichen Nutzungserlebnis erscheint. Viele Apps zeigen deshalb zunächst einen eigenen, gestalteten Vorab-Screen, der den Nutzen des Trackings erklärt, bevor der native Systemdialog ausgelöst wird. Ein A/B-Test zwischen unterschiedlichen Zeitpunkten und Formulierungen liefert dabei belastbarere Erkenntnisse als eine reine Bauchentscheidung des Produktteams.

5. Ein eigener Vorab-Screen vor dem nativen Systemdialog

Ein selbst gestalteter Vorab-Screen darf inhaltlich nicht irreführend formuliert sein und keinesfalls suggerieren, dass eine Ablehnung im nachfolgenden Systemdialog zu Funktionseinschränkungen der App führt, sofern das tatsächlich nicht der Fall ist. Apple prüft solche Formulierungen im App-Review-Prozess und lehnt manipulative Vorab-Screens konsequent ab.

Sinnvoll ist stattdessen eine sachliche Erklärung, warum personalisierte Inhalte oder Werbung für den Nutzer einen Mehrwert bieten können, verbunden mit einem klaren Button, der den nativen Prompt erst nach bewusster Nutzerinteraktion auslöst. Dieser Ansatz respektiert sowohl Apples Richtlinien als auch die tatsächliche Entscheidungsfreiheit des Nutzers.

6. Konsequenzen einer Ablehnung für Analytics- und Werbe-SDKs

Lehnt der Nutzer das Tracking ab oder wählt das System den Status restricted, etwa wegen aktivierter Bildschirmzeit-Beschränkungen, liefert die IDFA-Abfrage ausschließlich Nullen zurück. Werbenetzwerke, die für Retargeting oder geräteübergreifende Attribution auf die IDFA angewiesen sind, können betroffene Nutzer dann nicht mehr eindeutig identifizieren und fallen auf aggregierte, weniger präzise Signale zurück.

Apples SKAdNetwork-Framework bietet für Werbe-Attribution eine datensparsame Alternative, die auch ohne ATT-Zustimmung funktioniert, allerdings mit deutlich verzögerten und aggregierten Reports statt Echtzeit-Einzeldaten. Analytics-SDKs ohne Werbebezug, etwa reine Absturz- und Nutzungsstatistiken innerhalb der eigenen App, bleiben von einer ATT-Ablehnung in der Regel vollständig unberührt.

7. Alle vier Statuswerte korrekt behandeln

Der Rückgabewert des Prompts kennt vier mögliche Zustände: authorized, denied, restricted und notDetermined, wobei notDetermined nur vor der ersten Anzeige des Prompts auftritt. Apps sollten alle vier Zustände explizit im Code behandeln, statt fälschlich nur zwischen einem binären Ja oder Nein zu unterscheiden.

Besonders der Zustand restricted verdient eigene Aufmerksamkeit, da er unabhängig vom Nutzerwillen durch Geräteeinstellungen wie aktivierte Bildschirmzeit-Beschränkungen für Minderjährige erzwungen wird. In diesem Fall darf die App den Prompt gar nicht erst anzeigen, da das System ihn automatisch unterdrückt und sofort den Status restricted zurückliefert.

8. App-Review und die Declared-App-Privacy-Angaben

Apple prüft im App-Review-Prozess explizit, ob eine App, die tatsächlich trackt, den ATT-Prompt korrekt einbindet, und lehnt Einreichungen ab, bei denen Tracking-SDKs aktiv sind, ohne dass zuvor eine Zustimmung eingeholt wurde. Ergänzend müssen die App-Privacy-Angaben im App Store Connect korrekt widerspiegeln, welche Datentypen tatsächlich zu Tracking-Zwecken erfasst werden.

Eine Diskrepanz zwischen den deklarierten Privacy-Angaben und dem tatsächlichen SDK-Verhalten in der App, etwa ein Werbe-SDK, das trotz fehlender Deklaration Tracking-Daten sammelt, führt regelmäßig zu Ablehnungen im Review oder zu nachträglichen Beanstandungen, selbst wenn die ATT-Implementierung selbst technisch korrekt ist.

9. Testing des ATT-Flows vor der Veröffentlichung

Da der Prompt pro Installation nur einmal erscheint, muss für Tests entweder die App vollständig deinstalliert und neu installiert oder die Tracking-Berechtigung über die Einstellungen-App unter Datenschutz und Sicherheit zurückgesetzt werden. Ein einfacher Neustart der App reicht nicht aus, um den Prompt für einen erneuten Testdurchlauf wieder auszulösen.

Vor der Veröffentlichung sollte explizit getestet werden, wie sich die App bei jedem der vier möglichen Statuswerte verhält, insbesondere ob Werbe- und Analytics-SDKs bei einer Ablehnung tatsächlich auf datensparsame Alternativen umschalten, statt weiterhin unbemerkt IDFA-Anfragen zu stellen, die ohnehin nur Nullen zurückliefern. Ergänzend lohnt sich ein automatisierter UI-Test, der sicherstellt, dass der eigene Vorab-Screen bei jedem der vier Zustände korrekt reagiert und niemals versucht, den nativen Prompt ein zweites Mal programmatisch zu erzwingen, was ohnehin technisch wirkungslos bliebe.

10. Zusammenfassung

11. FAQ: App Tracking Transparency: Das Wichtigste auf einen Blick