Churn in Chargebee messen
Churn aus Chargebee-Daten messen: welche Status und Ereignisse zählen, freiwilliger vs. unfreiwilliger Churn, Reason Codes, Pausen und eine Monatsberechnung.
Churn klingt nach einer einzigen Zahl, aber in Chargebee verteilt er sich über mehrere Status, Ereignisse und Einstellungen. Ein Abo kann zur Kündigung vorgemerkt und trotzdem aktiv sein. Es kann pausiert sein und nichts zahlen. Es kann wegen Nichtzahlung gekündigt worden sein statt aus freier Entscheidung. Wenn Sie nicht vorab festlegen, wie jeder Fall zählt, berechnen zwei Personen in Ihrem Team aus denselben Daten zwei verschiedene Churn-Raten.
Dieser Ratgeber zeigt, wie Sie aus Chargebee Billing eine klare Churn-Messung aufbauen: welche Zustände und Ereignisse Sie nutzen, wie Sie freiwilligen von unfreiwilligem Churn trennen und wie Sie mit Pausen und Reaktivierungen umgehen. Er hält sich an Chargebees Dokumentation: Subscription Cancellation, die API Cancel a subscription, die Ereignistypen, die APIs List events und List subscriptions, Reason Codes und Pause Subscription (alle abgerufen im November 2026).
Beginnen Sie mit Chargebees Berichten
Chargebee hat eingebautes Reporting, darunter einen Standardbericht zu Abos. Nutzen Sie ihn zuerst und lesen Sie auf dieser Seite, wie jede Zahl definiert ist, bevor Sie sie mit irgendetwas anderem vergleichen. Dieser Ratgeber konzentriert sich darauf, aus Chargebees Daten Ihre eigene Messung aufzubauen, die Sie brauchen, wenn Sie Churn in Ihrem eigenen Data Warehouse mit Produktnutzung, Anmeldequelle oder Kündigungsgründen verknüpfen wollen.
Die Zustände, die zählen
| Chargebee-Zustand | Gechurnt? | Warum |
|---|---|---|
in_trial |
Noch kein zahlender Kunde | Messen Sie die Umwandlung von Testphasen separat |
active |
Nein | Zahlt |
non_renewing |
Noch nicht | Kündigung zum Laufzeitende geplant; noch aktiv |
paused |
Nein, aber zahlt nicht | Separat verfolgen |
cancelled |
Ja | Beendet |
Die Zeile non_renewing ist die, bei der Teams Fehler machen. Laut API Cancel a subscription setzt eine Kündigung zum Laufzeitende das Abo auf non_renewing und seine verbleibenden Abrechnungszyklen auf 0. Es kann mit „Remove scheduled cancellation” noch gerettet werden. Zählen Sie es als Churn an dem Datum, an dem es cancelled wird, nicht an dem Tag, an dem der Kunde geklickt hat.
Die Ereignisse, die zählen
Chargebees Ereignistypen liefern Ihnen einen Datensatz mit Zeitstempel für jeden Übergang:
| Ereignis | Nutzen Sie es für |
|---|---|
subscription_created |
Neue Abos |
subscription_cancellation_scheduled |
Geplante Kündigungen (Frühindikator) |
subscription_cancellation_reminder |
Wird 6 Tage vor einer geplanten Kündigung gesendet |
subscription_cancelled |
Churn, zum Datum des Wirksamwerdens |
subscription_reactivated |
Kunden, die nach der Kündigung zurückgekommen sind |
subscription_paused, subscription_resumed |
Pausenzeiträume |
subscription_pause_scheduled |
Für später geplante Pausen |
Sie können diese als Webhooks empfangen oder die Historie über die API List events abrufen. Für eine erste Analyse ist das Abrufen der Ereignisse der letzten zwölf Monate oft der schnellste Weg zu einer Ausgangsbasis.
Ein Hinweis zur Schreibweise: Chargebees Ereignisreferenz nutzt subscription_cancelled mit zwei L, während manche anderen Seiten „canceled” schreiben. Verwenden Sie genau den String, den Sie in Ihren eigenen Nutzlasten sehen.
Freiwilliger vs. unfreiwilliger Churn
Diese brauchen unterschiedliche Lösungen, trennen Sie sie also vom ersten Tag an.
- Unfreiwillig: Die Referenz der Ereignistypen sagt, dass
subscription_cancelledeinencancel_reasonträgt, wenn die Kündigung durch Nichtzahlung oder eine fehlende Karte verursacht wurde. Das sind Ihre Verluste durch fehlgeschlagene Zahlungen. - Freiwillig: Kündigungen ohne diesen Systemgrund, typischerweise mit einem
cancel_reason_codeaus Ihren konfigurierten Reason Codes.
Machen Sie Reason Codes für Kündigungen aus der App und dem Portal zur Pflicht. Laut Chargebees Dokumentation muss die Cancel-API dann ebenfalls einen cancel_reason_code erhalten. So hat jede freiwillige Kündigung einen Grund, und Sie können Churn ohne Raten nach Grund berichten.
Ein praktischer Punkt aus der Dokumentation zur Kündigung: cancel_reason_code ist beim Abrufen eines Abos im Status non-renewing womöglich nicht enthalten, es sei denn, Sie aktivieren die zugehörige Einstellung auf Site-Ebene. Aktivieren Sie sie oder erfassen Sie den Grund aus dem Ereignis subscription_cancellation_scheduled.
Pausen
Chargebees Seite Pause Subscription sagt, dass Verlängerungen stoppen, solange ein Abo pausiert ist. Ein pausierter Kunde zahlt nicht und ist nicht gegangen.
Wählen Sie eine Regel und bleiben Sie dabei:
- Schließen Sie pausierte Abos aus der Ausgangsbasis und dem Churn aus und berichten Sie die Zahl der pausierten Abos neben der Churn-Rate. Das ist die häufigste Wahl.
- Endet eine Pause in einer Kündigung, zählen Sie den Churn zum Kündigungsdatum wie jeden anderen.
Was auch immer Sie wählen, lassen Sie Pausen Ihre Churn-Rate nicht stillschweigend senken. Ein Pausenangebot, das die Kündigung nur verschiebt, sollte irgendwann als Churn auftauchen.
Reaktivierungen
Ein Kunde, der kündigt und später reaktiviert (subscription_reactivated), ist im Monat seines Weggangs trotzdem Churn. Zählen Sie die Reaktivierung separat, als zurückgeholte oder reaktivierte Kunden, statt sie vom vergangenen Churn abzuziehen. Vergangene Monate umzuschreiben, macht Trends unlesbar.
Eine monatliche Churn-Berechnung
Mit den obigen Zuständen und Ereignissen ergibt sich eine Kunden-Churn-Rate für einen Monat:
- Ausgangsbasis: Abos im Zustand
activeodernon_renewingum 00:00 Uhr am ersten Tag des Monats (ohnein_trial, und ohnepaused, wenn das Ihre Regel ist). Die API List subscriptions liefert Ihnen den aktuellen Zustand; für ein vergangenes Datum rekonstruieren Sie den Zustand aus den Ereignissen. - Gechurnt: Abos aus dieser Basis mit einem Ereignis
subscription_cancelledim Lauf des Monats. - Kunden-Churn-Rate: gechurnt geteilt durch Ausgangsbasis.
- Aufteilung: dasselbe Verhältnis für unfreiwillig (System-
cancel_reason) und freiwillig (mitcancel_reason_code), die zusammen die Gesamtsumme ergeben.
Im Lauf des Monats neu erstellte Abos sind nicht in der Ausgangsbasis, ihre Kündigungen innerhalb des Monats werden also separat berichtet oder weggelassen. Halten Sie fest, was davon.
Für Umsatz-Churn ersetzen Sie die Anzahl durch den monatlich wiederkehrenden Betrag jedes Abos zu Monatsbeginn (Jahrespläne geteilt durch 12). Berichten Sie Kontraktion durch Downgrades getrennt von Kündigungen.
Frühindikatoren
Churn ist eine nachlaufende Zahl. Diese bewegen sich früher:
- Geplante Kündigungen (
subscription_cancellation_scheduled) in diesem Monat, besonders bei Jahresplänen. - Gerettete non-renewing-Abos: Abos, die
non_renewingverlassen, ohne gekündigt zu werden. - Fehlgeschlagene Verlängerungen, die noch nicht zurückgeholt wurden.
- Begonnene Pausen und der Anteil der Pausen, die in einer Kündigung enden.
Häufige Fehler
- Churn beim Klick zählen. Das Kündigungsdatum ist, wenn das Abo
cancelledwird, nicht wenn esnon_renewingwurde. - Testphasen in die Basis mischen. Testphasen, die nicht umgewandelt werden, sind ein Conversion-Problem, kein Churn.
- Eine einzige gemischte Zahl. Ohne die Aufteilung in freiwillig und unfreiwillig können Sie nicht erkennen, ob Sie Ihr Mahnwesen oder Ihr Produkt reparieren müssen.
- Stille Pausen. Pausierte Abos auszuschließen, ohne sie zu berichten, versteckt eine wachsende Gruppe von Kunden, die nicht zahlen.
Halten Sie die Definitionen stabil
Schreiben Sie Ihre Definitionen auf: was als Basis zählt, wann Churn datiert wird, wie Pausen, Testphasen, Reaktivierungen und Vertragslaufzeiten behandelt werden. Ändern Sie sie selten, und wenn doch, berechnen Sie die Historie neu. Eine Churn-Rate ist vor allem im Vergleich mit sich selbst nützlich.
Umsetzung mit NoChurn
Abos, Kündigungen und Chargebees eigene Berichte bleiben in Chargebee. NoChurn liest Ihre Chargebee-Ereignisse, trennt freiwilligen und unfreiwilligen Churn, speichert den Grund aus seinem Kündigungsflow (in dem Kündigen immer einen Klick entfernt ist) und gibt jedem Kunden einen Churn-Score von 0 bis 100. Sie können per API Ihre eigenen Produktdaten senden, um zu sehen, welche Attribute mit Churn korrelieren, und wenn Sie einen Helpdesk verbinden, werden Support-Gespräche für den Score und die Erkenntnisse gelesen. Siehe NoChurn + Chargebee.