In einem Satz.
Ich mache Daten vertrauenswürdig. Dann prädiktiv. Diese Masterarbeit wendet diesen Ansatz end-to-end an.
Das Problem.
Standard-ELT-Tools und klassisches ETL setzen stabile Schemata und gut funktionierende APIs voraus. In einer realen B2B-SaaS-Umgebung trifft das nicht zu: Schema-Drift, NULL-Primary-Keys, HTTP-429-Ratelimits, Mid-Pagination-500s, verspätete SFTP-Dateien. Gleichzeitig dominiert in der Churn-Forschung B2C-Telekommunikation. B2B-SaaS (weniger Accounts, höherer Umsatz pro Account, mehrstufige Kündigungspfade) wird kaum erforscht. Beide Lücken habe ich in einem einzigen Live-Deployment in vollständiger Eigenverantwortung adressiert.
Was ich gebaut habe.
1. JSONB-First-ELT-Pipeline (eigenentwickelt).
Ingestion (Python 3.11). Eigenentwickelte Extraktoren pro Vendor, jeder mit eigener Auth, Paginierung und Fehlerbehandlung. Per-Account-Isolation, sodass ein Mid-Pagination-500 in einem Account keine Kaskade auslöst. Multi-Stage-Backoff mit Retry-After-Beachtung. Deterministische _ingestion_id via SHA-256-Content-Hashing für NULL-Primary-Keys. SFTP-File-Level-Cursors mit Lookback für verspätete Dateien. pytest-Tests für Cursor-Persistenz, Hashing und Retry-Logik.
Orchestrierung. Dagster Software-Defined Assets, sodass ein Vendor-Fehler nicht zu den anderen kaskadiert. Geplante tägliche Ingestion, nachgelagerte dbt-Transformation und wöchentliches ML-Scoring.
Raw-Layer. Append-only PostgreSQL 16 mit JSONB-Spalten und GIN-Indizes. Über 1 Million geladene Datensätze, volle Quelltreue, deterministisches Replay. GIN-Indizes beschleunigen Lookups auf der größten Tabelle.
Transformation. dbt Core 1.9, 48 Modelle über Staging-Views, Intermediate-Tabellen (inklusive MDM-artigem Cross-Source-Account-Spine, rekursiver CTE-Kundenhierarchie und Gaps-and-Islands-Engagement-Streaks), Star-Schema-Marts und einen ML-Feature-Layer. Automatisierte Tests fingen Datenqualitätsprobleme ab, einschließlich UUID-Casing-Konflikten, die ohne Korrektur Cross-Source-Matches verfälscht hätten.
2. Drei-Modell-Churn-Intelligence-Stack.
Jedes Modell beantwortet eine andere operative Frage:
- Survival-Modell:
GradientBoostingSurvivalAnalysis(scikit-survival). Wann wird ein Account abwandern? Kreuzvalidierter C-Index 0,850. - Health-Score: XGBoost via PostgresML (In-Database-Training). Wie wahrscheinlich ist Churn? Kreuzvalidierte AUC 0,924, besser als eine logistische Baseline. SHAP-Attributionen pro Vorhersage.
- Kausalmodell: DR-Learner (econml). Würde CSM-Outreach diesem Account tatsächlich helfen? Die naive Korrelation zwischen CSM-Zuweisung und Retention war durch reaktiven Zuweisungs-Selektionsbias erheblich überschätzt, da CSMs Accounts zugewiesen wurden, die bereits in Schwierigkeiten waren. Die DR-Learner-Korrektur legte den ehrlichen Treatment-Effekt offen, deutlich kleiner als die naive Schätzung, aber belastbar positiv.
Mit strikter prospektiver Kohorte (Beobachtungsfenster gefolgt von einem separaten Outcome-Fenster) zur Leakage-Vermeidung. Die Features verteilen sich auf sechs thematische Gruppen (Billing, Engagement-Volumen, Engagement-Verlauf, Support, Integration, hierarchieübergreifende Aggregationen).
3. Serving und Agentic-Schnittstelle.
FastAPI-Service mit JWT-Auth und PostgreSQL Row-Level Security für CSM-spezifisches Scoping, sodass ein CSM nur die ihm zugewiesenen Accounts sieht.
Angular-19-Dashboard mit SHAP-Erklärungen pro Account für das Customer-Success-Team.
Model-Context-Protocol-(MCP)-Endpoint, sodass ein LLM-Agent Account-Risiko, Treiber und Interventionsempfehlungen direkt abfragen kann. Damit stehen agentische Workflows über der Customer-Intelligence-Schicht jedem MCP-kompatiblen Client zur Verfügung.
4. Priorisierungs-Framework.
Zeitliche Dringlichkeit (Survival), Risikoklassifikation (Health-Score) und Interventions-Responsiveness (CATE aus dem Kausalmodell) in eine Tier-Rangfolge kombiniert. Ergebnis: eine belastbare, erklärbare Priorisierungsliste für CSM-Aktionen, jede Empfehlung rückführbar auf die zugrunde liegende Modell-Evidenz.
Architektonische Entscheidungen.
JSONB-First-Raw-Layer. Vendor-APIs ändern ihre Schemata häufig. Rohpayloads als JSONB mit GIN-Indizes ermöglichen jederzeit Replay, vollständiges Audit zurück zur Quelle und Schema-Anpassungen ohne Pipeline-Rebuild. Da die Raw-Schicht append-only ist, lässt sich jede Transformation aus den Rohdaten reproduzieren.
Drei Modelle, drei Fragen. Survival, Klassifikation und Causal Inference beantworten jeweils etwas anderes. Die meisten "Churn-Modelle" liefern nur Klassifikation und behandeln sie, als beantworte sie alle drei. Weil ich die Fragen trenne, entstehen drei verschiedene operative Ergebnisse, mit denen das Customer-Success-Team arbeiten kann.
Ehrliche kausale Korrektur statt naiver Korrelation. Die meisten Churn-Interventionssysteme berichten die rohe Korrelation zwischen Treatment und Outcome und behandeln sie wie einen Treatment-Effekt. Das verwechselt Korrelation mit Kausalität bei vorliegendem Selektionsbias. Die DR-Learner-Korrektur legt die ehrliche Zahl offen, deutlich positiv, aber wesentlich kleiner als die naive Schätzung. Ich berichte lieber die kleinere ehrliche Zahl als die überhöhte naive.
MCP als Schnittstelle für Agenten. Dashboards informieren, Agenten handeln. Die Customer-Intelligence-Schicht über MCP zugänglich zu machen, bedeutet, dass ein LLM-Agent ein Risikoprofil pro Account abrufen, nach den Gründen fragen und die nächste Intervention empfehlen kann, ohne dass ein CSM ins Dashboard wechseln muss.
Bemerkenswerte Ergebnisse.
- Über 1 Million Datensätze aus mehreren Vendor-APIs geladen.
- 48 dbt-Modelle, Datenqualitätsprobleme vor der Produktion abgefangen und gelöst.
- C-Index 0,850 (Survival), AUC 0,924 (Health-Score), messbare kausale Korrektur, die den Selektionsbias aus reaktiver Zuweisung offenlegt.
- Cursor-sichere Neustarts: Ein Vendor-Lauf kann ab dem letzten Cursor neu starten.
- Durchgängig DSGVO-konforme Pseudonymisierung unter NDA.
Was diese Arbeit belegt.
End-to-End-Verantwortung: API-Extraktoren, Warehouse-Modellierung, Multi-Modell-ML, Causal Inference, REST- und MCP-Serving und ein Analytics-Dashboard, alles von mir entworfen, gebaut und getestet, in der akademischen Betreuung verteidigt und in einer realen Produktionsumgebung deployt. Die Pipeline ist auf die API-Fehler ausgelegt, die in der Live-Umgebung tatsächlich auftraten. Produktionsorientiert: Tests, RLS, JWT, deterministische IDs, Append-only-Audit-Trail, DSGVO-konforme Pseudonymisierung unter NDA.
Stack.
Python 3.11 · PostgreSQL 16 (JSONB + GIN) · Dagster · dbt Core 1.9 · PostgresML · XGBoost · scikit-survival · econml (DR-Learner) · SHAP · FastAPI · Angular 19 · Model Context Protocol (MCP) · pytest