App-Store-Datenschutzlabels: zuerst die Analytics-SDKs prüfen (Checkliste 2026)

Ihre App-Store-Datenschutzlabels müssen abdecken, was Ihre Analytics- und anderen Drittanbieter-SDKs erfassen, nicht nur das, was Ihr eigener Code sendet. Bevor Sie die Fragen zum App-Datenschutz in App Store Connect beantworten, listen Sie jedes SDK im Release auf, notieren die Daten, die es vom Gerät sendet, und entscheiden, ob davon etwas für Tracking verwendet wird. Antworten Sie anhand dieser Liste, nicht aus dem Gedächtnis.

Müssen App-Store-Datenschutzlabels Daten von Drittanbieter-SDKs enthalten?

Ja. Apple verlangt, dass Sie Daten angeben, die der Code von Drittanbieter-Partnern erfasst, auch wenn das SDK diese Daten aus anderen Gründen als Analytics oder Werbung erfasst.

Apples Seite zum App-Datenschutz definiert Drittanbieter-Partner als „Analytics-Tools, Werbenetzwerke, Drittanbieter-SDKs oder andere externe Anbieter, deren Code Sie Ihrer App hinzugefügt haben“. Ein Crash-Reporter oder eine Anmeldebibliothek gehört also auf Ihre Liste. Entscheidend für die Erfassung ist die Übertragung: „Erfassen“ bedeutet, „Daten so vom Gerät zu übertragen, dass Sie und/oder Ihre Drittanbieter-Partner länger darauf zugreifen können, als nötig ist, um die übertragene Anfrage in Echtzeit zu bearbeiten“. Daten, die nur auf dem Gerät verarbeitet werden, gelten nicht als erfasst.

Wie erstellen Sie eine SDK-Inventur für Datenschutzlabels?

Erstellen Sie die Inventur aus den aufgelösten Abhängigkeiten des Release-Builds, einschließlich transitiver Abhängigkeiten, und notieren Sie Name und Version jedes SDKs.

1. Exportieren Sie für jede Plattform die aufgelöste Abhängigkeitsliste: Podfile.lock, Package.resolved, pubspec.lock oder Ihren Gradle-Abhängigkeitsbaum.
2. Behalten Sie transitive Abhängigkeiten bei. Laut Apples Anforderungen an Drittanbieter-SDKs sind Sie „für den gesamten Code verantwortlich, den das SDK in Ihre App einbringt“, also zählt auch ein gemeinsam genutztes Modul, das ein SDK nachzieht.
3. Notieren Sie Name und Version jedes Eintrags. Anbieter ändern ihren Umgang mit Daten zwischen Versionen, daher gehört die Version in Ihre Audit-Notizen.
4. Markieren Sie SDKs, die auf Apples Liste häufig genutzter Drittanbieter-SDKs stehen. Für diese verlangt Apple Privacy Manifests, wenn Sie eine neue App oder ein Update einreichen, das sie hinzufügt, und Signaturen, wenn sie als Binärabhängigkeiten eingebunden sind. „Jede Version eines gelisteten SDKs sowie alle SDKs, die gelistete SDKs neu verpacken, sind eingeschlossen.“

Nehmen Sie diesen Schritt in Ihre Checkliste für die App-Store-Einreichung auf, damit er bei jedem Release läuft, nicht nur beim ersten.

Welchen App-Store-Datentypen entspricht jedes SDK?

Jedes SDK entspricht einem oder mehreren von Apples festen Datentypen, etwa Absturzdaten, Leistungsdaten, Produktinteraktion, Geräte-ID und Werbedaten. Lesen Sie die Datendokumentation des Anbieters und füllen Sie für jedes SDK eine Zeile aus:

Laut Apple sind erfasste Daten „häufig mit der Identität des Nutzers verknüpft, sofern nicht vor der Erfassung bestimmte Datenschutzmaßnahmen getroffen werden, um sie zu de-identifizieren oder zu anonymisieren“, etwa indem direkte Identifikatoren wie Nutzer-ID oder Name entfernt werden. Nach der Erfassung dürfen Sie die Daten außerdem nicht wieder mit dem Nutzer verknüpfen oder mit anderen Datensätzen verbinden, die ihn identifizieren. Wenn Sie nicht bestätigen können, dass ein SDK Daten de-identifiziert, markieren Sie sie als verknüpft.

Wann zählt ein Analytics-SDK als Tracking?

Ein Analytics-SDK zählt als Tracking, wenn es Daten über Ihre Nutzer oder Geräte für gezielte Werbung oder Werbemessung mit Daten aus Apps oder Websites anderer Unternehmen verknüpft oder diese Daten mit einem Datenhändler teilt.

Apples Definition lautet: „das Verknüpfen von Daten, die Ihre App über einen bestimmten Endnutzer oder ein bestimmtes Gerät erfasst, etwa eine Nutzer-ID, Geräte-ID oder ein Profil, mit Drittanbieterdaten für gezielte Werbung oder Werbemessung, oder das Teilen von Daten, die Ihre App über einen bestimmten Endnutzer oder ein bestimmtes Gerät erfasst, mit einem Datenhändler“. Analytics, das innerhalb der Daten Ihrer eigenen App bleibt, ist kein Tracking. Werbemessung, die eine Kennung über Apps hinweg teilt, schon.

Die Falle ist ein Partner, der kein Werbe-SDK ist. Apples Beispiel ist „ein Login-SDK, das die Daten, die es aus Ihrer App erfasst, umfunktioniert, um gezielte Werbung in Apps anderer Entwickler zu ermöglichen“. Das zählt als Tracking, auch wenn Sie das SDK nicht zu diesem Zweck verwenden. Wenn eines Ihrer SDKs das tut, ist die übliche Lösung eine Konfigurationsänderung, die die app-übergreifende Nutzung unterbindet, oder ein anderer Anbieter.

Dürfen Sie SDK-Daten in Ihren Datenschutzlabels weglassen?

Nur wenn ein Datentyp alle vier Kriterien von Apple für die optionale Offenlegung erfüllt, und Analytics- und Absturzdaten tun das so gut wie nie. Die Kriterien sind:

• Die Daten werden nicht für Tracking verwendet.
• Sie werden nicht für Werbung Dritter, Ihre eigene Werbung oder Ihr Marketing oder andere Zwecke verwendet.
• Sie werden nur in seltenen Fällen außerhalb der Kernfunktion der App erfasst, und die Angabe ist für den Nutzer freiwillig.
• Der Nutzer gibt sie in der Oberfläche der App selbst ein, es ist für ihn klar, was erfasst wird, sein Name oder Kontoname wird im Eingabeformular deutlich angezeigt, und er entscheidet sich jedes Mal aktiv dafür, sie bereitzustellen.

Apple ergänzt: „Daten, die nach einer anfänglichen Erlaubnisanfrage fortlaufend erfasst werden, müssen offengelegt werden.“ Analytics-SDKs laufen kontinuierlich, und der Nutzer entscheidet sich nicht jedes Mal dafür, also fallen sie bei den letzten beiden Kriterien durch.

Wie sieht ein fertiger SDK-Audit aus?

Ein fertiger Audit gibt jedem SDK eine Zeile, die festhält, was anzugeben ist, ob die Daten mit dem Nutzer verknüpft sind und ob sie für Tracking verwendet werden. Hier ist die Vorlage für eine hypothetische Habit-Tracking-App mit drei SDKs. Die Antworten hängen von der Dokumentation des jeweiligen Anbieters ab, es handelt sich also nicht um Befunde zu realen Produkten.

Die Anmelde-Zeile verändert die Arbeit. Sie macht die App zu einer Tracking-App, also müssen die Labels das angeben, und Ihre Einwilligungsabfrage muss dazu passen. Ein Wechsel zu einem Anmeldeanbieter, der keine Daten app-übergreifend teilt, oder das Abschalten dieser Weitergabe ist vor der Einreichung weit günstiger als nach einer Ablehnung. Testen Sie anschließend den Release-Build mit allen aktivierten SDKs, wie im Testplan für den Release-Build.

Was ist bei anderen Entwicklern schiefgelaufen?

Öffentlich berichtete Fälle zeigen drei Fehlerquellen: Labels, die nicht zum Binary passen, SDK-Daten, von denen der Entwickler nichts wusste, und gelistete SDKs, die ohne Manifest ausgeliefert wurden.

• Ein Entwickler in den Apple Developer Forums entfernte das Tracking aus einem neuen Build, konnte es aber nicht aus dem Label entfernen. App Store Connect meldete: „Ihre App enthält NSUserTrackingUsageDescription, was darauf hinweist, dass Sie die Erlaubnis zum Tracking von Nutzern anfordern werden“, und das Review lehnte immer wieder ab mit: „Die Datenschutzangaben, die Sie in App Store Connect gemacht haben, weisen darauf hin, dass Sie Daten erfassen, um den Nutzer zu tracken … Sie verwenden jedoch nicht App Tracking Transparency.“ Laut dem Entwickler wurde die App freigegeben, nachdem er Einspruch eingelegt und vor der erneuten Einreichung die Antwort abgewartet hatte.
• Ein anderer Entwickler in den Apple Developer Forums nutzte Firebase Analytics mit deaktivierter IDFA- und IDFV-Erfassung und einem Label ohne Tracking und erhielt trotzdem eine Ablehnung nach Richtlinie 5.1.2. In der Nachricht hieß es: „Das Erfassen von Cookies ist eine Form von Tracking.“ Sie bezog sich auf Cookies in Webinhalten, die die App lud, nicht auf Firebase. Eine Antwort wies auf diese Diskrepanz hin, eine Lösung wurde nicht gepostet.
• Entwickler in einem RxSwift-GitHub-Issue erhielten „ITMS-91061: Missing privacy manifest“ für RxSwift, RxRelay und RxCocoa. Ein Nutzer ließ CocoaPods auf den Branch 6.8.0 zeigen, der das Manifest enthält, und berichtete, das nächste Update „ohne Warnungen von Apple“ ausgeliefert zu haben.

Der gemeinsame Nenner: Apple vergleicht Ihre Antworten mit dem, was das ausgelieferte Binary und seine Webinhalte tatsächlich tun. Eine Inventur auf Basis des echten Builds fängt daher alle drei Probleme ab, bevor das Review es tut.

Wie veröffentlichen und aktualisieren Sie Datenschutzlabels in App Store Connect?

Veröffentlichen Sie Datenschutzlabels im Bereich App-Datenschutz Ihrer App in App Store Connect. Die Antworten gehen erst live, wenn Sie auf Veröffentlichen klicken, und laut Apple können Sie sie jederzeit ändern, ohne ein App-Update einzureichen.

1. Wählen Sie in App Store Connect die App aus, klicken Sie in der Seitenleiste auf App-Datenschutz und dann auf Los geht's.
2. Geben Sie an, ob Sie oder Ihre Drittanbieter-Partner Daten erfassen, wählen Sie jeden Datentyp aus Ihrem Audit aus und klicken Sie auf Sichern.
3. Beantworten Sie die Folgefragen zu jedem Datentyp, klicken Sie auf Sichern und prüfen Sie die Vorschau der Produktseite.
4. Klicken Sie oben rechts auf Veröffentlichen und bestätigen Sie den Dialog zur Richtigkeit der Angaben.

Laut App-Datenschutz verwalten benötigen Sie die Rolle Kontoinhaber, Admin oder App-Manager. Ist die Produktseite noch nicht live, werden Ihre Antworten veröffentlicht, sobald sie live geht. Ist die App bereits erhältlich, sollten Ihre Antworten nur die Daten wiedergeben, die diese Version erfasst. Änderungen an URLs der Datenschutzrichtlinie „werden mit Ihrer nächsten App-Version veröffentlicht“. Hat das Review bereits Datenschutzprobleme beanstandet, beginnen Sie mit der Anleitung zur Behebung von App-Store-Ablehnungen.