Churn mit den Echtzeit-Entwicklerbenachrichtigungen von Google Play verfolgen

Google Play informiert Ihr Backend über Änderungen an Abos mit Echtzeit-Entwicklerbenachrichtigungen (Real-time Developer Notifications, RTDN), die in einem Google-Cloud-Pub/Sub-Topic veröffentlicht werden. Sie sind die Grundlage jeder ernsthaften Churn-Verfolgung für eine Android-App: wer gekündigt hat, wer ein Abrechnungsproblem hat, wer pausiert hat, wer tatsächlich gegangen ist.

Es gibt einen Haken, der alles Weitere prägt: Eine Benachrichtigung sagt nur, dass sich etwas geändert hat. Dieser Ratgeber behandelt das Setup, die Verarbeitung jeder Nachricht, die Zuordnung der Benachrichtigungstypen zu Churn-Kennzahlen und die Fehler, die die Zahlen verzerren. Er basiert auf der Dokumentation von Google: RTDN konfigurieren, die RTDN-Referenz, der Lebenszyklus von Abos und die API-Referenz für purchases.subscriptionsv2 (alle abgerufen im November 2026).

Benachrichtigungen einrichten

Der Einrichtungsleitfaden von Google führt Sie durch:

1. Erstellen Sie ein Pub/Sub-Topic in einem Google-Cloud-Projekt.
2. Geben Sie dem Dienstkonto google-play-developer-notifications@system.gserviceaccount.com die Rolle Pub/Sub Publisher für das Topic.
3. Erstellen Sie eine Subscription auf dem Topic: Push an einen HTTPS-Endpunkt Ihres Backends oder Pull durch einen Worker.
4. Geben Sie in der Play Console den Namen des Topics für Ihre App ein und klicken Sie auf Send Test Message.
5. Wählen Sie die Benachrichtigungstypen: nur Abos und stornierte Käufe, oder alles einschließlich Einmalprodukten.

Bestätigen Sie jede Nachricht. Bei Pull-Subscriptions sagt Google, abgerufene Nachrichten zu bestätigen, „um wiederholte Zustellung durch Cloud Pub/Sub zu vermeiden“; bei Push dient ein erfolgreicher Antwortcode als Bestätigung.

Eine Nachricht verarbeiten

Jede Pub/Sub-Nachricht hat ein base64-codiertes Feld data. Decodiert enthält es version, packageName, eventTimeMillis und genau eines von subscriptionNotification, oneTimeProductNotification, voidedPurchaseNotification, pendingRefundReviewNotification oder testNotification.

Eine Abo-Benachrichtigung enthält nur einen notificationType und ein purchaseToken. Googles Referenz ist eindeutig: Sie „müssen nach dem Empfang von Echtzeit-Entwicklerbenachrichtigungen die Google Play Developer API aufrufen, um den vollständigen Status zu erhalten“, weil Benachrichtigungen „Ihnen keine vollständigen Informationen über den Kauf geben“. Der Lebenszyklus-Leitfaden nennt purchases.subscriptionsv2.get „die maßgebliche Quelle für die Abo-Verwaltung“.

Die Pipeline lautet also:

1. Empfangen, messageId auf Duplikate prüfen (Google empfiehlt das), die Rohnachricht speichern, bestätigen.
2. purchases.subscriptionsv2.get mit dem Purchase Token aufrufen.
3. Den resultierenden Status als Snapshot mit dem Benachrichtigungstyp und eventTimeMillis speichern.
4. Ihre Berechtigungen und Kennzahlen aus dem Snapshot aktualisieren, nicht allein aus der Benachrichtigung.

Denken Sie daran, dass das Purchase Token nur bis 60 Tage nach dem Ablauf funktioniert. Rufen Sie den Status ab, wenn die Benachrichtigung eintrifft, nicht Wochen später.

Die Typen von Abo-Benachrichtigungen

Aus der RTDN-Referenz:

Code	Typ	Was passiert ist
1	SUBSCRIPTION_RECOVERED	Aus dem Account Hold erholt oder aus einer Pause fortgesetzt
2	SUBSCRIPTION_RENEWED	Ein aktives Abo hat sich verlängert
3	SUBSCRIPTION_CANCELED	Gekündigt, freiwillig oder unfreiwillig
4	SUBSCRIPTION_PURCHASED	Neues Abo gekauft
5	SUBSCRIPTION_ON_HOLD	In den Account Hold eingetreten
6	SUBSCRIPTION_IN_GRACE_PERIOD	In die Grace Period eingetreten
7	SUBSCRIPTION_RESTARTED	Der Nutzer hat ein gekündigtes, noch nicht abgelaufenes Abo wiederhergestellt
9	SUBSCRIPTION_DEFERRED	Verlängerungsdatum verschoben
10	SUBSCRIPTION_PAUSED	Pause ist wirksam geworden
11	SUBSCRIPTION_PAUSE_SCHEDULE_CHANGED	Pause eingeplant oder geändert
12	SUBSCRIPTION_REVOKED	Vor Ablauf widerrufen
13	SUBSCRIPTION_EXPIRED	Abgelaufen
18	SUBSCRIPTION_CANCELLATION_SCHEDULED	Kündigung eines Ratenplans zum Ende der Mindestlaufzeit eingeplant
20	SUBSCRIPTION_PENDING_PURCHASE_CANCELED	Eine ausstehende Transaktion wurde storniert

Es gibt noch einige weitere (geänderte Artikel, Aktualisierungen von Preisänderungen, Zustimmung zu Preisstufen). Code 8 ist veraltet.

Die für Churn wichtigen Status

Das Feld subscriptionState aus der API ist zum Zählen zuverlässiger als der Benachrichtigungstyp. Der Lebenszyklus-Leitfaden beschreibt, was jeder Status für den Zugang bedeutet:

Status	Hat der Nutzer Zugang?	Bedeutung für Churn
SUBSCRIPTION_STATE_ACTIVE	Ja	Abonnent
SUBSCRIPTION_STATE_IN_GRACE_PERIOD	Ja	Gefährdet: Zahlung fehlgeschlagen
SUBSCRIPTION_STATE_ON_HOLD	Nein	Gefährdet: Zahlung fehlgeschlagen, Zugang gesperrt
SUBSCRIPTION_STATE_PAUSED	Nein	Pausiert, nicht gekündigt
SUBSCRIPTION_STATE_CANCELED	Bis expiryTime	Gefährdet: Verlängerung gestoppt
SUBSCRIPTION_STATE_EXPIRED	Nein	Gekündigt (Churn)

Grace Period und Account Hold haben Standardwerte, die Sie kennen sollten. Die Grace Period ist bei allen sich automatisch verlängernden Basisplänen standardmäßig aktiviert. Der Account Hold ist ebenfalls standardmäßig aktiv, mit einer Dauer, die Google als 60 Tage minus die Grace Period berechnet. Beides lässt sich in der Play Console ändern. Bevor der Account Hold beginnt, unternimmt Google bis zu 48 Stunden lang zusätzliche Belastungsversuche.

Von Events zu Churn-Kennzahlen

Churn beim Ablauf zählen

SUBSCRIPTION_CANCELED bedeutet, dass die Verlängerung gestoppt wurde, nicht dass der Nutzer gegangen ist. Er behält den Zugang bis expiryTime und kann ihn wiederherstellen (SUBSCRIPTION_RESTARTED). Zählen Sie Churn bei SUBSCRIPTION_EXPIRED und nutzen Sie Kündigungen als Frühindikator.

Freiwilligen und unfreiwilligen Churn trennen

Der canceledStateContext der Abo-Ressource sagt, wer gekündigt hat:

• userInitiatedCancellation: freiwillig. Er kann auch die Antwort aus der Kündigungsumfrage des Nutzers enthalten.
• systemInitiatedCancellation: vom System gekündigt, „zum Beispiel wegen eines Abrechnungsproblems“. Das ist Ihr unfreiwilliger Churn.
• developerInitiatedCancellation: Sie haben gekündigt.
• replacementCancellation: durch ein neues Abo ersetzt, zum Beispiel nach einem Planwechsel. Kein Churn.

Der Abrechnungspfad hat eine erkennbare Abfolge: SUBSCRIPTION_IN_GRACE_PERIOD, dann SUBSCRIPTION_ON_HOLD, dann entweder SUBSCRIPTION_RECOVERED oder, am Ende des Account Hold, SUBSCRIPTION_CANCELED, unmittelbar gefolgt von SUBSCRIPTION_EXPIRED.

Pausen nicht als Churn zählen

SUBSCRIPTION_RECOVERED wird sowohl ausgelöst, wenn ein Abo den Account Hold verlässt, als auch, wenn es aus einer Pause fortgesetzt wird. Prüfen Sie den vorherigen Status, bevor Sie es als Abrechnungserholung zählen.

Planwechsel und erneute Anmeldungen behandeln

Upgrades, Downgrades und erneute Anmeldungen in der App vor dem Ablauf erzeugen einen neuen Kauf mit einem neuen Token. Das neue Abo hat einen linkedPurchaseToken, der auf das alte zeigt. Wenn Sie diesen Verknüpfungen nicht folgen, sieht jeder Planwechsel wie ein gekündigter und ein neuer Abonnent aus.

Erneutes Abonnieren im Play Store nach dem Ablauf ist anders: Google sagt, dass es keinen linkedPurchaseToken trägt, aber die API-Antwort enthält outOfAppPurchaseContext mit dem abgelaufenen Token, bis Sie den Kauf bestätigen. Zählen Sie diese als Reaktivierungen.

Widerrufe

SUBSCRIPTION_REVOKED bedeutet, dass der Zugang vorzeitig endete: Sie haben ihn widerrufen, oder der Kauf wurde per Chargeback zurückgebucht. Der Status wird abgelaufen. Weisen Sie ihn getrennt vom normalen Churn aus, zusammen mit stornierten Käufen.

Ein Monatsbericht

1. Aktiv zu Beginn: Abos im Status aktiv, Grace Period oder gekündigt, aber nicht abgelaufen.
2. Freiwilliger Churn: Abläufe, deren Kontext vom Nutzer ausgelöst ist.
3. Unfreiwilliger Churn: Abläufe, deren Kontext vom System ausgelöst ist.
4. Erholungsquote bei der Abrechnung: Abos, die in die Grace Period oder den Account Hold eingetreten sind und sich erholt haben, im Verhältnis zu allen, die eingetreten sind.
5. Wiederherstellungen: SUBSCRIPTION_RESTARTED.
6. Pausiert: Anzahl, und wie viele fortgesetzt werden.
7. Reaktivierungen: erneutes Abonnieren im Play Store und erneute Anmeldungen in der App nach dem Ablauf.

Die allgemeinen Formeln finden Sie in wie man die Churn-Rate berechnet.

Häufige Fehler

• Allein dem Benachrichtigungstyp vertrauen. Rufen Sie immer den Status des Abos ab.
• Kündigungen als Churn zählen. Das bläht den Churn auf und verbirgt Wiederherstellungen.
• Verknüpfte Purchase Tokens ignorieren. Planwechsel werden zu falschem Churn.
• Die API zu spät aufrufen. Tokens funktionieren 60 Tage nach Ablauf nicht mehr.
• Pub/Sub-Nachrichten nicht bestätigen. Sie bekommen Duplikate und verschwenden API-Kontingent.
• Keine verschleierte Konto-ID beim Kauf. Sie können Play-Daten nicht mit Ihren eigenen Nutzerdaten zusammenführen.

Das mit NoChurn umsetzen

Sie leiten Ihre Echtzeit-Entwicklerbenachrichtigungen von Play an NoChurn und geben ihm ein Dienstkonto mit Zugriff auf Ihre Play Console. NoChurn ruft für jedes Event den Status des Abos ab, folgt verknüpften Purchase Tokens, trennt freiwilligen Churn, Churn durch die Abrechnung und widerrufenen Churn und führt pro Kunde eine Zeitleiste, zugeordnet über die verschleierte Konto-ID, die Sie beim Kauf setzen. Grace Period, Account Hold und Kündigungen fließen in den Churn-Score von 0 bis 100 ein, und Sie können eigene Attribute per API hinzufügen. Google behält Zahlungen, Wiederholungen und den Kündigungsbutton. Siehe NoChurn + Google Play.