Is age a synthetic feature?

It can be, when calculated from a birth date and a reference date. The reference date must be defined.

Can a model create features automatically?

Yes. Representation learning and automated feature engineering can construct transformations, although their suitability still needs evaluation.

Should the original inputs be removed?

Not automatically. Keeping both original and derived inputs may help some models, while other methods need care with redundancy.

AI Glossary / AI and machine learning / Beginner

Synthetic feature

Definition

A synthetic feature is a model input constructed from other available inputs. It expresses a relationship, transformation or summary that was not supplied as a separate field in the original data.

What it means

A dataset might contain an order value and the number of items purchased. Dividing one by the other creates average value per item. That new quantity is a synthetic feature, even though every number used to calculate it came from ordinary records.

The word synthetic does not necessarily mean fictional. This term differs from synthetic data, where entire observations may be generated. A derived feature can describe a real transaction using a deliberately chosen calculation.

The purpose is to make a useful pattern easier for a model to use. Some algorithms learn complicated interactions themselves; others benefit from relationships expressed explicitly. A feature can also make an input easier for analysts to explain.

Creating more features is not automatically helpful. Irrelevant transformations add maintenance work, and features that use unavailable future information can produce misleadingly strong evaluation results.

How it works

The team starts with a prediction question and identifies a relationship worth representing. Possible operations include ratios, differences, logarithms, counts over a time window and combinations of categorical fields.

The calculation needs precise rules. A ratio must define what happens when its denominator is zero. A recent-activity count must specify its window boundaries and which timestamps it uses. Missing inputs require an explicit treatment rather than an accidental software default.

The feature is then calculated consistently for training and live prediction. Any quantities learned from data, such as normalization statistics, should be fitted using the training portion of an evaluation split. Under the cited Google glossary convention, normalization or scaling alone does not count as creating a synthetic feature.

Finally, the team tests whether the feature improves the desired outcome. It should examine performance across relevant groups and periods, not simply celebrate an improvement on the same examples used to invent the feature.

Three practical examples

Inventory planning: days since the last delivery turns two dates into an interpretable recency feature.
Customer support: requests per active user combines a request count with account size, helping distinguish volume from intensity of use.
Property analysis: floor area per room combines two measurements, potentially expressing a different pattern from either measurement alone.

Think of it this way

Think of preparing a recipe ingredient by mixing two ingredients already on the counter. The mixture may be more useful for the next step, but it does not create new underlying information from nowhere.

The analogy has a limit. A mathematical transformation can make existing information easier for a particular model to exploit without adding new facts. Its value depends on the learner and the task, not just on whether the calculation looks sensible to a person.

Worked example

Separating account size from support intensity

Suppose an invented dataset contains account A with 120 requests and 60 active users, and account B with 80 requests and ten active users. By raw request count, A is larger.

Requests per active user gives 120 / 60 = 2 for A and 80 / 10 = 8 for B. The derived feature highlights a different distinction: B has more requests relative to its active-user population.

Neither view is inherently correct for every decision. Staffing may depend on total requests, while investigating product difficulty may benefit from the ratio. The team may retain both features if evaluation supports that choice.

It must also define the observation period consistently. Dividing a monthly request count by a daily active-user count without explanation creates an ambiguous measure. These figures are teaching values, not a finding about actual customers.

Illustrative case study

A fictional subscription business creates a feature called future engagement by counting activity during the month after a prediction date. It appears highly useful for predicting renewal during that same month.

An operational review discovers that the feature cannot exist when the prediction is needed. The team replaces it with activity observed before the decision time, records the exact window and evaluates the revised model on later accounts.

The lesson is that feature engineering must respect information availability. A plausible name and a strong historical correlation do not make a feature suitable for deployment.

Common misconceptions and mistakes

Synthetic features are fabricated records. A synthetic feature can be a deterministic calculation from real measurements.
More derived columns mean a better model. Redundant or unstable features may increase overfitting and operational complexity.
A useful feature must establish causation. Predictive features can be associative, but they must still be available and appropriate for the decision.

Business use

Synthetic features can translate business knowledge into inputs a model can use. They are especially useful when ratios, durations or interactions express the operational question more clearly than raw fields.

Maintain a short definition for each important feature, including units, timing, missing-value rules and ownership. Compare the improved model against a baseline without the feature. The added accuracy should justify the extra data dependencies and maintenance burden.

Check your understanding

Two accounts have different total request counts. One has a much higher requests-per-user ratio. Which should receive more support staff?

Answer: The ratio alone cannot decide. Staffing depends on total workload, request duration and service targets. The feature highlights intensity, not the complete resource requirement.

Related terms

Learn next

Read feature engineering and data leakage. Choose one proposed ratio or time-window feature and document its units, boundary cases and availability at prediction time before testing it.

Sources

Google, Machine Learning Glossary, synthetic feature: https://developers.google.com/machine-learning/glossary#synthetic_feature. Core terminology consulted. Derived-account examples and evaluation questions are original teaching material.

Previous: Synthetic data Next: Synthetic measure