How do you choose an encoding for a 40,000-level seller ID that must be refreshed and served daily?

## Why this is a judgment question Every candidate encoding on a 40,000-level identifier will produce a working model. The differences that decide it are mostly not accuracy differences; they are differences in how much machinery the organisation has to carry, forever, on every retrain and every scoring path. A lead is expected to reason about that explicitly rather than reaching for whichever encoding scored best in one experiment. ## Axis 1 — does level identity carry signal at all? Before choosing an encoding, establish that the column deserves one. Check the count distribution: if 90% of rows come from 300 sellers, the honest feature set is one encoding for the head and a shared bucket for the tail, and the argument about sophisticated encodings evaporates. Check stability across time: if the sellers driving today's traffic barely overlap with last quarter's, any per-level statistic is stale by construction and identity-based features will decay between retrains. And check whether the signal is really about the seller or about attributes you already have — category, tenure, price band, shipping region. An encoding of the identifier that merely reconstructs features already in the table is pure operational cost. ## Axis 2 — what can the model consume? A gradient-boosted tree ensemble is happy with one or two dense columns per identifier — a count and a smoothed target mean — and will carve them up non-monotonically. A linear model needs either a wide sparse representation or a supervised encoding that is already close to monotone in the log-odds. A wide linear or factorisation-style model on web-scale data is the natural home for hashed sparse features. The encoding decision is not independent of the model family, and changing model family later is a reason to revisit it. ## Axis 3 — what state can the serving path carry? This is where most of the real cost lives. - **Stateless (hashing).** A pure function. Nothing to store, nothing to version, nothing to drift, new sellers handled on first sight. Pay in interpretability. - **Frozen mapping (counts, target means, rare bucket).** A table from level to number, built on the training window, shipped as an artefact with the model, loaded at scoring time. Manageable — but it is now a second thing that must be versioned, deployed atomically with the model, and refreshed on a defined cadence. A mapping refreshed independently of the model is a slow-motion train-serve skew: the model was fitted against one set of encoded values and now sees another. - **Point-in-time correctness.** When you rebuild the mapping for a retrain, it must be built from data available *before* the labels being predicted, or the feature quietly encodes the future. This is easy to get wrong when someone regenerates a historical training table with today's aggregates. Also budget for the tail of the mapping. Forty thousand entries is trivial; forty million is a serving dependency with a latency and memory story of its own, and that is when a rare-level bucket or hashing stops being a modelling nicety and becomes an infrastructure requirement. ## Axis 4 — who must explain the feature? A target-encoded seller feature is a label-derived statistic. In a regulated or audited setting, that invites questions: what exactly is this number, could it act as a proxy for a protected characteristic, what happens to a seller with no history. A hashed bucket is worse — the feature is not even invertible. Count encodings and rare buckets are the easiest to defend, because they are simple functions of observable volume. If the model faces external review, weight this heavily; if it is an internal ranking model, weight it lightly. ## A defensible sequence 1. **Baseline.** Count or frequency encoding, plus a rare bucket for the long tail. No labels, no folds, small mapping. Measure it. 2. **Escalate deliberately.** Add out-of-fold, smoothed target encoding, keeping the count alongside it so the model knows how much evidence backs each mean. Measure on a clean, time-forward holdout — not on the cross-validation the encoding was tuned against. 3. **Keep only what pays.** If the lift is within noise, ship the baseline; you have just saved the team a permanent maintenance burden. If the lift is real and material, ship it *with* the fold discipline documented and the mapping refresh wired into the retrain. 4. **Choose hashing instead** when levels are unbounded or streaming, or when the serving path genuinely cannot hold a mapping. ## What to monitor once it is live The share of scoring traffic hitting the unknown or rare bucket is the single best health metric: a rising line means the level population is turning over faster than the refresh cadence, and it will show up as decay before any accuracy metric does. Watch the distribution of the encoded values against the training distribution, the age of the mapping artefact, and the count of levels in the mapping over time. Fix the refresh cadence to the retrain cadence, and make the pair deploy atomically. ## The answer that fails "Target encoding, because it wins on the leaderboard." It may well win. The question is whether the organisation can keep it correct across every retrain, every backfill and every new consumer of the feature store — and whether anyone will be able to explain it when asked.