Churn-Prediction, mit der ein Fintech tatsächlich arbeiten kann

Ein Churn-Modell zahlt sich erst dann aus, wenn der Score verändert, was ein Retention-Team in dieser Woche tut. Die schwierigen Teile sind nicht der Algorithmus. Es sind: das Churn-Event so zu definieren, dass es dazu passt, wie Kunden tatsächlich gehen; Features zu berechnen, die respektieren, was zum Prediction-Zeitpunkt bekannt war; und den Kreis vom Score über die Intervention bis zu einem gemessenen Retention-Ergebnis zu schließen. Wird dieser letzte Schritt verpasst, hast du ein Dashboard, auf das niemand reagiert.

Nichts davon ist exotisch. Es ist nur leicht, es auf subtile Weise falsch zu machen, und die Fehler bleiben meist verborgen, bis das Modell längst in Produktion ist und Budget fehlallokiert.

Definiere Churn, bevor du es modellierst

In einem Fintech ist Churn selten eine saubere Kündigung. Ein Kunde, der seinen Gehaltseingang woanders hinlegt und eine Karte brach liegen lässt, ist gegangen, auch wenn der Account technisch noch offen ist. Wer für ein Quartal pausiert und zurückkommt, ist es nicht. Modellierst du das falsche Event, ist jede nachgelagerte Zahl selbstbewusst und falsch.

Fang damit an, die Definition als Query zu schreiben, nicht als Satz. Lege das Beobachtungsfenster, die Inaktivitätsschwelle und die Karenzzeit fest und gleiche diese Definition damit ab, wie das Finance-Team Abwanderung ohnehin schon reportet, damit sich ein Retention-Lift später an Umsatz koppeln lässt. Achte auf Folgendes:

• Stille Abwanderung. Der Verfall von Saldo und Transaktionen geht einem formalen Close meist um Wochen voraus. Labelst du nur harte Closes, sagst du den Papierkram vorher, nicht den Abgang.
• Unfreiwilliger Churn. Ein fehlgeschlagener Kartentausch oder ein abgelaufenes KYC-Dokument beendet eine Beziehung aus Gründen, die kein Retention-Angebot beheben kann. Trenn ihn ab, denn ihn mit hineinzumischen lehrt das Modell das falsche Signal und verwässert die Intervention.
• Reaktivierung. Entscheide von vornherein, ob ein zurückkehrender Kunde als gehalten zählt, und mach die Karenzzeit explizit. Eine 90-Tage-Lücke, die sich an Tag 100 auflöst, sollte an Tag 91 nicht als Churn gewertet werden.

Entity Resolution zählt hier mehr, als die meisten erwarten. Eine Person mit zwei Accounts, ein gemeinsamer Kontoinhaber und ein geschlossenes-dann-wieder-eröffnetes Profil können wie drei Churns und eine Akquise aussehen, obwohl es eine durchgehende Beziehung ist. Löse die Entitäten auf, bevor du das Label berechnest, sonst ist schon die Basisrate selbst Fiktion.

Bring die Timeline in Ordnung, sonst ist das Modell Fiktion

Churn-Features sind eine Falle für Lookahead. In dem Moment, in dem du eine Tabelle joinst, die in place überschrieben wurde, riskierst du, dem Modell etwas beizubringen, das es zum Prediction-Zeitpunkt gar nicht wissen konnte. Der Klassiker: ein Status-Feld, das „closed” liest, weil der Account inzwischen geschlossen ist, benutzt als Input, um genau diesen Close vorherzusagen. Die Offline-Metrik sieht hervorragend aus, und das Produktionsmodell sagt nichts vorher.

Baue Features zu einem Prediction-Datum auf und ziehe nur, was davor bekannt war. Konkret:

• Jedes Feature wird zu einem Cutoff berechnet, und das Label-Fenster öffnet strikt nach diesem Cutoff. Keine Überlappung.
• Nachträglich eingespielte oder korrigierte Werte tragen den Zeitstempel, zu dem sie verfügbar wurden, nicht den, auf den sie sich beziehen. Ein drei Wochen zu spät verbuchtes Chargeback geht mit dem Buchungsdatum ins Feature ein.
• Abstimmungsanpassungen und Quartalsend-True-ups sind häufige Leakage-Quellen. Sie landen nach der Periode, die sie beschreiben, sodass ein naiver As-of-Join eine zukünftige Korrektur in eine vergangene Feature-Zeile zieht.

Ein Feature Store, der Point-in-Time-Joins erzwingt, entfernt das meiste davon per Konstruktion und liefert dir zugleich Lineage, sodass du beim Drift eines Features es bis zur Quelltabelle zurückverfolgen kannst, statt zu raten. Wenn du Features in Ad-hoc-SQL berechnest, halte wenigstens ein Eval-Set vor, das über eine unabhängige Point-in-Time-Query gebaut ist. Wenn die beiden nicht übereinstimmen, hast du ein Leck gefunden.

Klassifikation, Survival oder beides

Wähle das Modell aus der Entscheidung heraus, nicht andersherum. Handelt das Retention-Team in einem festen Fenster, reicht ein Gradient-Boosted-Classifier über einen 30- oder 60-Tage-Horizont meist aus, und er lässt sich leicht kalibrieren und erklären. Treibt das Timing die Ökonomie, ist die Survival-Analyse die bessere Wahl, denn sie nutzt die Accounts, die am Ende deines Fensters noch aktiv sind, statt sie als ungelabelt wegzuwerfen.

Survival-Modelle behandeln Right-Censoring direkt. Ein Cox-Modell oder ein Discrete-Time-Hazard gibt dir eine Kurve pro Account statt einer einzelnen Wahrscheinlichkeit, wodurch du fragen kannst, wann ein Kunde wahrscheinlich geht, nicht nur ob. Dieser Unterschied verändert die Intervention. Ein Kunde mit erhöhtem Hazard in Woche zwei braucht einen anderen Touch als einer, dessen Risiko über sechs Monate langsam ansteigt.

Was auch immer du wählst: Die Kalibrierung ist der Teil, der ans Geld anknüpft. Ein Score von 0,8 muss ungefähr eine Event-Rate von 80 Prozent in diesem Band bedeuten, denn das Interventionsbudget wird nach Erwartungswert allokiert. Prüfe die Kalibrierung auf Out-of-Time-Daten, nicht auf einem zufälligen Split. Churn-Dynamiken verschieben sich mit Produktänderungen, Pricing und makroökonomischen Bedingungen, sodass ein zufälliger Split das Modell schmeichelt, indem er Saisonalität zwischen Training und Test durchsickern lässt.

Kopple jeden Score an eine Intervention und an eine Holdout-Gruppe

Ein Modell, das Risiko zuweist, ohne eine passende Aktion, ist ein Report. Ordne jedem Band etwas Konkretes zu: einen Gebührenerlass, einen Anruf vom Relationship Manager, einen Re-Engagement-Flow oder nichts, wenn der erwartete gehaltene Wert unter den Kontaktkosten liegt. Lege ein Budget für False Positives explizit fest, denn jede Intervention, die auf einen Kunden zielt, der nie gehen wollte, ist Ausgabe ohne Return, und in großem Maßstab lässt diese Verschwendung die Modellierungsgewinne winzig aussehen.

Halte dann eine Kontrollgruppe zurück. Enthalte einem zufälligen Teil der Hochrisiko-Population die Intervention vor und miss die Retention-Differenz zwischen behandelter und Kontrollgruppe. Das ist die einzige Zahl, die beweist, dass das System funktioniert. Die AUC sagt dir, dass das Ranking gut ist; die Holdout-Gruppe sagt dir, dass die Aktion das Verhalten verändert hat. Halte den Kreislauf am Laufen, denn sowohl das Modell als auch die Interventionen driften:

• Überwache Feature-Drift und die Basis-Churn-Rate. Ein Modell, das auf die Rate des Vorjahres kalibriert ist, allokiert Budget falsch, wenn sich die Rate verschiebt.
• Logge jeden Score, die getroffene Intervention und das Ergebnis, mit genügend Audit-Trail, um zu rekonstruieren, warum ein bestimmter Kunde kontaktiert wurde. Unter den meisten Model-Risk-Anforderungen musst du diese Lineage ohnehin nachweisen können.
• Schätze den Uplift nach einem festen Zeitplan neu. Eine Intervention, die zum Launch wirkte, kann verfallen, wenn sich Kunden an das Angebot gewöhnen.

Der Retention-Lift, netto der Kontaktkosten, gemessen gegen eine Kontrollgruppe, ist das Deliverable. Der Score ist nur der Mechanismus, der ihn erzeugt.