Feature Engineering

By this point in the glossary, you know how to clean messy data (Data Preprocessing) and put numeric values on a fair, comparable scale (Normalization). Both of those are about making existing data usable. This article is about something different and, in many real projects, more powerful: actively creating new pieces of information that weren’t sitting there in the raw data to begin with. That practice is called feature engineering.

The simple definition

Feature engineering is the process of creating new, more useful features from raw data, using domain knowledge and creativity — rather than just using whatever variables happened to arrive in the original dataset. This idea was first mentioned briefly back in the Feature article; this is its full, dedicated treatment.

Turning raw facts into useful signals

Suppose a delivery record contains:

distance = 12 km
travel_time = 30 minutes
order_time = 2026-08-25 18:30

Feature engineering can create:

average_speed = 12 / 0.5 = 24 km/h
order_hour = 18
is_evening = true
day_of_week = Tuesday

The new features expose relationships that may be easier for a model to learn.

A house-price example

Raw fields:

construction_year = 2016
current_year = 2026
latitude and longitude

Engineered features:

building_age = 2026 - 2016 = 10 years
distance_to_metro = 0.8 km
neighborhood_price_average = ₹7,200 per sq ft

The transformation must use information available at prediction time. A neighborhood average calculated using future sales would leak future information.

Feature-engineering flow

flowchart LR
    A[Raw fields] --> B[Domain knowledge and transformations]
    B --> C[Candidate features]
    C --> D[Train and validate model]
    D --> E[Keep useful, safe, stable features]

Common techniques

• Extracting date components
• Combining values into ratios or rates
• Grouping rare categories carefully
• Measuring distance between locations
• Creating counts over valid historical windows
• Encoding cyclical time such as hour or month
• Transforming skewed numerical values

Production risks

• Leakage: A feature contains future or target information.
• Training-serving skew: Production calculates the feature differently.
• Staleness: A stored feature is not updated when needed.
• Proxy bias: A feature indirectly reveals a sensitive property.
• Complexity: Hundreds of fragile features become difficult to maintain.

Modern Deep Learning can learn many representations automatically, especially for text, images, and audio. Feature engineering still matters for structured business data and for the surrounding system: selecting context, creating metadata, measuring recency, and ensuring only legitimate information reaches the model.

Why raw data often isn’t enough on its own

Raw data frequently contains the ingredients for a genuinely useful signal, but not the signal itself, laid out directly. Recall the example from the Feature article: a dataset might record a house’s construction date and its sale date separately, as two raw fields.

Neither one, on its own, is as directly useful as a single derived value — “age of the house at time of sale” — which is a far more direct predictor of price than either raw date alone. That derived value doesn’t exist in the raw data; an engineer has to actively build it. That act of building is feature engineering.

ANALOGY vs. TECHNICAL REALITY

Analogy: Think of a chef given a box of raw ingredients — flour, eggs, sugar, butter — none of which is, by itself, a cake. Feature engineering is like combining and transforming those raw ingredients into something new and more useful: not just listing “flour” and “eggs” separately, but actually baking them into the finished, far more valuable form.

Where this breaks down: A chef relies on intuition and taste, refined through experience. Feature engineering, while it does draw on genuine domain expertise, is ultimately judged by a much more objective standard: does adding this new feature actually improve the model’s measured performance on validation data (from the Validation Data article)? An engineer can propose a creative new feature based on good intuition, but it only earns a place in the final model if it demonstrably helps — intuition proposes, but validation data disposes.

Common feature engineering techniques

There isn’t one fixed recipe, but a few patterns come up constantly across real projects:

• Combining existing features. Creating “age of house at sale” from two raw dates, as above. Creating “debt-to-income ratio” from separate debt and income fields in a credit-scoring dataset — a single derived number that’s often far more predictive than either raw field alone.
• Extracting structure from a single feature. Pulling “day of the week” or “is this a holiday” out of a raw timestamp — information that was technically present in the original date but not directly usable by a model until it’s extracted into its own explicit feature.
• Binning continuous values into categories. Converting a raw numeric age into ranges like “18–25,” “26–40,” “41–60,” which can sometimes reveal a clearer pattern than the raw number, particularly for relationships that aren’t smoothly linear.
• Creating interaction features. Multiplying or combining two features together to capture a relationship that neither one reflects alone — for instance, “square footage per bedroom” can be more informative for predicting house price than square footage and bedroom count considered separately.

flowchart LR
    A[Raw feature: construction date] --> C[Derived feature: house age at sale]
    B[Raw feature: sale date] --> C
    C --> D[Fed into model training]

A concrete example, layered

For the hospital readmission model used throughout this glossary, raw data might include a patient’s admission date and discharge date separately. A simple derived feature — “length of stay” — is often one of the single most predictive features for readmission risk, despite not existing as its own field in the raw records. A more advanced engineered feature might combine number of prior hospital visits with time since the last visit into a single “recent utilization” score, capturing a pattern that neither raw number reflects clearly on its own.

Why this remains a meaningful skill even in the era of deep learning

It’s worth addressing directly, since this is exactly the kind of thing a beginner might reasonably wonder about: doesn’t Deep Learning — the family of techniques behind large language models — largely automate feature engineering away, by learning its own internal representations directly from raw data?

To a real and significant extent, yes — this is genuinely one of deep learning’s major advantages, and it’s part of why it has become so dominant for tasks like image recognition and language, where hand-engineering useful features by hand would be extremely difficult. But feature engineering hasn’t disappeared from the field; it’s simply shifted to where it’s still needed most.

Most real-world business applications of Machine Learning — fraud detection, credit scoring, churn prediction, and similar tasks working with structured, tabular data — still rely heavily on algorithms like decision trees and gradient-boosted models, where thoughtful, hand-crafted features often still meaningfully outperform raw, unprocessed inputs. Feature engineering remains a core, practical skill for exactly this large and common category of real-world ML work, even as deep learning has taken over other domains.

Key terms

• Feature engineering: Creating model inputs from available data.
• Derived feature: A value calculated from other fields.
• Feature store: A system for managing reusable production features.
• Training-serving skew: Different feature behavior during training and inference.
• Temporal leakage: Using information that would not have existed at prediction time.

Check your understanding

Is a complicated feature automatically useful? No. It must improve representative validation results and remain legitimate and maintainable.

Can an accurately calculated feature still leak information? Yes. It may use future data or the answer itself.

Common misconception

Beginners sometimes assume that the “smarter” or more advanced the algorithm, the less feature engineering matters — that a good-enough algorithm can compensate for weak features. In practice, the opposite is often closer to the truth for many real projects: a well-chosen set of engineered features fed into a relatively simple algorithm frequently outperforms a highly sophisticated algorithm fed nothing but raw, unprocessed data. This is a genuinely common lesson learned the hard way by engineers early in their careers — the phrase “better features beat better algorithms” is a well-worn piece of practical ML wisdom for exactly this reason.

Feature stores and consistent calculations

A feature store helps teams define, version, and reuse features. Its difficult job is consistency: the historical feature used during training and the live feature used during inference must mean the same thing and use only information available at that moment.

Raw fields are recorded facts. Engineered features are transformed inputs chosen for a task. Learned representations are produced inside a trained network for each input. Model parameters are the reusable learned numbers that create those representations.

Where this fits in what comes next

Feature engineering completes the picture of preparing existing data — cleaning it (Data Preprocessing), scaling it (Normalization), and now actively enriching it (feature engineering). The next two articles, Annotation and Labeling, shift focus to the other half of a training example — how the correct answers themselves, first introduced conceptually back in the Ground Truth article, actually get created and attached to raw data in practice.

In one sentence

Feature engineering is the deliberate craft of turning raw data into smarter, more informative signals a model can actually learn from — and it remains, for a huge share of real-world ML work, one of the highest-leverage skills an engineer can bring to a project.

Related Terms

• Feature
• Data Preprocessing
• Normalization
• Validation Data
• Model