SKAN (SKAdNetwork)

Definition: SKAdNetwork (SKAN) ist Apples datenschutzkonformes Framework für die Attribution von App-Installationen auf iOS-Geräten ohne geräteindividuelles Tracking und ohne IDFA. Eingeführt mit iOS 14 (2020) als Reaktion auf das ATT-Framework (App Tracking Transparency): da IDFA-Opt-in-Raten auf 20–40 % sanken, brauchte die Branche einen datenschutzkonformen Attributionsmechanismus. Funktionsprinzip: Apple vermittelt als vertrauenswürdiger Dritter – das Ad-Network signiert eine Anzeige kryptografisch, Apple verifiziert Installation und App-Nutzung auf dem Gerät, und sendet aggregierte Postbacks (ohne individuelle Nutzer-IDs) an das Ad-Network. Conversion Values: 6-Bit-Wert (0–63) der frei konfigurierbar ist und In-App-Events der ersten 24–48 Stunden repräsentiert; Granularität eingeschränkt. Postback-Verzögerung: 24–72 Stunden nach Install, dann weitere 24h für Conversion-Window. SKAN 4.0 (seit iOS 16.1, 2022): mehrere Timer-Fenster, Coarse Conversion Values (low/medium/high), Web-to-App-Attribution, Lock Window für sofortigen Postback. MMPs (AppsFlyer, Adjust, Branch): bieten SKAN-Dashboards und Conversion-Value-Konfiguration.

Erläuterung

SKAN ist der schwierigste Paradigmenwechsel im Mobile Marketing seit dem Smartphone: von nutzerindividueller, echtzeit-Attribution zu aggregierter, verzögerter Attribution. Kampagnenoptimierung die früher auf Nutzerebene funktionierte (welcher Nutzer kauft wieviel?) ist mit SKAN nur noch auf aggregierter Ebene möglich. Wer SKAN nicht versteht, verschwendet iOS-Budget oder optimiert auf falsche Signale.

SKAN-Mechanismus im Detail

Kryptografische Signierung: Ad-Network signiert Werbeanzeige mit privatem Schlüssel (Kampagnen-ID, Ad-Network-ID, Timestamp); Nutzer sieht Anzeige → installiert App → App-Store verifiziert Signatur; Apple bestätigt Installation ohne Weitergabe individueller Nutzer-IDs an Ad-Network; Kampagnen-ID (SKAN 3.x): max. 100 Kampagnen je Ad-Network und App; SKAN 4.0: erhöhte Kampagnenlimits und Hierarchie (Campaign → Ad Group → Creative)
Conversion Values (SKAN 3.x): 6-Bit-Wert: Zahlen 0–63 (64 mögliche Werte); App setzt CV via updateConversionValue()-API wenn Nutzer-Event eintritt; Timer: 24h nach letztem CV-Update läuft ab → Postback wird ausgelöst; Timer wird zurückgesetzt wenn neues höheres CV gesetzt wird (max. 1–2 mal Reset möglich); nur aufsteigende CV-Werte erlaubt; Beispiel-Konfiguration: 0 = Install (keine weitere Aktion), 1–10 = Tutorial-Schritte, 11–30 = Engagement-Events, 31–63 = Revenue-Brackets (z.B. 31 = $0–$1, 32 = $1–$5)
SKAN 4.0 (iOS 16.1+): Drei Timer-Fenster: Fenster 1 (0–2 Tage): Fine Conversion Value (0–63); Fenster 2 (3–7 Tage): Coarse Value (low/medium/high); Fenster 3 (8–35 Tage): Coarse Value; Lock Window: App kann Postback-Zeitpunkt erzwingen für schnellere Daten; Crowd Anonymity: Post-back nur bei ausreichend großer Zielgruppe (Datenschutz-Threshold); Source Identifier: 2–4 stellig, hierarchisch (Campaign/Ad Group/Creative/Location); Web-to-App: Attribution von Safari-Klicks zu App-Installs
Postback-Flow: App-Install → App läuft für erste Events (24–48h) → CV wird gesetzt → Timer läuft ab → Postback von Apple-Server an Ad-Network-Endpoint; Postback enthält: App-ID, Ad-Network-ID, Campaign ID, CV (wenn Crowd Anonymity erfüllt), Transaction ID; kein individueller Nutzer-Identifier; Ad-Network sendet Postback an MMP (falls konfiguriert); Gesamtverzögerung: 2–7 Tage bis zur Datenverfügbarkeit

Conversion Value Mapping: Strategie

Revenue-basiertes Mapping: Häufigste Strategie für E-Commerce und Gaming (IAP); CV-Werte repräsentieren Revenue-Brackets in erster Nutzungswoche; Beispiel: 0 = kein Revenue, 1 = $0,01–$0,99, 2 = $1–$2,99, 3 = $3–$9,99, ... 15 = $100+; Vorteil: direkte Optimierung auf LTV; Nachfrage: ausreichend In-App-Revenue in ersten 24h für CV-Signale (bei Subscription-Apps oft zu spät)
Event-basiertes Mapping: CV-Werte repräsentieren Engagement-Events; geeignet für Apps ohne sofortigen Revenue (Social, Content, Utility); Beispiel: 1 = Registrierung, 2 = erster Content-Aufruf, 3 = Feature X genutzt, 4 = Push-Opt-in, 5 = Tag-3-Retention; Problem: Events nach 24–48h liegen außerhalb des Conversion-Windows; Lösung: Proxy-Events nutzen (Day-1-Aktivierungsschritte die D7-Retention vorhersagen)
Kombiniertes Mapping: Bit-basiertes Mapping: jedes Bit des 6-Bit-CV repräsentiert ein separates Event (Bit 0 = Tutorial, Bit 1 = Push-Opt-in, Bit 2 = Profil erstellt, Bit 3 = erster Kauf, ...); bis zu 6 gleichzeitige Events in einem CV-Wert; Vorteil: maximale Information pro CV; Nachteil: komplexe Konfiguration und Dateninterpretation; MMP-Tools (AppsFlyer Conversion Studio, Adjust SKAN Analytics) vereinfachen Konfiguration

MMP-Integration und Kampagnen-Optimierung

MMP-Rolle (AppsFlyer, Adjust, Branch): Empfangen SKAN-Postbacks von Ad-Networks; Mapping von CV-Werten zurück auf konfigurierte Events und Revenue-Brackets; Dashboard: SKAN-Attribution nach Kanal/Kampagne; Probabilistisches Modeling: kombiniert SKAN-Daten mit anonymisierten Fingerprint-Signalen für bessere Schätzungen; AppsFlyer SKAN Conversion Value Tool: No-Code-Konfiguration der CV-Mapping-Logik; Adjust SKAN Analytics: Auswertung der Postback-Qualität
Kampagnen-Optimierung unter SKAN: Campaign Count: begrenzte IDs (SKAN 3.x: 100 Kampagnen) → Konsolidierung statt vieler kleiner Kampagnen; Budget-Threshold: kleine Kampagnen erreichen Crowd-Anonymity-Threshold nicht → keine CV-Daten; CBO (Campaign Budget Optimization): mehr Budget in weniger Kampagnen für SKAN-Datendichte; Creatives: auf Werbemittel-Ebene weniger Granularität → Top-Creatives identifizieren und skalieren; Lookback-Window: SKAN-Daten erst nach 3–7 Tagen → kein tägliches Optimieren möglich
Modellierung und Ergänzung: SKAdNetwork-Daten + MMM (Media Mix Modeling): SKAN-Aggregatdaten in MMM-Modell einbinden; Incrementality Testing: Holdout-Gruppen messen inkrementellen Effekt; Blended CPI: SKAN-Installs + organische Installs gemeinsam betrachten; SKAN-Lücken durch First-Party-Daten schließen: App-interne Events mit User-ID (consent-basiert) + SKAN-Aggregatdaten = vollständigeres Bild

Praxistipp: Konfigurieren Sie Ihre Conversion Values sorgfältig bevor Sie iOS-Kampagnen skalieren – eine schlechte CV-Konfiguration macht alle SKAN-Daten unbrauchbar. Beginnen Sie mit einer revenue-basierten CV-Konfiguration (0–63 auf Revenue-Brackets mappen) wenn Ihre App In-App-Purchases in den ersten 24–48h generiert. Wenn das Conversion-Window für Revenue zu kurz ist: nutzen Sie Day-1-Proxy-Events (Registrierung + Tutorial-Abschluss + erste Kernfunktion genutzt) als CV-Mapping und validieren Sie welche Proxy-Events am stärksten mit D30-Revenue korrelieren. Nutzen Sie die SKAN-Konfigurationstools Ihres MMP (AppsFlyer Conversion Studio oder Adjust SKAN Analytics) – diese vereinfachen das CV-Mapping erheblich.