Was AppsFlyer erfasst

Das AppsFlyer SDK initialisiert eine Sitzung, sobald die Host-App startet, und erfasst standardmäßig ein Bündel von Identifikatoren und kontextuellen Signalen: den geräteweiten Werbe-Identifikator (IDFA auf iOS, GAID auf Android), den herstellerbezogenen IDFV auf iOS, eine generierte AppsFlyer-Installations-ID, die über Sitzungen hinweg bestehen bleibt, die IP-Adresse (verwendet für Geo-IP und für Fingerprint-basiertes probabilistisches Matching), User Agent, Gerätemodell, Betriebssystemversion, Mobilfunkanbieter und Zeitzone. Nach der Installation meldet das SDK das Installationsereignis an die Server von AppsFlyer, wo es mit den von Ad-Netzwerken weitergeleiteten Klickdaten abgeglichen wird. Nachfolgende In-App-Ereignisse – Kauf, Registrierung abgeschlossen, Tutorial abgeschlossen, benutzerdefiniert – werden über dasselbe SDK ausgelöst und übernehmen denselben Identifikator-Satz.

Regulierungsbehörden haben ausdrücklich festgestellt, dass es sich hierbei um eine Verarbeitung personenbezogener Daten im Sinne der GDPR handelt. IDFA und GAID sind personenbezogene Daten, weil sie persistente geräteweite Identifikatoren sind. Das probabilistische Fingerprint-Matching, das parallel läuft, ist ohne Einwilligung noch schwerer zu rechtfertigen, da es per Definition ein Versuch ist, einen Nutzer ohne dessen ausdrückliche Mitwirkung zu identifizieren. Die CNIL, die italienische Garante und die spanische AEPD haben alle Untersuchungen gegen Publisher eingeleitet, deren Attribution-Stacks vor der Einwilligung ausgelöst wurden.

Native Datenschutzkontrollen von AppsFlyer

AppsFlyer stellt eine bedeutende Reihe nativer Datenschutz-Primitiven zur Verfügung. Sie sind kein Ersatz für ein echtes Consent-Framework, aber ihr Verständnis ist unerlässlich, da sie die Hebel sind, die ein CMP zur Steuerung des SDK-Verhaltens nutzt.

Die Start SDK API

Das SDK unterstützt einen Initialisierungsmodus, in dem es konfiguriert wird, aber keine Daten überträgt, bis start() explizit aufgerufen wird. Dies ist der wichtigste einzelne Hook für Consent-Gating – standardmäßig startet das SDK automatisch beim App-Start, was für jede Rechtsordnung mit einer Vorab-Einwilligungspflicht das falsche Verhalten ist. Setzen Sie isStopped bei der Initialisierung auf true oder verwenden Sie die Deferred-Start-API und rufen Sie start() erst auf, wenn das Einwilligungssignal erfasst wurde.

Stop-API

Wenn die Einwilligung während einer Sitzung widerrufen wird, stoppt der Aufruf von stop() jede weitere Übertragung. Bereits gesendete Daten werden dadurch nicht rückwirkend gelöscht. Für eine vollständige Löschung müssen Sie eine Betroffenen-Löschanfrage über das Datenschutzportal von AppsFlyer stellen – eine Integration, die Teams über die AppsFlyer-API automatisieren sollten, anstatt einen manuellen Workflow zu verwenden.

setSharingFilter

Dieser filtert, welche nachgelagerten Ad-Netzwerke Postback-Daten erhalten. Er ist die richtige Primitive für granulare partnerspezifische Einwilligung – beispielsweise die Attribution generell zu erlauben, aber Weiterleitungen an ein bestimmtes Netzwerk zu blockieren, das der Nutzer abgelehnt hat.

Apple App Tracking Transparency-Integration

Auf iOS liest AppsFlyer den ATT-Autorisierungsstatus und passt sein Verhalten automatisch an – wenn der Nutzer ATT abgelehnt hat, wird IDFA nicht übertragen. ATT ist unabhängig von der GDPR-Einwilligung, und viele Publisher verwechseln beides. ATT kontrolliert ein einzelnes iOS-spezifisches Signal; die GDPR-Einwilligung kontrolliert alles andere.

Integration auf iOS

Das zuverlässige Muster auf iOS besteht darin, das AppsFlyer SDK zu installieren, aber die Initialisierung aufzuschieben, bis sowohl ATT als auch der In-App-Consent-Flow abgeschlossen sind. Die minimale Sequenz ist: App startet, das SDK wird mit isStopped = true konfiguriert, das In-App-Consent-Banner wird angezeigt, der Nutzer akzeptiert die relevanten Kategorien, das isStopped-Flag des SDK wird zurückgesetzt und start() wird aufgerufen. Wenn die App auch ATT benötigt (was für jeden Nutzer gilt, bei dem IDFA relevant ist), wird der ATT-Prompt zusammen mit oder nach dem In-App-Banner angezeigt. Die meisten CMPs, die Mobile unterstützen, haben eine Callback-basierte API, die die Einwilligungsentscheidung liefert; dieser Callback ist der richtige Ort, um start() aufzurufen.

Integration auf Android

Die Android-Implementierung entspricht iOS mit zwei Unterschieden. Erstens gibt es kein ATT-Äquivalent – GAID ist verfügbar, es sei denn, der Nutzer hat die geräteweite Einstellung „Werbe-ID löschen" aktiviert, was die meisten Nutzer nicht tun. Zweitens ist der Android-Lebenszyklus aggressiver beim Hintergrund-Versetzen, sodass die SDK-Initialisierung an den persistent gespeicherten Consent-Status gebunden werden muss. Lesen Sie den Consent-Status beim App-Start aus dem lokalen Speicher, konfigurieren Sie das SDK entsprechend und prüfen Sie beim Fortsetzen erneut, falls der Nutzer seine Wahl aktualisiert hat, während die App im Hintergrund war.

Integration im mobilen Web

AppsFlyer operiert auch im mobilen Web über seine Smart-Banner- und OneLink-Produkte. Diese sind im Wesentlichen webseitige Analyse- und Deep-Link-Tools, die Cookies setzen und AppsFlyer-Server vom Browser aus aufrufen. Sie unterliegen denselben Regeln wie jede andere Web-Tracking-Oberfläche: Schalten Sie sie hinter die Marketing-Kategorie des CMP, lassen Sie das Smart-Banner-Skript nicht vor der Einwilligung ausführen und stellen Sie sicher, dass alle durch OneLink ausgelösten Ereignisse aus E-Mail- oder Push-Kampagnen den Consent-Status des Nutzers berücksichtigen.

Häufige Fallstricke

Vier Integrationsfehler tauchen wiederholt bei Audits von AppsFlyer-Implementierungen auf.

ATT als GDPR-Einwilligung behandeln

ATT und GDPR-Einwilligung sind unterschiedliche Signale mit unterschiedlichem Geltungsbereich. Ein Nutzer, der ATT akzeptiert, hat die IDFA-Nutzung für App-übergreifendes Tracking autorisiert; er hat nicht alles andere autorisiert, was das SDK tut. Für EU- und UK-Traffic sind beide Signale erforderlich, wobei das In-App-Banner das bindende ist und ATT eine iOS-spezifische zusätzliche Schicht darstellt.

Das SDK beim Start initialisieren lassen

Dies ist der häufigste einzelne Fehler. Die Standard-Integration ruft start() sofort auf, was das Installationsereignis mit vollständiger Identifikator-Payload auslöst, bevor der Nutzer das Consent-Banner gesehen hat. Die Behebung ist unkompliziert: Konfigurieren Sie isStopped = true bei der Integration und rufen Sie start() nur aus dem Consent-Callback auf.

Vergessen, den Widerruf zu behandeln

Wenn ein Nutzer akzeptiert und später widerruft, muss dem SDK mitgeteilt werden, die Übertragung einzustellen. Verwenden Sie die stop()-API und aktualisieren Sie den persistent gespeicherten Consent-Status, damit der nächste App-Start die neue Entscheidung berücksichtigt.

Server-zu-Server-Postbacks ignorieren

AppsFlyer leitet Conversion-Ereignisse über serverseitige Postbacks an eine lange Liste integrierter Ad-Netzwerke weiter. Jede Weiterleitung enthält personenbezogene Daten und erbt den Einwilligungsumfang des ursprünglichen Ereignisses. Verwenden Sie setSharingFilter, um sicherzustellen, dass Weiterleitungen nur an Partner gehen, die von den Einwilligungsentscheidungen des Nutzers abgedeckt sind, nicht an jeden Partner in Ihrem AppsFlyer-Dashboard.

Audit-Checkliste

Sechs konkrete Fragen, die für jede AppsFlyer-Implementierung mit EU-, UK- oder Kalifornien-Traffic zu beantworten sind.

• Wartet das SDK auf die Einwilligung? Bestätigen Sie bei einer Neuinstallation auf einem in der EU lokalisierten Testgerät, dass kein AppsFlyer-Endpunkt eine Anfrage erhält, bevor der Nutzer das Banner akzeptiert hat.
• Ist ATT von der In-App-Einwilligung getrennt? Bestätigen Sie, dass das In-App-Banner das kontrollierende Einwilligungssignal ist und ATT als zusätzliche iOS-spezifische Schicht behandelt wird.
• Ist die Partner-Weiterleitung auf die Einwilligung beschränkt? Bestätigen Sie, dass setSharingFilter so konfiguriert ist, dass Partner ausgeschlossen werden, die der Nutzer nicht autorisiert hat.
• Stoppt der Widerruf das SDK? Bestätigen Sie, dass der Aufruf von stop() beim Einwilligungswiderruf funktioniert und dass der neue Status über App-Starts hinweg bestehen bleibt.
• Werden Server-Postbacks überprüft? Bestätigen Sie, dass die Liste der „Konfigurierten Integrationen" im AppsFlyer-Dashboard sauber den im Banner offengelegten Marketing-Partnern zugeordnet ist.
• Ist die Datenlöschung automatisiert? Bestätigen Sie, dass DSAR-Anfragen die Löschungs-API von AppsFlyer auslösen, nicht ein manuelles Ticket.

Wo AppsFlyer in einen Consent-First-Stack passt

Mobile Attribution ist eine der identifikatorintensivsten Oberflächen im Marketing-Stack, und das SDK von AppsFlyer ist eine seiner folgenreichsten einzelnen Integrationen. Die gute Nachricht ist, dass die Plattform die Primitiven bereitstellt – Start SDK, Stop, Sharing-Filter, Löschungs-APIs – die für eine saubere und überprüfbare Consent-Durchsetzung erforderlich sind. Die Aufgabe der Publisher besteht darin, diese Primitiven mit einem CMP zu verbinden, das die bindende Einwilligungsentscheidung besitzt, ATT als ergänzendes Signal statt als Ersatz zu behandeln und sicherzustellen, dass die serverseitige Partner-Weiterleitung nicht dem Einwilligungsrahmen entweichen kann, den das Banner erfasst hat. Korrekt umgesetzt ist das Ergebnis ein Attribution-Stack, der Regulierungsbehörden zufriedenstellt und gleichzeitig die Installations- und Ereignisdaten bewahrt, auf die User-Acquisition-Teams angewiesen sind.