Es ist Montagmorgen. Ihr Vertriebsleiter legt den Quartalsbericht auf den Tisch. Neukunden im Plus, Umsatz stabil — und trotzdem eine Zeile, die alles überschattet: 2.400 Kündigungen im letzten Quartal. Niemand hatte sie kommen sehen.
Dabei hatten diese Kunden über Wochen Signale gesendet. Unauffällig, aber messbar. Niemand hat sie gelesen.
Die Faustregel ist bekannt: Einen Bestandskunden zu halten kostet fünf- bis siebenmal weniger, als einen neuen zu gewinnen. Bei einem mittelständischen Unternehmen mit 50.000 Vertragskunden bedeutet eine Senkung der Kündigungsrate um nur zwei Prozentpunkte schnell einen sechs- bis siebenstelligen Effekt im Jahr.
Genau hier setzt Customer Churn Detection an: Modelle, die wochenlang vor der Kündigung erkennen, welche Kunden wackeln. Nicht alle. Nicht perfekt. Aber gut genug, um gezielt einzugreifen — bevor das Schreiben in der Post landet.
In diesem Projekt habe ich genau das gebaut — auf Basis von 594.000 Kundeneinträgen aus dem IBM Telco Customer Churn Datensatz. Das Ergebnis: ein Modell mit 91 % Trefferqualität (AUC-ROC), das auf dem öffentlichen Kaggle-Leaderboard mit der internationalen Spitze mithalten kann.
Phase 1 — Den Datensatz verstehen
Bevor ein Modell trainiert wird, kommt der wichtigste Schritt: die Daten wirklich verstehen.
Der Datensatz umfasste 21 Features — Vertragsarten, Kundendauer, Gebühren, Zahlungsmethoden und Zusatzdienste. Die erste auffällige Zahl: Rund 26 % der Kunden hatten gekündigt. Diese Basis wurde zur Referenz für jedes einzelne Merkmal: Unterscheidet sich dieses Feature bei Kündigern sichtbar von Bestandskunden — oder nicht?
In der Praxis ist dieser Schritt selten so sauber: Echte Kundendaten kommen mit Lücken, Inkonsistenzen und DSGVO-Einschränkungen. Fehlende Werte müssen begründet befüllt oder aussortiert, Spaltenbezeichnungen vereinheitlicht, Datenschutzvorgaben von Anfang an mitgedacht werden. Genau diese Arbeit entscheidet später über die Qualität jeder Vorhersage — nicht der Algorithmus. In diesem Projekt bot der Datensatz eine ungewöhnlich saubere Ausgangslage — was den Blick umso klarer auf das Wesentliche lenkte: Welche Features sagen tatsächlich etwas aus?
Am Ende blieben 14 relevante Features übrig. Geschlecht, Telefonservice und Streaming-Dienste flogen raus — hier zeigten sich kaum Unterschiede. Auch die Gesamtkosten wurden aussortiert, da sie stark mit der Kundendauer korrelierten.
Was blieb, lieferte klare geschäftliche Muster:
Der stärkste Einflussfaktor war die Vertragsart — Monatskunden kündigten drastisch häufiger als Kunden mit langfristigen Verträgen. Je stärker Kunden im Service-Ökosystem eingebunden waren, desto geringer ihre Kündigungsrate.
Besonders aufschlussreich war die Zahlungsmethode Electronic Check. Sie verursacht keinen Churn — aber sie kündigt ihn an. Kunden, die kündigen wollen, wählen bewusst die flexibelste Zahlungsoption. Genau solche Muster sind wertvoll, weil sie frühzeitige Gegenmaßnahmen ermöglichen.
Phase 2 — Schnell verstehen, was funktioniert
Die Daten waren bereinigt, die Features ausgewählt — jetzt kam die eigentliche Frage: Welches Modell funktioniert für dieses Problem?
Statt direkt in Code einzusteigen, nutzte ich zunächst einen visuellen Workflow-Ansatz mit H2O AutoML, um früh das technische Potenzial der Daten einzuschätzen. Das beste Ergebnis lieferte ein Stacked Ensemble mit einer AUC von 0,912 — ein wichtiger Orientierungswert. Solche Zahlen zeigen frühzeitig, wo die Obergrenze liegt. Wird AutoML danach nicht deutlich besser, liegt das Problem meist nicht mehr am Modell, sondern an den verfügbaren Daten.
Parallel dazu testete ich einen Random Forest mit einem Sampling-Verfahren, das das Klassenungleichgewicht ausgleicht — schließlich kündigten nur 26 % der Kunden. Ergebnis: 85 % Genauigkeit, 69 % Recall. Gerade der Recall ist bei Churn Prediction entscheidend: Es geht nicht darum, treue Kunden korrekt zu identifizieren — sondern gefährdete rechtzeitig zu erkennen. Konkret: Von zehn Kunden, die tatsächlich kündigen würden, erkannte das Modell sieben.
Phase 3 — Das produktionsreife Modell in Python
Der Aufbau folgte einem klaren Schema: von einfach nach komplex. Als Basislinie diente ein Decision Tree, dann ein Random Forest, schließlich XGBoost — der Algorithmus, der bei tabellarischen Daten regelmäßig das letzte Quäntchen Leistung herausholt. Eine wichtige Stellschraube: der Parameter scale_pos_weight = 3.4, der das Ungleichgewicht zwischen Kündigern und Bestandskunden ausgleicht. Ohne diese Korrektur lernt das Modell die Mehrheit — und ignoriert genau die Gruppe, auf die es ankommt.
Entscheidend war auch das Feature Engineering: Neue Merkmale entstanden durch Kombination vorhandener Daten — die durchschnittliche Gebühr pro Kundenmonat, ein Interaktionsterm aus Bindungsdauer und Retention-Indikator sowie die Summe aller gebuchten Zusatzdienste. Alle drei tauchten am Ende unter den wichtigsten Treibern auf. Manchmal bringt das richtige Engineering mehr als jedes weitere Tuning-Experiment.
Das Ergebnis: AUC-ROC 0,913 — Kaggle Public Score 0,910, nur 0,0075 Punkte von der weltweiten Spitze entfernt.
Die entscheidende Frage: Ab wann gilt jemand als Kündigungs-Kandidat?
Standardmäßig zieht ein Modell die Grenze bei 50 % Wahrscheinlichkeit. Das klingt vernünftig — ist aber geschäftlich oft falsch. Die Kosten sind nicht symmetrisch: Ein verpasster Kündiger kostet den vollen Kundenwert. Ein Fehlalarm kostet eine Marketing-Aktion.
Deshalb wurde der Schwellwert auf 0,35 gesenkt. Das Modell meldet damit mehr potenzielle Kündiger — auch wenn nicht alle es wirklich werden. Für das Geschäft ist das die richtige Wahl: Lieber zwanzig Kunden vorsorglich ansprechen als fünf still ziehen lassen.
Was das Modell erklärt — nicht nur entscheidet
Was nützt ein Modell, das niemand versteht? Hier kommt SHAP ins Spiel. Die Methode zeigt für jeden Kunden, welche Merkmale die Vorhersage in welche Richtung beeinflusst haben. Die globalen Top-Treiber bestätigten die Feature-Analyse: Monatsvertrag, Fiber-Optic-Anschluss, Kundendauer, Electronic Check.
Das Ergebnis ist kein Bauchgefühl mehr — sondern eine begründete Aussage. Wenn das Modell sagt, Kunde 4711 wird mit 78 % Wahrscheinlichkeit kündigen, liefert es direkt mit: warum. Das ist der Unterschied zwischen einer Blackbox und einem echten Entscheidungswerkzeug.
Fazit: Was das für ein Unternehmen bedeutet
- Sie wissen Wochen vor der Kündigung, welche Kunden wackeln — Zeit für Retention-Anrufe, Sonderkonditionen, Vertragsanpassungen.
- Sie wissen, an welchen Stellschrauben Sie ansetzen müssen — Vertragsverlängerungen, Cross-Selling, Zahlungsmethoden-Monitoring.
- Sie wissen, wo Sie keine Energie verschwenden müssen — Geschlecht, Telefonleitungen, Streaming-Angebote: irrelevant.
Und ein Modell, das einmal trainiert ist, kann monatlich neu kalibriert werden. Jede Vorhersage liefert neue Daten, jede Retention-Aktion einen Lerneffekt.
Das Muster gilt weit über Telekommunikation hinaus: Ob SaaS-Anbieter mit monatlichen Abos, E-Commerce mit sinkenden Wiederkaufsraten oder Versicherungen mit auslaufenden Verträgen — überall wo Kundendaten vorliegen, lassen sich dieselben Mechanismen anwenden.
Was es braucht, ist nicht der größte Datensatz — sondern der richtige Blick auf die Daten, die bereits vorhanden sind.
Zwei bis drei Prozentpunkte weniger Kündigung im Jahr. Der Effekt ist sechsstellig.
Code & Ressourcen
Wenn Sie selbst reinschauen möchten – der komplette Code ist auf GitLab:
🔗 https://git.tellaev.de/stellaev/churndetection_ibmtelco
Dort finden Sie:
- Python-Jupyter Notebook – DecisionTree, RandomForest, XGBoost Hyperoptimierung, XGBoost RSHyperoptimierung
- Tableau – Featureselection und Featureanalysis
- KNIME – Workflows als Prototyping
- Datensatz – Datenquelle: IBM Telco Customer Churn Dataset, Kaggle Playground Series S6E3. Lizenz: CC BY 4.0.
Kontakt
Fragen? Feedback? Eigene Erfahrungen teilen? Schreiben Sie mir gerne: