Kann SKAN die Abo-Zahlung nach dem kostenlosen Trial messen?

Manchmal, und nur als grober Wert (Coarse Value: low, medium oder high), nie als feiner (Fine Value). Die Abbuchung nach einem kostenlosen Trial geschieht auf Apples Seite und erreicht RevenueCat per Server-to-Server, während SKAN nur festhält, was die App auf dem Gerät schreibt. Die Zahlung zählt also nur, wenn Ihr einziger Schreiber für den Conversion Value in der App läuft, bevor das Fenster schließt, in das sie fällt. Die Trial-Länge ändert die Antwort. Ohne Trial kann die Erstzahlung im ersten Fenster als feiner Wert landen. Der kürzeste kostenlose Trial, den Apple anbietet (3 Tage), schiebt sie schon ins zweite Fenster, ein Trial von 1 Woche meist ins dritte, beide nur grob. Ein Trial, der nach Tag 35 endet, verpasst jedes Fenster.

Umfang: iOS Subscription-Apps mit RevenueCat, einem MMP (AppsFlyer und Singular sind die beiden, deren Weiterleitungsregeln ich geprüft habe) oder Firebase, auf SKAdNetwork 4 und AdAttributionKit, mit Mediaeinkauf bei Meta und Google, alle Regionen. Jede Plattformangabe habe ich am 1. Oktober 2026 auf der Seite des Anbieters selbst geprüft.

Was passiert zwischen “RevenueCat hat die Zahlung erfasst” und “das Gerät hat den Wert aktualisiert”?

Sechs Schritte, und die Lücke liegt zwischen dem dritten und dem fünften.

1. Erster Start. Hier beginnt Apples Uhr. Die SKAdNetwork-Seite Receiving postbacks in multiple conversion windows legt drei Fenster ab dem ersten Start fest: Tag 0 bis 2, 3 bis 7 und 8 bis 35. Nur der erste Postback kann einen feinen Wert tragen, den Apples Update-Methode als Zahl von 0 bis 63 definiert.
2. Trial-Start. Meist auf der Paywall in der ersten Session, innerhalb von Fenster 1, wo das SDK auf dem Gerät ihn sieht.
3. Bestätigte Zahlung. Wenn der Trial endet, bucht der App Store ab. RevenueCats Event Types and Fields meldet eine erfolgreiche erste Abbuchung als RENEWAL, bei dem is_trial_conversion auf true steht. Ein Trial, den niemand gekündigt hat, ist keine Zahlung, und ein aktives Entitlement auch nicht. Apples Reducing involuntary subscriber churn sagt, dass eine fehlgeschlagene Verlängerung bis zu 60 Tage in den Billing Retry geht, und mit eingeschalteter Billing Grace Period behält der Nutzer vollen Zugriff, während Apple versucht, den Betrag einzuziehen.
4. Weiterleitung über den Server. RevenueCat sendet das Event per Server-to-Server an den MMP. AppsFlyers SKAN Conversion Studio sagt, dass AppsFlyer den Wert neu berechnet. Ist die App geöffnet, aktualisiert das SDK das Gerät, andernfalls wartet der Server auf das nächste Öffnen der App. Das muss vor Ablauf des Fensters geschehen, sonst bleibt das Event unberücksichtigt. Singulars S2S Support for Conversion Models FAQ beschreibt dasselbe Warten für eine Funktion, die Singular auf Anfrage einschaltet. Sie läuft nur im Managed-SKAN-Modus. Schließt das Fenster oder öffnet der Nutzer die App nie wieder, kann Singular den Wert nicht aktualisieren.
5. Ausführung auf dem Gerät. Das SDK ruft Apples Update-Methode auf. Der Wert landet in dem Fenster, das in diesem Moment offen ist, nicht in dem Fenster, in dem die Abbuchung geschah. Apples Seite updatePostbackConversionValue sagt, dass der feine Wert nach dem ersten Fenster ignoriert wird.
6. Postback. Nachdem das Fenster geschlossen ist, sendet Apple den Postback nach einer zufälligen Verzögerung: 24 bis 48 Stunden beim ersten, 24 bis 144 Stunden beim zweiten und dritten. Apple sagt außerdem, dass die App den Wert in jedem Fenster aktualisieren muss, um für mehr als einen Postback infrage zu kommen. Ein Nutzer, der die App zwischen Tag 3 und Tag 7 nie öffnet, hinterlässt in Fenster 2 also nichts, was zu melden wäre. Eine Anzeige in Apples niedrigster Stufe (Stufe 0) bekommt gar keinen zweiten oder dritten Postback.

Wer schreibt den Conversion Value?

Ein Schreiber, auf dem Gerät. Jede Update-Methode, die Apple dokumentiert, ist ein Aufruf, den die App macht. Eine Server-API habe ich nicht gefunden.

RevenueCat ist nicht dieser Schreiber. Seine Seite Meta Ads sagt, es aktualisiere keine SKAN Conversion Values (“doesn’t update SKAN conversion values”), und empfiehlt einen einzigen Updater, sei es die App, das Meta SDK oder ein MMP, damit die Werte nicht kollidieren. Seine Seite Singular sagt, dass es sie aus seinen Server-Events nicht ändern kann. Seine Seite AppsFlyer sagt außerdem, Sie sollten das clientseitige Umsatz-Tracking entfernen, um Doppelzählung zu vermeiden. Dann erreicht bei diesem Setup selbst ein Kauf an Tag 0 das AppsFlyer SDK nur über die Server-Weiterleitung.

Ein zweiter Schreiber ist der Fehler, vor dem die Anbieter warnen. Googles Set up your SKAdNetwork conversion value schema sagt, es werde dringend empfohlen, das Schema an einer Stelle einzurichten. Die Google-Analytics-Version von Set up your SKAdNetwork conversion value schema hat eine Option, mit der das Firebase SDK den Wert für jedes Fenster setzen darf, und Firebases Get started with Google Analytics for iOS+ sagt, dass das SDK die App automatisch bei SKAdNetwork registriert, sofern Sie GOOGLE_ANALYTICS_REGISTRATION_WITH_AD_NETWORK_ENABLED nicht auf NO setzen. AppsFlyers SKAN 4.0 anomalies explained sagt, dass jedes Update das vorherige überschreibt, einschließlich Updates im Stil von SKAN 3 und Install-Registrierungen aus einem anderen SDK. Dieser Beitrag erschien zuerst im August 2023 und ist die Darstellung eines Anbieters, nicht die von Apple. Apples Seite zur Methode sagt nicht, was passiert, wenn zwei SDKs sie aufrufen.

AdAttributionKit fügt keinen Schreiber hinzu. Apples Understanding AdAttributionKit and SKAdNetwork interoperability sagt, dass Aufrufe von SKAdNetwork zum Conversion Value in AdAttributionKit gespiegelt werden und über beide Frameworks hinweg nur eine Impression gewinnt.

In welchem Fenster kann die Erstzahlung landen?

Die Tabelle nimmt an, dass der Trial in der ersten Session startet. Ein Trial, der an Tag 2 startet, verschiebt jedes Datum um zwei Tage nach hinten. Die Trial-Längen entsprechen den Laufzeiten für kostenlose Trials, die Apple in Set up introductory offers for auto-renewable subscriptions aufführt. Die kürzeste beträgt 3 Tage. Die Zellen zu Fenster 2 und Fenster 3 gelten nur für Anzeigen in Stufe 1 oder höher, weil eine Anzeige in Stufe 0 nach dem ersten keinen Postback mehr bekommt.

Addieren Sie die Postback-Verzögerung, dann lesen Sie die Tabelle als Kalender. Eine Zahlung in Fenster 3 erreicht Ihren MMP zwischen Tag 36 und Tag 41 nach dem ersten Start, sofern das Fenster nicht vorzeitig gesperrt wurde.

Was deckt RevenueCats eigener Leitfaden ab, und was lässt er aus?

RevenueCats How to use RevenueCat server-to-server events for SKAdNetwork attribution, veröffentlicht am 18. Februar 2025, ist der ausführlichste Anbieter-Leitfaden zu diesem Problem, den ich kenne. Er ordnet Trials, die kürzer als sieben Tage sind, Fenster zwei zu und Trials von sieben Tagen Fenster drei. Das passt zur Tabelle. Er bietet zwei Lösungen an: den Trial-Status jedes Mal zu prüfen, wenn die App in den Vordergrund kommt, und einen Silent Push, wenn der Trial endet. Er sagt auch, dass sein Ansatz keine vollständige Genauigkeit garantiert. Was ich ergänze:

• Apples Grenzen für Silent Push. Apples Pushing background updates to your App sagt, dass Hintergrundbenachrichtigungen niedrige Priorität haben, die Zustellung nicht garantiert ist, das System sie drosseln kann (Apple sagt, man solle nicht mehr als zwei oder drei pro Stunde senden) und eine zurückgehaltene Benachrichtigung verworfen wird, wenn die App per Force Quit beendet wird. Eine Kernaussage des Leitfadens geht weiter, als Apples Dokumentation stützt: dass Apples Server-Benachrichtigungen über RevenueCat Conversions erfassen, ohne dass der Nutzer die App öffnet.
• Der Schreiber. Der Code des Leitfadens schreibt aus der App in SKAdNetwork. Wenn Ihr MMP SDK ebenfalls schreibt, haben Sie jetzt zwei Schreiber. Leiten Sie das Event stattdessen über Ihren einzigen Schreiber.
• Zahlung oder Entitlement. Die Prüfung des Leitfadens sucht ein aktives Entitlement, das nicht mehr in der Trial-Phase ist. Ordnen Sie den Wert stattdessen der eingezogenen Abbuchung zu, weil die Billing Grace Period ein Entitlement aktiv halten kann, während Apple noch versucht, den Betrag einzuziehen.
• Änderungen am Framework seither. Apples Seite AdAttributionKit Updates führt Änderungen vom Juni 2024 und Juni 2025 auf, nach Stand dieser Prüfung nichts für 2026.

Was machen Google und Meta mit einer groben Trial-Zahlung?

Google sagt, dass es sie nicht nutzt. Die Schema-Seite von Google Ads sagt, dass Googles Conversion-Modellierung nur feine Werte nutzt und die groben Conversion Values von SKAN 4 nicht unterstützt (“we currently do not support SKAN version 4’s coarse conversion values”). Dieselbe Seite verlangt mehr als 10 Conversion-Events pro Tag je Event im Schema und rund 50 Installs pro Tag. Das sind Googles Richtlinien für das Schema, nicht Apples Privacy-Schwelle, und Apple veröffentlicht keine Install-Zahl für seine Stufen. Bei App-Kampagnen auf iOS ist das SKAN-Signal, aus dem Google lernt, also das, was in den ersten zwei Tagen passiert. Googles modellierte Conversions und sein Integrated Conversion Measurement sind von SKAN getrennt, und ich vergleiche die drei in warum Google Ads, Ihr MMP und SKAN unterschiedliche iOS-Conversions melden nebeneinander.

Meta hat ein eigenes Setup. Configure Apple’s SKAdNetwork in Meta Events Manager lässt Sie Events mit feinen und groben Werten für SKAdNetwork 4 konfigurieren: nach Metas Empfehlungen, durch Import des Schemas Ihres MMP oder von Hand. Die Seite sagt, dass Meta den Support für SKAdNetwork 4 schrittweise einführt und er für Sie womöglich noch nicht verfügbar ist. Prepare your app integration for Apple’s SKAdNetwork verlangt von Apps, die das Facebook SDK for iOS nutzen, Version 16.2.1 oder höher und rät davon ab, Conversion Values zu senken oder Lock Windows zu nutzen. AppsFlyer bietet beides an: eine Einstellung, mit der negativer Umsatz, etwa eine Erstattung, den Wert senken kann, und einen Lock, der den Postback früher sendet. Geht der größte Teil Ihres iOS-Budgets an Meta, entscheiden Sie diese beiden Einstellungen anhand von Metas Empfehlungen. Die Konfigurationsseite sagt, dass Events mit groben Werten der Anzeigenleistung helfen können. Sie sagt nicht, wie die Auslieferung einen groben Wert aus Fenster 3 gewichtet, und ich habe keine Meta-Seite gefunden, die AdAttributionKit-Postbacks bestätigt, also behaupte ich keines von beidem.

Was heißt das für das Optimierungs-Event bei Meta?

Über SKAN kommt die Trial-Zahlung spät an, grob, und nur für Nutzer, die die App nach der Zahlung öffnen. Ein Event aus der ersten Session kommt in Fenster 1 an und kann fein sein. Events, die SKAN schnell an Meta melden kann, sind also frühe: ein Trial-Start, ein Trial-Start mit einer Bedingung, die eine Zahlung vorhersagt, oder ein bezahlter Plan, der an Tag 0 gekauft wird. Die Zahlung kann trotzdem im Schema für die Fenster 2 und 3 stehen, als grober Wert. Ich würde sie dort als späten Bericht über die Kohorte lesen und mich nicht darauf verlassen, dass sie die Auslieferung steuert, weil Meta nicht sagt, wie die Auslieferung sie gewichtet. Metas Aggregated Event Measurement ist ein eigener Weg mit eigenen Regeln. Markiert der Events Manager dort den Trial oder den Kauf als nicht berechtigt, stehen die Prüfungen in warum Trial- und Kauf-Events für Meta AEM nicht berechtigt sind. Die Wahl des Events selbst steht in auf welches Event eine Subscription-App optimieren sollte.

Was ändert sich bei einem Mobile Game?

Der größte Teil des Weiterleitungsproblems entfällt, weil die Zahlung in der Session geschieht. Wenn das MMP SDK einen In-App-Kauf auf dem Gerät selbst loggt, kann es den Wert in dieser Session schreiben, und Fenster 1 kann ihn als feinen Wert tragen. AppsFlyers Conversion Studio kann den Gesamtumsatz, einschließlich Ad Revenue, über ein einziges Event messen, af_skad_revenue, und merkt an, dass Werte für Ad Revenue nie negativ werden. Ein Hybrid Game kann seine 64 feinen Werte in Fenster 1 zwischen Käufen, Ad Revenue und Progression aufteilen und die groben Werte in den Fenstern 2 und 3 für Retention oder einen ersten Kauf nutzen.

Der schwierigere Teil ist das Volumen. Apple legt die Stufe nach der Crowd-Größe fest, ein Soft Launch ist absichtlich klein, und eine Anzeige in Stufe 0 bekommt einen Postback ohne Wert. Weniger, größere Kampagnen erreichen die höheren Stufen früher. Das behandle ich in weniger Kampagnen, mehr Signal. Was ein Soft Launch beweisen muss, und das SKAN-Schema dafür, steht auf User Acquisition für Mobile Games.

Wie testen Sie das, bevor der Spend steigt?

Ich würde vier Prüfungen machen, bevor ein Trial-Schema Budget trägt. Jede folgt aus den Anbieterseiten oben:

1. Der Schreiber. Ein SDK ruft Apples Update-Methode auf, und Google und Meta bekommen dasselbe Schema, dem es folgt. Firebases Option, Werte zu setzen, und die SKAN-Updates jedes anderen SDK sind ausgeschaltet.
2. Das Event. Die Zahlung wird der eingezogenen Abbuchung zugeordnet, RevenueCats RENEWAL mit is_trial_conversion, nicht dem Trial-Start plus ausbleibender Kündigung.
3. Beide Weiterleitungswege. AppsFlyer dokumentiert zwei Wege für ein Server-Event: Das SDK aktualisiert den Wert sofort, wenn die App gerade benutzt wird, oder der Server hält ihn für den nächsten App-Start zurück. Verfolgen Sie eine weitergeleitete Trial-Conversion auf einem Testgerät über jeden Weg und notieren Sie, wann der Update-Aufruf lief.
4. Der Blick auf die Kohorte. Vergleichen Sie bei einer gereiften Kohorte (mindestens Tag 41 nach dem ersten Start) die Trial-Conversions, die RevenueCat für Nutzer erfasst, die Ihr MMP diesem Netzwerk zuschreibt, mit den Zahlungswerten, die Ihr MMP für die Fenster 2 und 3 dekodiert hat. Die Lücke setzt sich aus zu spät geschriebenen Zahlungen, Anzeigen in Stufe 0 ohne späteren Postback und Attributionsunterschieden zwischen den beiden Quellen zusammen. Weisen Sie sie deshalb als Lücke aus und rechnen Sie nichts hoch, um die Differenz zu füllen.

Was mache ich damit in einem Account?

Das ist der iOS-Teil von signal engineering: ein Schreiber, ein Schema, das auf Ihren Trial und Ihr Volumen zugeschnitten ist, und eine schriftliche Erwartung, was SKAN zeigen wird und was nicht, bevor jemand eine Kampagne daran beurteilt. Was Ihr Schema heute trägt, lese ich im growth audit nach.

Quellen

Alle am 1. Oktober 2026 geprüft.

• Apple Developer: Receiving postbacks in multiple conversion windows für SKAdNetwork, und die gleichnamige AdAttributionKit-Seite, jeweils kein Seitendatum.
• Apple Developer: Set up introductory offers for auto-renewable subscriptions, kein Seitendatum.
• Apple Developer: Understanding AdAttributionKit and SKAdNetwork interoperability, kein Seitendatum.
• Apple Developer: updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:), kein Seitendatum.
• Apple Developer: AdAttributionKit Updates, Einträge für Juni 2024 und Juni 2025.
• Apple Developer: Pushing background updates to your App, kein Seitendatum.
• Apple Developer: Reducing involuntary subscriber churn, kein Seitendatum.
• Google Ads Help: Set up your SKAdNetwork conversion value schema, kein Seitendatum.
• Google Analytics Help: Set up your SKAdNetwork conversion value schema, kein Seitendatum.
• Firebase: Get started with Google Analytics for iOS+, zuletzt aktualisiert am 1. Oktober 2026.
• Meta Business Help Center: Configure Apple’s SKAdNetwork in Meta Events Manager, kein Seitendatum.
• Meta Business Help Center: Prepare your app integration for Apple’s SKAdNetwork, kein Seitendatum.
• AppsFlyer: SKAN Conversion Studio, aktualisiert am 26. April 2026.
• AppsFlyer-Blog: SKAN 4.0 anomalies explained, veröffentlicht am 8. August 2023, geändert am 13. November 2025.
• Singular: S2S Support for Conversion Models FAQ, aktualisiert am 17. Dezember 2024.
• RevenueCat-Dokumentation: Meta Ads, AppsFlyer, Singular und Event Types and Fields, jeweils kein Seitendatum.
• RevenueCat-Blog: How to use RevenueCat server-to-server events for SKAdNetwork attribution, veröffentlicht am 18. Februar 2025, aktualisiert am 19. Februar 2025.