Feature engineering and preprocessing · insight-1125

Treat a feature's time-to-live as a modelling choice, since it decides which training rows receive nulls

Situation
A feature store applies a time-to-live to a feature view, and training sets are built with point-in-time joins over entities with irregular update gaps.
Action
Choose the TTL from the age after which the value stops predicting, measure the null rate it creates per segment, and use the same TTL in the offline join and online serving.
Reason
The point-in-time join scans backward from each row's timestamp only up to the TTL, so the TTL directly sets the missingness pattern the model learns.
Boundary
Feast-style feature views with infrequently updated aggregates and slowly changing attributes.

Symptom or risk

A TTL that is too short nulls many rows in training and serving; one that is too long supplies stale values that were never usable fresh.

Static features that never expire.

Longer TTLs raise coverage at the price of staleness; the right value differs by feature and segment.

Setting the TTL for training convenience while the online path applies a different freshness limit.

Feast point-in-time joins scan backward from each entity row's timestamp up to the feature view's time-to-live.
Point-in-time joins (Feast documentation)