From Raw Data to Features
With the churn frame agreed, Iris expects the data team to start training. Instead they open the customer table and stare at it for a week. The raw columns are humble: order timestamps, order amounts, delivery addresses, a support-ticket log. Nothing in there says "about to leave". And that is the problem — because as Topic 12 established, a model can only be as sharp as the features it is given. A pattern that no column expresses may as well not exist.
So the team spends the week manufacturing columns. Out of plain timestamps they build "days since last order", "orders per week, trending up or down", "share of orders placed with a discount". This craft — reshaping raw facts into telling ones the model can actually use — is called feature engineering, and it is where a large share of any data team's working weeks quietly go.
Raw Facts vs Telling Facts
Take one raw column and watch the transformation. A timestamp says when an order happened — a true, precise, useless-on-its-own fact. Subtract it from today and you get "days since last order", and suddenly the column says something about the framed question: is this customer drifting away? Nothing was added. The same information was reshaped until it pointed at churn.
Detectives have done this forever. A case board does not hold the raw witness reports — it holds the facts distilled out of them that discriminate between suspects: "alibi has a two-hour gap", "was near the scene twice". The skill is not gathering more paper; it is knowing which derived facts point somewhere. Feature engineering is exactly that skill, applied to columns — and with the analogy mapped, we can drop it, because the rest of the page is the real thing.
Where Do Feature Ideas Come From?
Here is the part that surprises most newcomers: feature ideas come from domain sense, not from mathematics. The couriers know that rain slows bikes — that hunch became a feature in the delivery-time model long ago. The support team knows that customers who file a complaint often go quiet a few weeks later — so "complaints in the last 60 days" joins the churn table. Every good feature starts life as a sentence someone who knows the business could say out loud.
Which means Iris is not a spectator here. When the data team runs its feature brainstorm, the question on the whiteboard — what might predict that a customer is about to leave? — is a business question first and a technical one only afterward. "People whose favorite restaurant left the platform." "People whose last two orders arrived late." Anyone who knows the customers can propose columns; turning the hunch into an exact, computable definition is then the data team's half of the trade.
The Leakage Guard, Applied
One discipline stands guard over the whole workshop. Topic 12 introduced leakage — a feature that smuggles the answer into the question — and every manufactured column must now re-face its test: will we actually know this at prediction time? The churn project's classic self-own is the feature "received a win-back offer". It correlates beautifully with churn in the historical data — because the team only started sending those offers to customers who already looked lost. At prediction time, for a fresh customer, the feature is either unknown or an echo of the model's own future output.
The guard is procedural, not clever: for each proposed feature, imagine the moment the model runs — next Monday, scoring customer 4711 — and ask whether that number would genuinely be on file at that moment. Features built from the past (orders, complaints, timestamps of things that already happened) pass. Features that quote the future, or quote the team's own reaction to the prediction, fail — however well they score in training. A feature that fails this test does not make the model better; it makes the test lie.
Deep Learning's Asterisk
One honest footnote before the tournament. In Chapter 8 you will meet models that learn their own features: show a neural network raw pixels or raw text, and its early layers manufacture the telling facts themselves — that is much of why deep learning conquered images and language. So does that retire the craft you just learned?
Not where most business ML lives. On tables like Plateful's — customers, orders, amounts, dates — human-crafted features still usually decide the game, and a modest model with sharp features routinely beats a fancy model with dull ones. The fair summary: on images, sound, and text, the network does the feature engineering; on business tables, people do. This chapter's churn model lives firmly in the second world.
- "The model finds everything in the raw data by itself." A classical model sees exactly the columns it is given, nothing more. A pattern that no feature expresses — like drift hiding inside plain timestamps — is invisible to it.
- "Feature engineering is just data cleaning." Cleaning fixes what is wrong with the data — duplicates, gaps, typos. Engineering creates new telling columns out of data that was already correct. Different work, both necessary.
- "Only data scientists can propose features." Feature ideas are really domain knowledge in another form — rain slows bikes, complaints precede churn. The best ones routinely come from the business side; the data team's half is making them exact.
- "What signals might predict this?" is now a brainstorm you can lead — your knowledge of the customers is literal model input, no code required.
- It explains where data-team weeks actually go between "we have the data" and "we have a model" — and why that gap is craft, not delay.
Knowledge Check
What is the difference between the raw column "order timestamp" and the feature "days since last order"?
- The feature required collecting new information from customers
- Same information, reshaped so it points at the question the model is asked
- The feature is more accurate than the raw timestamp
- The raw column is text while the feature is a number, which models require
Where do the best feature ideas for the churn model come from?
- Advanced mathematics that only data scientists know
- The model itself, which suggests features during training
- Domain sense — people who know the business saying what might predict the outcome
- Copying the feature list wholesale from another company's churn model and using it unchanged
Why must the feature "received a win-back offer" be rejected, even though it correlates strongly with churn in historical data?
- It fails the leakage test — it won't be honestly known at prediction time
- The correlation is too weak to be useful
- Models are not allowed to use marketing data
- Computing it for every customer would be far too expensive to run at the scale required
Where does deep learning change the feature-engineering story — and where doesn't it?
- Everywhere — neural networks make hand-crafted features obsolete
- Nowhere — deep learning also needs every single feature designed by hand, on images and text just like tables
- On images and text networks learn features; on business tables people still craft them
- Deep learning removes the need to check features for leakage
You got correct