Good representation can beat more tuning
Feature engineering translates domain history into variables a model can use. On tabular problems it can matter more than fine-grained hyperparameter search, but only when the feature respects prediction time and is computed identically in production. Begin with a raw-field baseline so each addition has measurable value.
Time-window aggregates
Counts, sums, and means over prior 7-, 30-, or 90-day windows summarize behavior. Close each window strictly before the row's prediction cutoff and define how late events are handled.
Recency and frequency
Measure elapsed time since a valid prior event and event rate over a stated exposure period. Define behavior for no prior event, and distinguish zero activity from missing history.
Ratios and baselines
Divide a value by a meaningful peer or historical baseline, with explicit rules for zero and missing denominators. Build the baseline only from information available before the decision.
Categorical interactions
Pairs such as tier × region encode a domain hypothesis that additive models may miss. Limit cardinality, provide an unknown path, and validate the interaction rather than generating every possible combination.
Cross-entity rollups
Organization, household, or device history can add context, but the target row and future peers must not contribute to their own feature. Use point-in-time as-of joins and keep entity boundaries consistent with validation.
Attach a time-legality proof to every feature
Record source tables, keys, event time, cutoff, lookback, late-arrival policy, and null behavior. State why the value existed at prediction time and add boundary tests. A column in today's warehouse may have arrived after yesterday's decision.
Use the same fitted implementation for training and serving
Fit target encoders, vocabularies, imputers, scalers, and frequency tables only on training folds. Use out-of-fold target-derived values and a documented unseen-category fallback. Package the transformations in the same pipeline or shared feature code used at inference.
Ablate every addition
Add related features in groups and remove them to measure repeatable lift across folds. Include missingness, drift, latency, compute cost, and new-entity behavior. Version definitions and keep offline-online parity fixtures. A feature is ready when semantics, availability, and implementation agree—not when a notebook cell looks clever.