# Churn Prediction

Estimating which customers will stop using a product, so retention effort can be targeted before they leave.

**Rests on:** Logistic Regression, Rare Event Prediction

*Machine Learning · Machine Learning Foundations*


## Why learn this

Churn prediction teaches you how to use past history to change real-world decisions before it is too late. Imagine a subscription service losing customers every month. If the company knows who will leave next, they can offer a discount or a call to keep them, saving revenue. To do this safely, you must avoid 'leakage' (a critical error where information from the future unknowingly slips into the past data, making a model appear perfect when it is actually broken). This process also illustrates 'supervised' learning (the method of teaching a computer by showing it labeled examples, like 'this customer left' or 'this customer stayed'). Mastering this gives you a concrete framework for evaluating whether a prediction will actually work in the real world, which applies to every **Logistic Regression** model (a specific statistical method for binary choices) and **Decision Trees** (a flowchart-like structure that splits data based on simple rules) later on.


## The intuition

Think of a streaming service like Netflix or Spotify. Every month, some subscribers cancel their account. The company wants to know, before the month ends, which specific people are about to leave, so they can intervene with a special offer or a friendly phone call. To build this ability, the company collects history for every past subscriber: how long they have been with us, how often they watched, how many devices they use, and whether their payment has ever failed. Crucially, the company also knows the final outcome for each of those people: did they eventually leave or stay? From this history, we want to build a rule that, for any current subscriber, reads their numbers and produces a score between 0 and 1. A score of 1 means 'almost certainly leaving' and 0 means 'almost certainly staying'. We do not write this rule by hand. Instead, we let the computer discover it from thousands of past examples. The computer finds patterns, such as 'subscribers who log in less than once a week are more likely to leave,' and encodes those patterns into a function. When we feed new customers through that function, we get a churn score. This prediction is useful only if we can intervene in time, with a cost less than the revenue the customer would bring if they stayed.


## An analogy

A doctor does not wait until a patient collapses to treat them. Instead, the doctor looks at measurements like heart rate and blood pressure and compares them with years of records from thousands of other patients. From those records, the doctor has learned a pattern: certain combinations of measurements are associated with a higher risk of a heart attack. When a new patient comes in with slightly abnormal numbers, the doctor flags them as high-risk and prescribes preventive medication. Churn prediction works exactly the same way: the patient is a customer, the heart attack is a cancellation, and the doctor is a machine-learning model. The historical records are the training data: every past customer, their features, and their eventual outcome. The analogy breaks in one crucial way. A doctor's model is built on medical knowledge of cause and effect; a churn model is purely empirical, finding correlations without understanding why. It might mistakenly learn that customers whose names start with 'A' churn more, which is meaningless noise rather than a real cause. This caveat warns us that correlation does not always mean we can change the outcome.


## Definition

Churn prediction is the process of building a function from historical customer data that estimates, for each current customer, the probability that they will stop using the product within a defined time window, so that retention actions can be targeted at those most likely to leave. It is a supervised learning task because it relies on past examples where the outcome was already known.


## How it connects

This concept sits at the very start of your Machine Learning Foundations study as your first concrete instance of learning functions from data rather than specifying them by hand. Churn prediction is a 'supervised' problem (a category where we teach a model by showing it labeled examples, such as 'churned' or 'not churned'), which is why the **train-validate-test** split (a method of dividing data into three parts: one for learning, one for tuning, and one for final testing) is essential to trust the model. The neighbouring topic of **Rare Event Prediction** is directly relevant because churn is often a rare event; if only 2% of subscribers leave each month, a simple model that always predicts 'stays' would be 98% accurate but completely useless for identifying who actually leaves. Finally, the classical models you have recorded — **Logistic Regression**, **Decision Trees**, and **Random Forests** — are the standard tools for churn on tabular data, reinforcing the principle that simple models often remain the best answer for structured customer information.


## The mathematics

Churn prediction is a type of statistical learning where we use past data to guess an unknown future event: whether a specific customer will leave (churn) or stay. The model does not give a simple 'yes' or 'no' answer. Instead, it gives a number between 0 and 1. We interpret this number as a probability. A result of 0.8 means the model estimates an 80% chance that the customer will churn.

To get this number, the model performs two main steps using basic arithmetic and one standard function.

Step 1: The Weighted Sum
The model looks at several features (numbers describing the customer), such as 'days since last login' or 'number of support tickets'. For each feature, there is a corresponding weight. A weight is a number that tells us how much that specific feature matters and in which direction.

- If the weight is positive, a higher value for that feature increases the churn risk.
- If the weight is negative, a higher value for that feature decreases the churn risk.

The model calculates a single number called the 'weighted sum' (also known as the linear combination). It does this by:
1. Multiplying each feature value by its weight.
2. Adding all those products together.
3. Adding a final constant number called the 'bias'. The bias shifts the entire result up or down, acting like a baseline churn tendency before any specific features are considered.

Mathematically, if we have n features, the formula is:
Sum = (weight1 × feature1) + (weight2 × feature2) + ... + (weightn × featuren) + bias

This Sum can be any number: negative, positive, large, or small. It is not yet a probability.

Step 2: The Sigmoid Function
To turn this arbitrary Sum into a probability between 0 and 1, we pass it through a fixed mathematical function called the sigmoid function (sometimes called the logistic function). The sigmoid function takes any real number as input and outputs a value strictly between 0 and 1.

The formula for the sigmoid is:
P = 1 / (1 + e^(-Sum))

Here, 'e' is a mathematical constant approximately equal to 2.718. The term 'e^(-Sum)' means raising e to the power of negative Sum.

Key properties of the sigmoid:
- If the Sum is exactly 0, the output P is exactly 0.5 (a 50/50 chance).
- If the Sum is a large positive number, P gets very close to 1 (almost certain churn).
- If the Sum is a large negative number, P gets very close to 0 (almost certain retention).

The whole model is simply: calculate the weighted sum of your features and bias, then apply the sigmoid formula to that result.


## A worked example

Let us walk through a concrete example with three customers. We have two features for each customer:
1. Days since last login (let's call this x1). A higher number means less activity.
2. Number of support tickets in the last 30 days (let's call this x2).

We assume we have already trained a model on historical data and found the following weights and bias:
- Weight for x1 (days inactive): w1 = 0.05. This is positive, meaning more days inactive increases churn risk.
- Weight for x2 (tickets): w2 = 0.15. This is positive, meaning more tickets increases churn risk in this specific scenario.
- Bias: b = -1.0. This is the baseline shift.

The formula we will use for each customer is:
Sum = (0.05 × x1) + (0.15 × x2) - 1.0
Probability P = 1 / (1 + e^(-Sum))

Customer A
Features: x1 = 2 days, x2 = 1 ticket.

Step 1: Calculate the weighted sum.
Multiply x1 by w1: 0.05 × 2 = 0.10
Multiply x2 by w2: 0.15 × 1 = 0.15
Add these products and the bias:
Sum = 0.10 + 0.15 - 1.0
Sum = 0.25 - 1.0
Sum = -0.75

Step 2: Apply the sigmoid function.
P = 1 / (1 + e^(-(-0.75)))
Note that negative of negative 0.75 is positive 0.75.
P = 1 / (1 + e^(0.75))
Using a calculator, e^(0.75) ≈ 2.117
P = 1 / (1 + 2.117)
P = 1 / 3.117
P ≈ 0.321

Customer A has a 32.1% probability of churning.

Customer B
Features: x1 = 45 days, x2 = 4 tickets.

Step 1: Calculate the weighted sum.
Multiply x1 by w1: 0.05 × 45 = 2.25
Multiply x2 by w2: 0.15 × 4 = 0.60
Add these products and the bias:
Sum = 2.25 + 0.60 - 1.0
Sum = 2.85 - 1.0
Sum = 1.85

Step 2: Apply the sigmoid function.
P = 1 / (1 + e^(-1.85))
Using a calculator, e^(-1.85) ≈ 0.157
P = 1 / (1 + 0.157)
P = 1 / 1.157
P ≈ 0.864

Customer B has an 86.4% probability of churning.

Customer C
Features: x1 = 7 days, x2 = 0 tickets.

Step 1: Calculate the weighted sum.
Multiply x1 by w1: 0.05 × 7 = 0.35
Multiply x2 by w2: 0.15 × 0 = 0.00
Add these products and the bias:
Sum = 0.35 + 0.00 - 1.0
Sum = -0.65

Step 2: Apply the sigmoid function.
P = 1 / (1 + e^(-(-0.65)))
P = 1 / (1 + e^(0.65))
Using a calculator, e^(0.65) ≈ 1.916
P = 1 / (1 + 1.916)
P = 1 / 2.916
P ≈ 0.343

Customer C has a 34.3% probability of churning.

Summary of Results:
- Customer A: 32.1% churn risk
- Customer B: 86.4% churn risk
- Customer C: 34.3% churn risk

Customer B is at significantly higher risk than A or C, primarily due to the high number of inactive days (45) and multiple support tickets. The model suggests prioritizing retention efforts for Customer B.


## From scratch, in Python

```python
# Churn prediction, from scratch, on a tiny dataset.

# Our data: list of customers, each is a list [days_since_last_login, support_tickets]
# The target is 1 if the customer churned, 0 if they stayed.
# We will use a simple logistic regression model with two weights and a bias.
# In this example, we skip training and just use pre-set weights.

# Step 0: Define the training data (past customers)
# Each row: [days inactive, tickets, churned?]
data = [
    [2,  1, 0],   # customer A: stayed
    [45, 4, 1],   # customer B: churned
    [7,  0, 0],   # customer C: stayed
    [30, 2, 1],   # customer D: churned
]

# Step 1: Define the model's parameters (we set them arbitrarily for now,
# in a real project they would be learned from data by training)
w1 = 0.05       # weight for days inactive
w2 = 0.15       # weight for support tickets
b  = -1.0       # bias

# Step 2: Define the sigmoid function
def sigmoid(z):
    return 1 / (1 + 2.718281828459045 ** (-z))

# Step 3: Define the prediction function
def predict_churn(x1, x2, w1, w2, b):
    z = w1 * x1 + w2 * x2 + b    # weighted sum
    p = sigmoid(z)               # squash to probability
    return p

# Step 4: Make predictions for a few new customers
new_customers = [
    [5,  0],   # a usually active user
    [60, 5],   # a very inactive user with many tickets
    [10, 1],   # moderately active
]

for customer in new_customers:
    x1, x2 = customer
    prob = predict_churn(x1, x2, w1, w2, b)
    print(f"Customer (days={x1}, tickets={x2}) -> churn probability = {prob:.2f}")
```

(Note: The dataset size is far too small to train a real model, but the calculation shows the mechanics.)


## The same thing, with a framework

```python
# The same model using NumPy for vectorised arithmetic
import numpy as np

# Data as a 2D array (matrix) of features: rows are customers, columns are features
X = np.array([
    [2,  1],
    [45, 4],
    [7,  0],
    [30, 2]
])

# Target vector
Y = np.array([0, 1, 0, 1])

# Weights and bias (in a real project these would be trained)
w = np.array([0.05, 0.15])
b = -1.0

# Sigmoid function (vectorised: works on arrays element-wise)
def sigmoid(z):
    return 1 / (1 + np.exp(-z))

# Predictions for all data at once (this is the dot product we did by hand:
# each row of X is multiplied by w, then summed, then bias added)
z = X @ w + b
probs = sigmoid(z)
print("Training set predictions:", probs)

# Predictions for new customers
new = np.array([[5, 0], [60, 5], [10, 1]])
new_probs = sigmoid(new @ w + b)
print("New customers:", new_probs)
```


## What the code does

The plain Python code builds the entire model step by step. We start by defining a `list` of customers. A list in Python is an ordered collection that can be changed; here each customer is itself a list of two numbers (days inactive and tickets). The loop at the end (`for customer in new_customers:`) goes through each new customer one by one, extracts the two feature values, calls the `predict_churn` function, and prints the probability. The function `predict_churn` does exactly the weighted sum you worked by hand: `z = w1 * x1 + w2 * x2 + b`, then passes `z` into `sigmoid`. The function `sigmoid` is defined using the formula `1 / (1 + e^(-z))`, and we approximate `e` with `2.718281828459045`. In the NumPy version, the same arithmetic is expressed in one line: `z = X @ w + b`. The symbol `@` performs a **matrix-vector product**: it multiplies each row of `X` by the vector `w` element-wise and adds the results, exactly like your hand loop. NumPy does this efficiently for thousands of rows. The `np.exp` function computes `e` raised to a power for every element of an array at once. Underneath, NumPy is still doing the same multiply-and-add loops.


## Common misconceptions

**Churn prediction is the hard part** — If I build a model with 95% accuracy, I have solved the business problem.

Accuracy is meaningless when only 2% of customers churn; a model that always predicts 'stay' is 98% accurate. More importantly, an accurate prediction is worthless if there is no profitable action to take. Churn models fail in production not because they are inaccurate, but because the intervention is too little, too late, or too costly. In fact: Churn prediction is only a means to an end. The real value comes from pairing a well-calibrated probability with an intervention whose expected benefit outweighs its cost. The hardest part is often defining the *exact* target (what counts as churn: cancellation, non-renewal, 90 days of inactivity?) and ensuring the data reflects that definition accurately.

**More features always make the model better** — I'll include every column in the database; the model will sort out what matters.

Including features that are affected by the outcome (or by the decision itself) causes leakage. For example, 'ticket log mentioning cancellation' is only known after the customer has decided to cancel. Also, irrelevant features can add noise and overfit the training data, making the model perform worse on new customers. In fact: Feature selection is a key skill. Use only information that is available **at the moment** you want to make the prediction. Domain knowledge plus simple diagnostics (e.g., correlation with churn) guide what to include. Your library's emphasis on *data quality dominates algorithm choice* is exactly this: a few clean, well-defined features beat a hundred messy ones.

**The sigmoid output is a sure classification** — If the model says 0.8, the customer is definitely churning.

A probability of 0.8 does not mean the customer *will* churn; it means that, based on the model, there is an 80% chance they will, given the historical patterns. Probabilities are not certainties, and they reflect the model's ignorance, not a hidden truth. In fact: The model output is an estimate, calibrated to historical data. It is better to think of it as a risk score that ranks customers. The business then decides a threshold based on the **cost of a false alarm** (offering a discount to a customer who would have stayed anyway) versus the **cost of a miss** (losing a customer without any attempt to retain them). This trade-off is the core of your **Rare Event Prediction** notes.

**Churn prediction is the same as customer satisfaction** — If a customer is happy, they will never churn; so I just need to measure satisfaction.

A customer can be satisfied but still churn because of price, a competitor's offer, or a change in their own circumstances. Conversely, some unhappy customers stay because of switching costs. Satisfaction is one factor, not the whole story. In fact: Churn is driven by many causes, and the model learns their combination. Satisfaction surveys might be one input, but usage patterns, support interactions, and payment history often carry more signal. The model's job is to find the best combination from whatever informative data is available.


## In short

Churn prediction is the task of estimating which customers will leave, using historical data and a weighted sum of features passed through a sigmoid to get a probability. The core loop is: define the target, gather clean features, train a logistic regression (or a tree-based model), evaluate with a metric that respects class imbalance, and connect the score to a concrete retention action. The two biggest pitfalls are leakage (using information available only after the decision) and treating prediction as an end rather than a means — a churn model is only as good as the intervention it drives. If you remember nothing else, remember that the probability is not a verdict; it is guidance for where to spend limited retention effort, and the business context determines the threshold.


## Where this is used

Churn prediction is one of the most widely deployed machine learning applications in industry, and its principles appear throughout modern AI systems.

**In everyday applied machine learning** (the most direct case): Almost every subscription business — telecom, SaaS, banking, OTT streaming — runs a churn model. A data scientist gathers a table of customers: demographics, usage statistics, payment history, support interactions, and a column labelled 'churned' (1 if the customer cancelled within the next, say, 30 days, 0 otherwise). They train a **logistic regression** or a **random forest** on that table. The model outputs a probability for each current customer. The business then sets a threshold: customers with probability > 0.7 get a retention email with a discount; those > 0.9 get a phone call from a retention agent. The developer's code looks like what you saw in the NumPy example, but with a real trained model, typically loaded from a library such as scikit-learn. The crucial part is the **intervention**: the model is only as good as the action it triggers. If the discount costs more than the customer's expected lifetime value, the model is counterproductive. In practice, developers also have to be careful about **leakage**: if the training data contains a feature that is only known *after* the decision (e.g., 'customer called to cancel'), the model will predict perfectly in training but fail in production. Your library explicitly flags leakage as a persistent trap — it is the single most common reason a churn model looks great in testing and fails in deployment.

**In small language models and on-device models**: Churn prediction itself usually does not run on a phone — it runs on the company's servers. However, the *on-device* trend touches churn indirectly. For example, a music streaming app might run a small language model on your phone to analyse your listening habits *locally* (without sending your data to the cloud) and then use that summary — along with other features — to update a churn score. The small model computes an embedding (a list of numbers representing your behaviour) that becomes one more feature in the churn model. The key is that the churn model itself remains a lightweight logistic regression or tree, because it must score millions of users quickly and cheaply. The on-device component just enriches the input features while preserving privacy, a common requirement in banking and health apps.

**In large language models (LLMs)**: LLMs are not the primary tool for churn prediction — the tabular logistic regression wins on small structured data, as your library notes. But LLMs are increasingly used in the *why* and *what-to-do* parts. After the churn model flags a customer as high-risk, an LLM can read the customer's support chat history and generate a personalised retention message: 'I see you had trouble with our billing last week — here is a one-month credit.' LLMs can also be used to *extract features* from unstructured text (e.g., sentiment of support tickets) that feed into the churn model. So the LLM does not replace the churn predictor; it augments the intervention and the feature engineering.

**In retrieval-augmented generation (RAG)**: RAG is used in customer-facing chatbots that a churn-prone customer might visit. When a customer with a high churn score opens the support chat, a RAG system retrieves the most relevant help articles or past conversation snippets and a language model uses them to craft an answer. The churn model decides *who* to give the premium support experience; RAG powers that experience. Without churn prediction, RAG would treat every customer identically; with it, the company can escalate the right customers to a human agent or a specialised response.

**In agentic systems that plan and act**: At the frontier, churn prediction is being embedded into autonomous agents. An AI 'retention agent' could have the goal of reducing churn for a list of at-risk customers. It queries the churn model's probabilities, then plans: for each high-risk customer, it selects a tool (e.g., 'send promotional email', 'schedule a callback', 'apply a discount code') and executes it. It then observes whether the customer remains active and updates its plan. In this loop, the churn model is a component that the agent calls thousands of times, and the quality of those probability scores determines the quality of the agent's decisions. A poor churn model — say, one with leakage — would make the agent take counterproductive actions on a massive scale.


---

Read this on the web: https://basavapurushottam.com/learn-ai/churn-prediction
