Choosing features is one of the most practical skills in machine learning. The model can only learn from the signals you give it, so weak or misleading features can hurt even a strong algorithm.
Use this guide as a checklist when reviewing raw data before building a model.
The practical goal is to decide which signals deserve to be in the model and which ones should be removed, transformed, grouped, or reviewed more carefully.
Quick Answer
Choose machine learning features by checking whether each candidate feature is related to the target, available at prediction time, ethical to use, represented correctly, and supported by enough examples.
Then test whether the feature actually improves validation performance and works in the real prediction workflow.
Key Takeaways
- Good features must relate to the business objective.
- Features must be available when the model makes predictions.
- Avoid features that leak the answer.
- Numeric values should have meaningful magnitude before being treated as numbers.
- Rare categories may need grouping, hashing, or embeddings.
- Feature review should happen before training and again after evaluation.
- A feature can be technically predictive but still risky, unavailable, or inappropriate.
Feature Quality Checklist
| Check | Question |
|---|---|
| Relevance | Does the feature help explain the target? |
| Availability | Will this value exist at prediction time? |
| Legality | Are we allowed to collect and use it? |
| Ethics | Could this feature create unfair or sensitive outcomes? |
| Representation | Is the value encoded in a useful way? |
| Coverage | Do we have enough examples? |
| Stability | Will this feature behave similarly in production? |
| Evaluation | Does it improve the model metric? |
Feature Review Workflow
- Start with the prediction goal.
- List candidate raw fields from available data sources.
- Remove obvious leakage fields.
- Check whether each feature is available at prediction time.
- Review legal, privacy, fairness, and business concerns.
- Transform identifiers, dates, text, and categories into useful model inputs.
- Train a simple baseline model.
- Add features or feature groups one at a time.
- Compare validation metrics and error examples.
- Keep features that improve performance, trust, or operational clarity.
- Document why each important feature was kept, changed, or removed.
1. Is The Feature Related To The Objective?
Start with the target. If the goal is to predict taxi fare, features like distance, pickup location, dropoff location, time of day, and toll amount may be relevant.
Features that are not related to the prediction goal add noise. They can also make the model harder to explain and maintain.
Ask:
- Why might this feature affect the outcome?
- Would a domain expert expect it to matter?
- Does the data show a useful pattern?
- Does the model improve when the feature is added?
2. Is The Feature Available At Prediction Time?
This is one of the most important checks.
A feature is not useful if it is only known after the event you are trying to predict. That creates leakage.
Examples:
- Do not use final delivery time to predict delivery delay before delivery happens.
- Do not use post-purchase behavior to predict whether a customer will buy.
- Do not use resolved ticket category to predict support ticket routing.
If a value is delayed by hours or days, account for that delay in your training data.
3. Is It Legal And Ethical To Use?
Some data may be technically available but inappropriate to use.
Review:
- personal data,
- protected attributes,
- financial information,
- health information,
- employee records,
- sensitive location data,
- consent requirements.
Good feature engineering also includes deciding what not to use.
4. Does The Numeric Value Have Meaningful Magnitude?
Some values look numeric but should not be treated as real numbers.
Examples:
- ZIP code,
- customer ID,
- product ID,
- phone number,
- category code.
These values may be identifiers or labels. Treating them as numbers can mislead the model because the distance between two IDs is usually meaningless.
5. Do We Have Enough Examples?
Rare categories can be hard for a model to learn.
If a feature has thousands of unique categories with very few examples each, consider:
- grouping rare values into
Other, - bucketizing,
- hashing,
- embeddings,
- using higher-level categories,
- removing the feature if it does not help.
6. Does The Feature Survive Production?
Training data can look clean, while production data is messy.
Check:
- missing values,
- late-arriving data,
- changed category names,
- different formats,
- time zone issues,
- measurement drift,
- inconsistent source systems.
Features must work in the real prediction workflow.
How To Test Feature Value
A feature should earn its place in the model. A feature that sounds useful in a meeting may still add noise, create leakage, or make the model harder to operate.
Start with a baseline model using a small set of trusted features. Then add one feature group at a time and compare results on validation data. Do not judge the feature only by training performance. A feature that improves training accuracy but hurts validation performance may be teaching the model a pattern that does not generalize.
| Test | What to check |
|---|---|
| Validation metric | Does the feature improve the metric that matters? |
| Error review | Does it reduce real mistakes or only improve a number? |
| Segment performance | Does it help one group while hurting another? |
| Stability | Does the feature behave consistently across time periods? |
| Availability | Will it exist when the prediction is made? |
| Explainability | Can the team explain why the feature matters? |
| Operational cost | Is the feature worth the data pipeline effort? |
If a feature creates a small metric gain but requires a fragile pipeline, sensitive data, or unclear ownership, it may not be worth keeping.
Real-World Example
Imagine a team building a churn model for a SaaS product. At first, the dataset includes customer plan, number of users, login frequency, support ticket count, renewal date, account age, survey score, and cancellation reason.
Some of those fields are useful. Login frequency can show engagement. Support ticket count can show friction. Account age and plan type may explain different customer behavior.
But cancellation reason is a leakage feature if the model is supposed to predict churn before the customer leaves. Renewal outcome is also not valid if it is only known after the prediction point. A survey score may be useful, but only if it is collected before the prediction and has enough coverage across customers.
The team may also find that “number of support tickets” is too broad. One ticket about a password reset is not the same as five unresolved billing issues. A better feature might separate ticket volume, unresolved tickets, ticket severity, and days since last support interaction.
This is where feature review becomes practical. The team is not just asking, “Can we train a model?” It is asking, “Can we trust this signal in production, explain it later, and collect it consistently?”
Example Feature Review
| Candidate feature | Good? | Why |
|---|---|---|
| Trip distance | Yes | Related and numeric |
| Pickup hour | Yes | Captures time pattern |
| Final fare amount | No | This is the target |
| Driver ID | Maybe | Could overfit or create fairness issues |
| Customer phone number | No | Identifier and sensitive |
| Weather category | Maybe | Useful if available at prediction time |
Common Feature Review Mistakes
- Keeping fields that reveal the answer after the event.
- Treating IDs, ZIP codes, or category codes as normal numbers.
- Using sensitive attributes without a clear legal, ethical, and business review.
- Adding many rare categories without enough examples.
- Measuring improvement only on training data.
- Ignoring whether the feature can be produced reliably in production.
- Forgetting to document why features were removed or transformed.
Official Resources
- Google Machine Learning Crash Course: Numerical Data
- Google Machine Learning Crash Course: Categorical Data
- Google Machine Learning Crash Course: Feature Crosses
- scikit-learn Feature Selection
Related AI Charcha Reading
- Feature Engineering for Machine Learning
- Feature Engineering With Keras and BigQuery ML
- Vertex AI Feature Store Guide
- Data Quality and EDA for Machine Learning
- Model Evaluation, Generalization, and Sampling Guide
- Data Preprocessing Options for Enterprise ML
FAQ
What makes a machine learning feature good?
A good machine learning feature is relevant to the prediction goal, available at prediction time, represented correctly, ethically usable, and supported by enough training examples.
What is feature leakage?
Feature leakage happens when a model is trained with information that would not be available when the model makes a real prediction.
Bottom Line
Good feature selection is a disciplined review process. Choose features that are relevant, available at prediction time, ethical, stable, operationally reliable, and proven by evaluation.
The best features are not only predictive. They are also explainable, collectable, safe to use, and trustworthy enough to support real decisions.