Day 04 Part 1 — ML for Analysts¶
You don't need to be a data scientist to use machine learning thinking. This session demystifies ML for analysts: what the main types of problems are, when ML helps vs when simpler methods win, and crucially — when to escalate to a data science team rather than build it yourself.
Learning Objectives¶
- Distinguish regression, classification, and clustering
- Understand the ML workflow at a conceptual level
- Know when ML is overkill vs when it adds value
- Recognise when to escalate to data science
- Interpret model outputs and avoid common pitfalls
The Three Main Problem Types¶
| Type | Predicts | Example | Output |
|---|---|---|---|
| Regression | A continuous number | Forecast next month's revenue | A value (£) |
| Classification | A category | Will this customer churn? | A label + probability |
| Clustering | Groups (unsupervised) | Segment customers by behaviour | Group assignments |
Supervised vs unsupervised
Regression and classification are supervised — you train on labelled examples (you know the past answers). Clustering is unsupervised — there's no "right answer," you're finding structure. RFM segmentation is essentially manual clustering.
The ML Workflow (Conceptual)¶
1. Define the problem → what are we predicting, and why?
2. Gather & label data → the target variable + features
3. Engineer features → the analyst's superpower (most of the value is here)
4. Split data → train / test (never test on training data!)
5. Train a model → fit the algorithm to training data
6. Evaluate → how well does it predict on unseen test data?
7. Deploy & monitor → use it, watch for drift
Feature engineering is where analysts add the most value
The algorithm matters less than the features you feed it. A simple model with great features (recency, frequency, tenure, engagement) beats a fancy model with raw data. This is exactly the analytical skill you've built all course — and it's the most transferable to ML.
Common Algorithms (Just Enough to Talk About)¶
| Algorithm | Type | When |
|---|---|---|
| Linear Regression | Regression | Simple, interpretable numeric prediction |
| Logistic Regression | Classification | Churn, conversion — interpretable, a great baseline |
| Decision Tree | Both | Interpretable rules, handles non-linearity |
| Random Forest / Gradient Boosting (XGBoost) | Both | High accuracy, the workhorse for tabular data |
| K-Means | Clustering | Customer/product segmentation |
# A conceptual classification example with scikit-learn
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report
X = df[["tenure", "monthly_charges", "num_addons", "overtime_flag"]]
y = df["churned"]
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
model = LogisticRegression().fit(X_train, y_train)
print(classification_report(y_test, model.predict(X_test)))
Evaluating Models (Without the Maths)¶
| Problem | Don't rely on | Use |
|---|---|---|
| Classification (imbalanced) | Accuracy | Precision, Recall, F1, ROC-AUC |
| Regression | — | MAE, RMSE, R² |
| Clustering | — | Silhouette score, business interpretability |
Accuracy lies on imbalanced data
If only 5% of customers churn, a model that predicts "nobody churns" is 95% accurate and completely useless. For rare events, recall (did we catch the churners?) matters far more than accuracy.
When ML Is Overkill¶
Don't reach for ML when a simpler method works: - A simple rule ("customers inactive 90+ days are at risk") often beats a model and is explainable - A SQL query answers "what happened" — you don't need ML for descriptive analytics - A heuristic score (like the churn risk score in Projects/Customer-Churn-Analysis/sql-analysis) is interpretable and good enough for many cases
ML adds value when: the patterns are complex and non-obvious, the prediction needs to be automated at scale, and you have enough quality labelled data.
When to Escalate to Data Science¶
As an analyst, escalate when: - The model will make automated, high-stakes decisions (credit, hiring, medical) - Production deployment, monitoring, and retraining are needed - The problem needs deep learning, NLP, or computer vision - Statistical rigour around causality or experimentation is required - The data volume or velocity exceeds what you can handle
Your role as the analyst: frame the problem, prepare the features, build a baseline, and know enough to collaborate well with data scientists.
Practice Exercises¶
Warm-up 1. Classify each as regression, classification, or clustering: (a) predict next month's sales, (b) flag fraudulent transactions, (c) group customers by behaviour, (d) predict review score 1-5. 2. Explain why accuracy is a bad metric for a churn model where only 8% churn. 3. List 5 features you'd engineer to predict customer churn.
Main 4. Using scikit-learn, build a logistic regression to predict churn on the Telco dataset. Report precision and recall. 5. Build a simple rule-based churn flag and compare its recall to the model. 6. Use K-Means to cluster customers by RFM and interpret the clusters.
Interview Questions¶
[Beginner] What is the difference between regression and classification?
[Beginner] What is the difference between supervised and unsupervised learning?
[Mid-level] Why is accuracy a poor metric for imbalanced classification, and what would you use instead?
[Mid-level] Why is feature engineering often more important than the choice of algorithm?
[Senior] A stakeholder wants you to "build an AI model" to predict churn. How do you decide whether to build a simple heuristic, a model yourself, or escalate to data science?