EN 
Українська
Polski
Español
Deutsch
日本語
Italiano
Português (BR)
Français
العربية
Nederlands
中文
한국어
हिन्दी
Türkçe
Tiếng Việt
Русский
Bahasa Indonesia
فارسی
বাংলা
ไทย
Filipino
Kiswahili
اردو
Bahasa Melayu
தமிழ்
עברית
Ελληνικά
ਪੰਜਾਬੀ
አማርኛ
မြန်မာဘာသာ
ខ្មែរ
ქართული
नेपाली
Монгол хэл
Հայերեն
සිංහල
ລາວ
Čeština
Română
Magyar
Български
Svenska
Dansk
Suomi
Norsk
Slovenčina
Hrvatski
Српски
Slovenščina
Lietuvių
Latviešu
Eesti
Íslenska
Shqip
Македонски
Bosanski
Malti🎯 Churn Prediction ROC Explorer
Interactive churn-prediction simulator: drag a decision threshold and watch the ROC curve, precision-recall tradeoff and business cost move together in real time.
About the Churn Prediction ROC Explorer
Most business machine-learning models don't output a decision — they output a probability. A churn model doesn't say "this customer will leave," it says "this customer has a 73% chance of leaving." Turning that probability into an action (send a retention offer or don't) requires picking a decision threshold, and that single choice determines how many real churners you catch, how many false alarms you generate, and ultimately how much the model is worth in pounds and pence. This simulation generates a synthetic population of customers with known outcomes and model scores, then lets you explore that threshold decision directly.
Drag the model-quality slider and watch two overlapping score distributions — retained customers clustered near zero, churned customers clustered higher — separate or collapse into each other. As you move the threshold slider, a marker slides simultaneously across the score histogram, the ROC curve and the precision-recall curve, so the connection between "where I cut the scores" and "where I land on the curve" is immediate and visual. A live cost calculator lets you weigh a wasted retention offer against a lost customer and see exactly which threshold minimises total expected cost — which is rarely the same threshold that looks "best" on the ROC curve alone.
Frequently Asked Questions
What does AUC actually measure?
AUC (area under the ROC curve) is the probability that the model ranks a randomly chosen churned customer higher than a randomly chosen retained customer. AUC = 1.0 means perfect ranking — every churner scores above every non-churner. AUC = 0.5 means the model is no better than a coin flip. Critically, AUC is threshold-independent: it summarises the model's ranking ability across every possible cutoff at once, which is why it does not tell you what threshold to actually use in production.
Why is accuracy misleading when only 20% of customers churn?
With a 20% base churn rate, a lazy model that predicts "never churns" for every customer is already 80% accurate while catching zero real churners. Accuracy weights both classes equally, but in an imbalanced population the majority class dominates the score. That is why this simulation reports TPR (recall), precision and cost instead of accuracy — they expose how well the model finds the rare positive class rather than rewarding it for parroting the majority.
What is the tradeoff between precision and recall as I move the threshold?
Raising the threshold means only very high scores are flagged as churn, so precision (the fraction of flagged customers who truly churn) tends to rise while recall (the fraction of true churners you actually catch) falls. Lowering the threshold does the opposite — you catch more churners but flag more false alarms. The precision-recall curve traces this whole tradeoff; there is no threshold that maximises both simultaneously unless the classes are perfectly separable.
How does the cost-optimal threshold differ from the point closest to the ROC curve's top-left corner?
The top-left corner of the ROC curve (TPR = 1, FPR = 0) is a purely statistical ideal that treats a false positive and a false negative as equally bad. The cost-optimal threshold instead minimises total expected business cost = FP × cost-per-false-positive + FN × cost-per-false-negative. If a missed churner is far more expensive than a wasted retention offer, the cost-optimal threshold sits lower (catch more churners) than the statistically "balanced" point, and vice versa.
Why do real-world churn thresholds get chosen by business cost rather than pure statistics?
A model's probability output is only an intermediate product — the business decision is binary: send the retention offer or don't. Two companies with the identical model and identical AUC can rationally choose completely different thresholds if their cost structures differ, for example a low-margin subscription business versus a high-value enterprise contract. This is why deploying a model always involves a conversation with the business about the relative cost of false positives and false negatives, not just a data-science metric.
What does the "model quality" slider actually change?
It controls how far apart the score distributions of retained and churned customers are. At low quality the two bell-shaped score distributions overlap heavily, so no threshold separates them well and the ROC curve sits close to the diagonal (AUC near 0.5). At high quality the distributions barely overlap, the ROC curve bows sharply toward the top-left corner, and AUC approaches 1.0 — this is exactly what improving a real model's features or algorithm does to its score distribution.
Why does the ROC curve look like a staircase, and what is the diagonal line?
The ROC curve is built by sweeping the threshold across every distinct score present in the finite sample of customers; each time the threshold crosses one customer's score, the curve steps either up (a true positive was captured) or right (a false positive was captured), producing a staircase rather than a smooth line. With more customers the steps get finer and the curve looks smoother. The dashed diagonal from (0,0) to (1,1) represents a model with zero predictive skill — a classifier that guesses at random has an expected ROC curve that lies exactly on this line.
A trained classifier scores customers by churn probability — drag the threshold and watch the ROC curve and business cost move together.
3D · Three.js / WebGL renderer · 60 FPS target · runs fully client-side, no install