Master

Feature engineering

The interesting finding is usually a derived value that was not in the data: a rate, a duration, a flag, a bucket. Good features turn a question into a column you can group by, which is why the best analysis work is spent here rather than on models.

What you will see

'under a month' - the boundary is stated in the code so a reader can change it deliberately rather than discover it by accident.

About 2 min of reading

Quick check

Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.

Try It

Build a duration feature and test it.

1

Duration between two dates

from datetime import date d0, d1 = date(2026, 3, 4), date(2026, 4, 1) days = (d1 - d0).days print(days)

Before you run it, say out loud what it will print. Then open the answer.

What it prints
28 - and note it is exact because both are date objects, not strings.
2

Bucket with a stated meaning

band = 'under a month' if days < 30 else 'a month or more' print(band)

Before you run it, say out loud what it will print. Then open the answer.

What it prints
'under a month' - the boundary is stated in the code so a reader can change it deliberately rather than discover it by accident.

Put it in order

Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.

Data Flow

Raw columns combine into a signal.
1 Write the question as a sentence
↓
2 Design the column that answers it
↓
3 Compute it from data at or before the event
↓
4 Test it on known cases
Line by line

Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.

from datetime import date sets nothing on screen
d0, d1 = date(2026, 3, 4), date(2026, 4, 1) sets nothing on screen
days = (d1 - d0).days sets nothing on screen
print(days) 28 - and note it is exact because both are date objects, not strings.
Why this works
Leakage

A feature computed with information from after the event being predicted is a leak, and it makes a model look excellent on history and poor on new data. Compute every feature from data available at or before the event, and check the ordering explicitly.

Fewer, better features

Twenty weak features hide one strong one and make every later step slower to reason about. Write down the three features you think carry the signal and check whether they answer the question before adding more.

Examples

Turn a question into a column

'Did this customer return?' becomes a boolean column. 'How long between orders?' becomes a number. Once the question is a column, the answer is a group and a mean, which you already know how to compute.

Bucket with intent

Bucket ages or sizes only when the buckets mean something, like age bands a policy already uses. Buckets invented to make a chart look nice move the conclusion, and the same data with different edges gives a different story.

Test a feature before trusting it

A new feature is a claim. Check it on cases you already know the answer for: a known duration, a known rate, a known flag. A feature that is wrong on a known case is wrong everywhere.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← A reproducible analysis pipeline
Previous Lesson
A reproducible analysis pipeline
Next Lesson
Writing the report
Writing the report →