How this track works
Ten sessions, one running case: Lumen Skincare's checkout data - 40,000 sessions, a 3.2% conversion rate, and a pile of raw columns. The intro-ML course trained a model on it; the model-evaluation course judged the result. This course owns what sits between them: turning columns into features, and not fooling yourself while you do it. b2-b4 build the craft (numeric transforms, encoding, datetime), b5 is the leakage session everything else defends against, b6-b8 go deeper (interactions, missing data, selection), b9 bridges to embeddings, and b10 ships a written feature spec you can hand to a colleague.
The model does not see your table 7 min live
Google's glossary is precise: feature engineering is "the process of determining which features might be useful in training a model, and then creating those features from raw data." The key word is creating. Your model never sees channel = "email" or a timestamp - it sees a vector of floating-point numbers. Everything else is a translation you perform, and every translation is a decision about what the model is allowed to notice.
LiveWhy "just throw the columns in" fails4 min▶
Three concrete failures, all of them common, all of them fixed in this course:
- Strings-as-integers. Google's crash course puts it perfectly: if you index categories and hand them over raw, "the model would treat the indexed values as continuous floating-point numbers. The model would then consider 'purple' six times more likely than 'orange.'" That is not a subtle bias - it is arithmetic on nonsense (b3).
- Buried signal. A
signup_dateholds tenure, weekday, seasonality, recency. As a timestamp it holds none of them, as far as a linear model is concerned (b4). - Invisible relationships. Spend matters more for returning customers than new ones. No single column carries that; the interaction has to be built (b6).
Where practitioners actually spend the time. Google's crash course states it flatly: "ML practitioners spend far more time evaluating, cleaning, and transforming data than building models." The model-selection debate that eats a planning meeting is usually worth less than one afternoon of feature work - and this course exists because the afternoon is the part nobody teaches.
Self-studyGoogle's feature rules, condensed3 min read▶
From "Rules of Machine Learning" - the ones that shape this whole track:
- Rule 17: "Start with directly observed and reported features as opposed to learned features." Hand-crafted first; the embeddings bridge comes in b9, not before.
- Rule 19: "Use very specific features when you can." Specific beats clever.
- Rule 20: "Combine and modify existing features to create new features in human-understandable ways" - discretization and crosses, which are b2 and b6.
- Rule 21: "The number of feature weights you can learn in a linear model is roughly proportional to the amount of data you have." More columns is not free (b8).
- Rule 22: "Clean up features you are no longer using." Feature debt is real debt.
Five groups, one ladder 6 min live
Everything you will build in the next nine sessions falls into five groups, and tonight's workbench turns them on one at a time so you can watch each one earn its lift. The point is not the numbers - it is that the numbers move at all while the algorithm sits perfectly still.
| Group | What it does to the table | Session |
|---|---|---|
| Raw numerics | Take the numbers as-is, then decide how to scale, bin, or tame their shape | b2 |
| Encoding | Turn categories into numbers a model can hold without inventing an order | b3 |
| Datetime | Break a timestamp into the things it actually means: tenure, weekday, recency | b4 |
| Interactions | Build the relationships between columns that no single column carries | b6 |
| Selection | Remove what is noise, which is a feature decision too | b8 |
LiveThe sixth toggle, and why it is different4 min▶
Tonight's workbench has a sixth lever, drawn with a dashed border: target leakage. It is not a feature group - it is the failure mode this entire course is arranged to prevent, and you will press it deliberately in a moment.
sklearn's own documentation defines the problem exactly: "Data leakage occurs when information that would not be available at prediction time is used when building the model. This results in overly optimistic performance estimates... and thus poorer performance when the model is used on actually novel data."
Read the middle clause twice. Leakage does not announce itself with an error. It announces itself with a better score - which is why it survives code review, demo day, and the launch meeting, and only fails once it is somebody's production system.
Self-studyWhat a held-out set is protecting you from3 min read▶
Every score in this course comes in a pair - training and held-out - and the workbench deliberately hides the held-out number until you press a button. That friction is on purpose. The pattern to internalize:
- Training score answers "did the model fit what it saw?" It is always available, always flattering, and never sufficient.
- Held-out score answers "will this work on rows it has never met?" It is the only one connected to production.
- The gap between them is the diagnostic: a small gap means honest work; a sudden large gap means you have taught the model something it will not have when it matters.
The intro-ML course made this split; this course will try, repeatedly, to break it on purpose so you recognize the shape when it happens by accident.
Climb the ladder ★ 14 min · everyone runs it
Below is a real logistic regression, trained by gradient descent in your browser on 1,800 Lumen sessions and scored on 1,200 it never saw. Start with every lever off, then switch on one group at a time and press Score on held-out after each. The algorithm never changes. Only the columns do.
All levers off: 0.500. No features, no model - a coin flip. Everything above this line is something you build, not something the algorithm finds.
+ Raw numerics: 0.696. Spend and pages viewed carry real signal - and they were already sitting in the table, costing nothing but the decision to use them.
+ Encoding: 0.785. The single biggest jump on the ladder, and it comes from columns the model previously could not read at all (b3).
+ Datetime: 0.806. Tenure and weekend were inside signup_date the whole time, invisible until decomposed (b4).
+ Interactions: 0.812. Spend-times-returning is a relationship no column holds alone (b6).
+ Selection: 0.813. Dropping the noise column barely moves the score - and that is the lesson: selection buys simplicity and stability more than accuracy (b8).
Now break it on purpose ★ 8 min · everyone runs it
With all five honest levers on, switch on target leakage and read the training score first. Then press Score on held-out. This is the most important thirty seconds of the course.
Training AUC jumps to 0.967. In a normal week this is the moment you message the team. The feature is post_purchase_flag, and it was sitting right there in the warehouse.
Press Score on held-out: 0.789. A gap of 0.179 - and look closer, it is BELOW the 0.813 you had before adding it. The leak did not just fail to help; it made the model worse.
Understand the mechanism: post_purchase_flag is written after the sale. In your historical table it is filled in. At prediction time - the moment that actually matters - it is empty. The workbench scores held-out rows the way production would, so the column arrives blank and the model's best feature evaporates.
Say the rule out loud: a feature is only a feature if it exists before the thing you are predicting.
sklearn documents this with a number that should scare you. In their own worked example on completely random data with no signal at all, running feature selection before the train/test split produced 0.76 accuracy. Done honestly, the same pipeline scored 0.50 - and 0.43 under cross-validation. Leakage manufactured 26 points of accuracy out of pure noise. If a result looks too good, this is the first thing to check, not the last.
Try it yourself - this week ◐ 20-30 min total
- Run every lever combination on the workbench until you can predict which ones move the held-out score and roughly how much. Note which single group buys the most lift.
- Take a table you actually work with and sort its columns into the five groups. Anything that fits none of them is either an identifier, a leak, or a feature waiting to be invented - label which.
- For one column, write down what the model literally receives today. If the answer is "a string" or "a timestamp," you have found this week's win.
- The leakage audit, five minutes: for each column, ask "was this value knowable before the outcome happened?" Bring the suspicious ones to b5.
Official sources covered
This track teaches the working core of the canonical feature-engineering sources - sklearn's preprocessing, pitfalls, and selection guides, Google's crash-course data modules and Rules of ML, and Kaggle Learn's feature-engineering course - with a live workbench on the key pages. Certificates and graded exercises stay with the official providers (linked each session). This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Why can you not hand a model the column channel = "email" as an integer index?
Google's crash course says it exactly: the model "would then consider 'purple' six times more likely than 'orange.'" The index imposes an order and a magnitude that the categories never had. Encoding (b3) is how you avoid inventing that arithmetic.
2 · The leakage lever pushed training AUC to 0.967 and held-out AUC to 0.789. What made the held-out score collapse?
This is the production failure in miniature. sklearn's definition names it precisely: information "that would not be available at prediction time." The historical table has the column filled in; the live request does not.
3 · On the ladder, the algorithm never changed. What does that demonstrate?
That is the thesis of the whole course. Same estimator, same rows, same split - every point of improvement came from translating raw columns into things the model could actually use.