1. What is feature engineering?

Feature engineering is the process of converting raw business data into inputs that help a machine-learning model learn useful patterns.

Raw database values:

PolicyStartDate
ExpiryDate
CustomerCreatedDate
PolicyType
Claim transactions
Complaint transactions
Payment transactions

Engineered features:

PolicyAgeDays
DaysUntilExpiry
CustomerTenureMonths
PolicyTypeEncoded
ClaimsInLast12Months
ComplaintsInLast90Days
AveragePaymentDelayDays
PremiumIncreasePercent

Feature engineering combines:

• Business knowledge
• Data knowledge
• Statistical thinking
• ML requirements

A model does not automatically understand the business meaning of every SQL column.

2. Raw feature versus engineered feature

A raw feature is taken directly from the source.

PremiumAmount = 18,500

An engineered feature is calculated from one or more raw values.

PreviousPremiumAmount = 16,000
CurrentPremiumAmount  = 18,500

PremiumIncreasePercent
= ((18,500 - 16,000) / 16,000) × 100
= 15.625%

The percentage may be more informative than the current premium alone because it represents the customer’s price change.

3. Feature vector

Most traditional ML algorithms expect features as numbers collected into a feature vector.

A feature vector is an ordered numeric array representing one example:

CustomerAge                 = 42
PremiumAmountNormalized     = 0.37
ClaimCount                  = 2
ComplaintCount              = 1
PolicyType_Motor            = 1
PolicyType_Health           = 0
PolicyType_Life             = 0

Feature vector:

[42, 0.37, 2, 1, 1, 0, 0]

In ML.NET, this combined column is usually named:

Features

The label remains separate.

4. Numeric features

Numeric values may already appear model-friendly:

Age = 42
Claims = 2
Premium = 18,500

But their scales differ considerably.

ClaimCount:     0–10
CustomerAge:   18–100
Premium:    5,000–500,000

Large numeric values can dominate some algorithms.

Scaling or normalization transforms numeric features into comparable ranges.

Example min-max scaling:

Original premium:   ₹18,500
Minimum observed:    ₹5,000
Maximum observed:   ₹50,000
Normalized value:      0.30

Not every algorithm requires normalization equally, but creating a consistent pipeline is important.

Normalization values must be learned from training data only.

5. Categorical features

A categorical feature contains named categories

PolicyType = Motor
PolicyType = Health
PolicyType = Life

Assigning arbitrary numbers can be misleading:

Motor  = 1
Health = 2
Life   = 3

This may suggest:

Life > Health > Motor

even though no such numeric order exists.

A common solution is one-hot encoding.

PolicyType = Motor

PolicyType_Motor  = 1
PolicyType_Health = 0
PolicyType_Life   = 0

For Health:

PolicyType_Motor  = 0
PolicyType_Health = 1
PolicyType_Life   = 0

ML.NET can perform this conversion using OneHotEncoding.

6. Date and time features

Raw dates are rarely passed directly into traditional models.

Instead, derive business-relevant values.

From:

ExpiryDate = 30 September 2026
PredictionDate = 31 August 2026

Create:

DaysUntilExpiry = 30

From:

CustomerCreatedDate = 10 June 2020 
PredictionDate = 31 August 2026

Create:

CustomerTenureMonths = 74

Other possible date features:

• Day of week
• Month
• Quarter
• Days since last payment
• Days since last complaint
• Days since last login
• Number of renewals in the previous three years

Feature choice must reflect the business problem.

7. Aggregation features

Operational databases commonly store one-to-many relationships:

One Policy
   ├── Many claims
   ├── Many complaints
   ├── Many payments
   └── Many contact events

A model row normally needs summarized values:

ClaimCountLast12Months
ClaimAmountLast12Months
ComplaintCountLast90Days
AveragePaymentDelayDays
CallsAnsweredLast30Days

These are aggregation features because multiple transactional rows are summarized into one value.

8. Window features

A window defines the historical period used to calculate a feature.

Examples:

Claims in previous 12 months
Complaints in previous 90 days
Payment failures in previous 6 months
Website visits in previous 30 days

Different windows can reveal different behaviour:

LifetimeComplaintCount = 10
ComplaintsLast30Days    = 4

The second feature shows a recent increase that the lifetime count may hide.

9. Missing-value indicators

Sometimes missingness itself contains information.

Example:

LastLoginDate = NULL

Possible interpretations:

• Customer never used the portal.
• Tracking started recently.
• Data migration lost the value.
• Login happened through another system.

You might create:

HasPreviousLogin = 0
DaysSinceLastLogin = default approved value

Do not assume missing automatically means zero.

No claims = 0 claims
Unknown claim history ≠ 0 claims

10. Interaction features

An interaction feature combines two or more variables.

Examples:

ClaimsPerPolicyYear
ComplaintsPerClaim
PremiumPerFamilyMember
FailedPaymentsPerRenewal

For example:

ClaimCount = 6
PolicyAgeYears = 10
ClaimsPerPolicyYear = 0.6

This can be more meaningful than ClaimCount = 6 alone.

11. Point-in-time correctness

Every feature must use only information available at the prediction moment.

Suppose the prediction occurs 30 days before expiry:

PredictionMoment = ExpiryDate - 30 days

Valid:

Complaints recorded before PredictionMoment
Claims recorded before PredictionMoment
Payments recorded before PredictionMoment

Renewal receipt created after PredictionMoment
Retention call outcome recorded later
Payment made after the prediction
Final renewal status

This rule is called point-in-time correctness.

Without it, historical features may secretly contain future information.