Churn mit App Store Server Notifications V2 messen

App Store Connect liefert Ihnen Verkaufs- und Abo-Berichte, aber wenn Sie Churn-Zahlen wollen, denen Sie vertrauen und nach denen Sie handeln können (wer gegangen ist, warum, und wer kurz davor ist), brauchen Sie ein eigenes Ereignisprotokoll. Unter iOS kommt dieses Protokoll aus den App Store Server Notifications V2: Apples Server ruft Ihren jedes Mal auf, wenn ein Abo seinen Zustand ändert.

Dieser Ratgeber zeigt, wie Sie sie zuverlässig einrichten, wie jede Benachrichtigung einer Churn-Kennzahl entspricht und wie Sie die Lücken füllen. Er basiert auf Apples Dokumentation: Enabling App Store Server Notifications, Responding to App Store Server Notifications, die Referenz zu notificationType und Get Notification History (alle abgerufen im November 2026).

Den Endpunkt einrichten

Apples Anforderungen sind kurz:

1. Eine HTTPS-URL auf Ihrem Server, mit TLS 1.2 oder neuer. Wenn Sie einen Port angeben, muss er 443 oder 1024 und höher sein.
2. Wählen Sie in App Store Connect Version 2 für die URL. Apple empfiehlt V2 für alle neuen Implementierungen. Sie können eine eigene Sandbox-URL festlegen oder dieselbe verwenden.
3. Wenn Ihre Firewall eine Allowlist nutzt, fügen Sie 17.0.0.0/8 hinzu, was Sandbox und Produktion abdeckt.
4. Geben Sie HTTP 200 bis 206 zurück, wenn Sie die Benachrichtigung gespeichert haben. Jeder andere Code zählt als Fehlschlag.
5. Testen Sie mit dem Endpunkt Request a Test Notification, der eine Benachrichtigung TEST sendet, und prüfen Sie das Ergebnis mit Get Test Notification Status.

Jede Benachrichtigung kommt als signedPayload im JWS-Format. Prüfen Sie die Signatur, bevor Sie irgendetwas darin vertrauen, und dekodieren Sie dann die Nutzlast.

Zustellung, Wiederholungen und Duplikate

Es geht etwas schief: Deployments, Ausfälle, Timeouts. Apples Dokumentation beschreibt, was dann passiert.

• Wiederholungen. Bei V2 versucht Apple es fünfmal erneut, wenn Ihr Server keinen Erfolgscode zurückgibt, jeweils 1, 12, 24, 48 und 72 Stunden nach dem vorherigen Versuch. Wiederholungen gibt es nur in der Produktion; in der Sandbox sendet Apple jede Benachrichtigung einmal.
• Duplikate. Jede Nutzlast hat eine notificationUUID, die Sie laut Apple zur Erkennung von Duplikaten nutzen sollen. Speichern Sie sie mit einer Unique-Constraint und ignorieren Sie Wiederholungen.
• Verlauf. Get Notification History liefert die Benachrichtigungen, die Apple in den letzten 180 Tagen in der Produktion (30 Tage in der Sandbox) zu senden versucht hat, 20 Einträge pro Seite, optional gefiltert nach Typ, Subtyp oder Transaktion. Führen Sie es nach jedem Ausfall aus.
• Aktueller Stand. Verlaufseinträge spiegeln den Zustand zum Zeitpunkt des Versands. Für den aktuellen Zustand eines Abos verweist Apple auf Get All Subscription Statuses.

Ein gutes Muster: Speichern Sie zuerst die Rohbenachrichtigung, geben Sie 200 zurück und verarbeiten Sie sie dann aus einer Warteschlange. Erledigen Sie nie langsame Arbeit, bevor Sie Apple antworten.

Was in einer Benachrichtigung steht

Die dekodierte Nutzlast hat einen notificationType, einen optionalen subtype, ein signedDate und ein Objekt data. Bei Abos enthält data:

• signedTransactionInfo: die Transaktion (Produkt, Daten, genutztes Angebot, gegebenenfalls Widerruf).
• signedRenewalInfo: was bei der nächsten Verlängerung passiert, einschließlich autoRenewStatus, expirationIntent, isInBillingRetryPeriod, gracePeriodExpiresDate und eligibleWinBackOfferIds.
• status: der Abo-Status zum Zeitpunkt von signedDate: 1 aktiv, 2 abgelaufen, 3 in Billing Retry, 4 in Billing Grace Period, 5 widerrufen.

Um ein Abo mit einem Ihrer Nutzer zu verbinden, setzen Sie beim Kauf ein appAccountToken. Apple gibt es in der Transaktions- und Verlängerungsinfo zurück. Ohne es haben Sie nur Apples Transaktions-IDs.

Benachrichtigungen auf Churn-Kennzahlen abbilden

So übersetzen sich Apples Benachrichtigungstypen in die Zahlen, die die meisten Teams verfolgen. Die Beschreibungen folgen Apples Tabelle zu notificationType.

Kennzahl	Benachrichtigung	Subtyp
Neuer Abonnent	SUBSCRIBED	INITIAL_BUY
Zurückkehrender Abonnent (auch über Win-back-Angebote)	SUBSCRIBED	RESUBSCRIBE
Verlängerung	DID_RENEW	keiner
Kündigungsabsicht (Verlängerung abgeschaltet)	DID_CHANGE_RENEWAL_STATUS	AUTO_RENEW_DISABLED
Kündigung zurückgenommen	DID_CHANGE_RENEWAL_STATUS	AUTO_RENEW_ENABLED
Abrechnungsfehler	DID_FAIL_TO_RENEW	GRACE_PERIOD oder keiner
Abrechnung wiederhergestellt	DID_RENEW	BILLING_RECOVERY
Freiwilliger Churn	EXPIRED	VOLUNTARY
Unfreiwilliger Churn (Abrechnung)	EXPIRED	BILLING_RETRY
Churn durch Preiserhöhung	EXPIRED	PRICE_INCREASE
Produkt aus dem Verkauf genommen	EXPIRED	PRODUCT_NOT_FOR_SALE
Rückerstattung	REFUND	keiner, oder SEATS bei Mehrplatz-Abos
Downgrade geplant	DID_CHANGE_RENEWAL_PREF	DOWNGRADE

Der expirationIntent in der Verlängerungsinfo liefert dieselbe Aufteilung als Zahl: 1 Kunde hat gekündigt, 2 Abrechnungsfehler, 3 keine Zustimmung zu einer Preiserhöhung oder Angebotsumwandlung, 4 Produkt nicht verfügbar, 5 sonstiges (Referenz).

Zählen Sie Churn beim Ablauf, nicht bei der Kündigung

Im App Store stoppt eine Kündigung nur die Verlängerung. Der Kunde behält den Zugriff bis zum Ende des Zeitraums und kann die Verlängerung wieder einschalten. Also:

• Nutzen Sie AUTO_RENEW_DISABLED als Frühindikator: Abos, die in diesem Zeitraum gefährdet sind.
• Nutzen Sie EXPIRED als Churn-Ereignis: Abos, die tatsächlich geendet haben.

Wenn Sie Churn bei AUTO_RENEW_DISABLED zählen, überschätzen Sie ihn und übersehen jeden Kunden, der es sich anders überlegt hat.

Abrechnungs-Churn hat einen langen Nachlauf

Laut Apples Referenz versucht der App Store nach einer fehlgeschlagenen Verlängerung 60 Tage lang weiter abzurechnen, oder bis der Kunde seine Abrechnung repariert oder kündigt. Mit aktivierter Billing Grace Period behält der Kunde während der Grace Period den Zugriff; GRACE_PERIOD_EXPIRED markiert ihr Ende, während die Wiederholungsversuche weiterlaufen. Ein Abo in Billing Retry ist weder aktiv noch schon gechurnt. Berichten Sie es als eigene Kategorie, und zählen Sie es erst als Churn, wenn EXPIRED mit BILLING_RETRY eintrifft.

Beachten Sie auch recentSubscriptionStartDate in der Verlängerungsinfo: Apple berechnet es unter Ausblendung von Unterbrechungen von 60 Tagen oder weniger, was für Abodauer und Kohorten praktisch ist.

Ein einfacher Churn-Bericht aus Benachrichtigungen

Wenn jede Benachrichtigung gespeichert ist, besteht ein Monatsbericht aus einer Handvoll Abfragen:

1. Aktiv zu Monatsbeginn: Abos, deren letzter Status vor dem Monat aktiv, in Grace Period oder in Billing Retry war (entscheiden Sie einmal, ob Retry als aktiv zählt, und bleiben Sie dabei).
2. Gechurnt: EXPIRED-Benachrichtigungen im Monat, aufgeteilt nach Subtyp.
3. Freiwillige Churn-Rate: EXPIRED/VOLUNTARY geteilt durch aktiv zu Beginn.
4. Unfreiwillige Churn-Rate: EXPIRED/BILLING_RETRY geteilt durch aktiv zu Beginn.
5. Wiederherstellung der Abrechnung: DID_RENEW/BILLING_RECOVERY geteilt durch DID_FAIL_TO_RENEW über dieselbe Kohorte.
6. Jetzt gefährdet: Abos, deren letzte Verlängerungsinfo eine abgeschaltete automatische Verlängerung und ein künftiges Ablaufdatum zeigt.
7. Reaktivierungen: SUBSCRIBED/RESUBSCRIBE.

Die allgemeinen Formeln und Fallen (Monats- und Jahrespläne mischen, Testphasen mitzählen) finden Sie unter Churn-Rate berechnen.

Häufige Lücken

• Nur V1 abhören, oder nur die Produktion. Testen Sie V2 in der Sandbox, bevor Sie die Produktion umstellen; Apple empfiehlt genau diese Reihenfolge.
• Kein Abgleichsjob. Auch mit Wiederholungen sollten Sie Get Notification History regelmäßig und nach Vorfällen ausführen.
• Familienfreigabe und Gruppen ignorieren. SUBSCRIBED und REVOKE werden auch für Familienmitglieder und Gruppenplätze ausgelöst. Entscheiden Sie, ob diese in Ihren Kennzahlen als Abonnenten zählen.
• Rückerstattungen als Kündigungen behandeln. Ein REFUND beendet den Zugriff und gibt Geld zurück; berichten Sie es getrennt.
• Kein appAccountToken. Sie bekommen saubere App-Store-Zahlen, können sie aber nicht mit Nutzungs-, Plan- oder Akquisedaten verknüpfen, und genau daher kommen Erklärungen für Churn.

Umsetzung mit NoChurn

NoChurn gibt Ihnen eine URL, die Sie als Endpunkt für Ihre App Store Server Notifications eintragen. NoChurn prüft und dedupliziert jede Benachrichtigung, führt die Timeline pro Kunde (zugeordnet über Ihr appAccountToken), trennt freiwilligen, Abrechnungs- und Preiserhöhungs-Churn und markiert eine abgeschaltete automatische Verlängerung als frühes Risikosignal im Churn-Score von 0 bis 100. Sie können per API eigene Attribute hinzufügen, um zu sehen, was den Churn treibt. Apple behält Abrechnung, Wiederholungsversuche und den Kündigungsbutton. Siehe NoChurn + App Store.