Build Features People Can Understand
A clear equation is only useful when its inputs have clear meanings. “Visits” sounds obvious, but does it count the previous seven days, the previous month, or all visits ever recorded? This chapter turns that question into concrete feature definitions.
State when the prediction is made
Our running example predicts next month’s spending. Visits means completed visits during the previous calendar month. Plan means the plan recorded at the prediction time. Observed spending is collected after the target month ends.
| Item | Available when predicting? | Role |
|---|---|---|
| Previous-month visits | Yes | Model input |
| Current plan | Yes | Model input |
| Next-month spending | No | Outcome to predict |
| Refund after next month ends | No | Not an input for this prediction |
This definition also gives a simple explanation: “The prediction uses your visits last month and the plan you currently have.” A column called activity_score_v7 would need much more unpacking.
Put counts on a meaningful observation window
Imagine a separate activity report for our four customers. Each report counts recent visits, but the available history covers different numbers of days. These are new history measurements, not replacements for the previous-month inputs in Part 1.
| Customer | Visits recorded | Days observed | Visits per 7 days |
|---|---|---|---|
| Asha | 1 | 7 | 1 |
| Ben | 1 | 14 | 0.5 |
| Cara | 3 | 7 | 3 |
| Dev | 3 | 14 | 1.5 |
Asha and Ben both have one recorded visit. But Ben’s history covers twice as long. Compute a common rate:
Ben: 7 × 1 / 14 = 0.5.
If this rate became a model input, its coefficient would mean “dollars per additional weekly visit in the measured rate.” We would need to refit the model for that definition. We cannot silently replace the old monthly count while keeping its coefficient 5.
A history with zero observed days has no measured rate. Treat it as missing or give it an explicitly designed representation. Calling it zero activity would confuse “we saw no visits” with “we had no opportunity to observe visits.”
Make larger values mean what the reader expects
Suppose we want to capture increasing activity. Here is another small example using the same names:
| Customer | Earlier visits | Recent visits | Recent / earlier |
|---|---|---|---|
| Asha | 2 | 4 | 2 |
| Ben | 4 | 2 | 0.5 |
| Cara | 3 | 3 | 1 |
| Dev | 1 | 3 | 3 |
Asha’s ratio of 2 means recent activity doubled. Ben’s 0.5 means it halved. A value of 1 means no change. This direction is easy to explain: larger values mean more growth.
The inverse ratio would carry related information but reverse the direction. It might make the eventual explanation harder to follow. Choosing the orientation is part of feature design. Changing a ratio to its inverse generally changes the functions a linear model can fit, so refit and evaluate it rather than assuming the predictions stay identical.
If the earlier count is zero, the ratio is undefined. For a first implementation, an absolute change plus a “no earlier activity” indicator may be easier to interpret. A feature should have a meaningful definition for the rows where you will actually use it.
Choose useful information from different sources
Suppose our candidate list contains visits last month, visits over two months, time spent visiting, current plan, and a customer identifier. Ranking each column in isolation can fill the shortlist with several versions of activity.
| Candidate | What it contributes | Decision to investigate |
|---|---|---|
| Monthly visits | Activity level | Keep as a clear starting feature |
| Visit minutes | Another activity measure | Check what it adds beyond visits |
| Current plan | Service tier | Keep a distinct source of information |
| Customer identifier | Record identity | Exclude from this simple spending model |
| Future refund | Later outcome information | Unavailable at prediction time |
A useful candidate should be predictive in evaluation, reliably measured, available when needed, and clear enough to describe. Also check whether its meaning is likely to remain stable. If an app release changes what counts as a “visit,” the same stored number may stop representing the same behavior.
Predictive value depends on the other inputs. A modest feature by itself can add something valuable to a model; two strong features by themselves may mostly repeat each other. Keep that context when selecting the final set.
Turn definitions into a working process
- Define the prediction time and target. List the events that have happened by that time.
- Build readable features. State the window, units, and missing-value behavior.
- Group overlapping candidates. Start with the underlying measurements they share.
- Fit and compare on development data. Check whether the simpler set preserves useful prediction quality.
- Evaluate the chosen model on fresh rows. Keep the feature definitions and transformations fixed.
For our running model, the definitions fit in one sentence and there are only two inputs. In larger datasets, grouping overlapping candidates becomes the difficult step. The next chapter uses feature clustering to make that grouping visible.
Sources and worked examples
This chapter develops ideas from the lessons below in A Data Odyssey’s Explainable AI playlist. The customer data, calculations, figures, and interactive examples here are original teaching examples. The creator’s companion notebooks use different datasets.
- Interpretable Feature Engineering — Conor O’Sullivan, A Data Odyssey.
- 8 Characteristics of a Good Machine Learning Feature — Conor O’Sullivan, A Data Odyssey.