Features, and explaining what the model did

Given a fixed dataset, the difference between a mediocre model and a good one is usually features, not the algorithm. Given a fixed model, the difference between one that gets deployed and one that does not is usually whether anyone can explain it.

Feature types and what they need#

Numeric. Trees do not care about scale; linear models and anything distance-based do. For skewed columns, a log transform often turns a curved relationship into a straight one — check the residual plot in the Regression Lab before and after.

Categorical. One-hot for low cardinality. For high cardinality, target encoding — but compute it within cross-validation folds, or you leak the target straight into the feature. This is one of the most common leaks in practice.

Datetime. Never feed a raw timestamp. Extract hour, day of week, month, is-weekend, is-holiday, days-since-event. For cyclical features, encode the cycle rather than the integer:

import numpy as np
df["hour_sin"] = np.sin(2 * np.pi * df["hour"] / 24)
df["hour_cos"] = np.cos(2 * np.pi * df["hour"] / 24)

Otherwise hour 23 and hour 0 are maximally distant, when they are adjacent.

Text. Start with length, word count, and a handful of keyword flags. They are often most of the signal, and they are trivially explainable. Reach for embeddings when you have shown the simple version is insufficient.

Aggregates over history. Counts, sums and rates over trailing windows — 7, 30, 90 days. Usually the most predictive features in business problems. And the most dangerous: every one must be computed strictly as of the prediction time.

The features that usually matter most#

In business prediction problems, in rough order:

1. Recency — days since last purchase, login, contact.
2. Frequency — events in the trailing window.
3. Monetary — spend in the trailing window.
4. Tenure — how long they have existed.
5. Trend — this month versus the previous three, as a ratio.
6. Diversity — distinct categories, products, channels touched.

That is RFM plus two, and it is a strong opening hand for churn, propensity, and lifetime value alike.

Interpretation, and its limits#

Coefficients (linear/logistic). Directly interpretable if features are scaled and not strongly collinear. Collinearity makes individual coefficients unstable and their signs unreliable — check variance inflation factors before reading any single coefficient as a story.

Permutation importance. Shuffle a column, measure the drop in score. Model-agnostic and honest about what the model uses. Splits credit arbitrarily between correlated features — if two columns carry the same information, both may look unimportant because either can substitute for the other.

SHAP values. Per-prediction attributions with a sound theoretical basis. Excellent for explaining an individual decision to a person. Expensive on large data, and routinely over-interpreted.

Partial dependence: the shape, not just the ranking#

Importance tells you which features the model uses. Partial dependence tells you how — and that is what stakeholders actually want.

from sklearn.inspection import PartialDependenceDisplay
PartialDependenceDisplay.from_estimator(model, X_test, features=["tenure_days", "seats"])

The shapes are where the insight lives: a threshold effect at 30 days, a plateau above 50 seats, a non-monotone dip in the middle. They also catch bugs — a feature whose partial dependence is a perfect step function at a suspiciously round number is usually leakage.

Explaining a model to a non-technical stakeholder#

Four things, in this order:

1. What it predicts, and for whom. "For each account, the chance it cancels in the next 60 days."
2. How good it is, against the alternative. "It catches 62% of cancellations in the top 10% of scores. Ranking by tenure alone catches 21%."
3. What drives it, with shapes. "Recency of login matters most, and the risk rises sharply after 14 days of inactivity."
4. Where it is unreliable. "It has almost no signal for accounts under 30 days old, because there is not enough history."

The fourth point buys more credibility than the other three combined. A model whose author volunteers its weaknesses gets trusted; one presented as uniformly excellent gets tested until it fails publicly.

Fairness, briefly but seriously#

If a model affects people — hiring, lending, pricing, prioritisation — check its behaviour across groups. Removing the protected attribute does not remove the bias; other features proxy for it, often strongly.

Measure the error rates by group, not just overall. A model with 85% accuracy overall can be 92% for one group and 61% for another, and the aggregate number hides it completely. Which fairness definition applies is a decision that involves people beyond the data team — but measuring the disparity is unambiguously your job, and it takes one groupby.