Pooled vs Per-Asset Models on Panel Data

You have five years of daily data on 500 stocks and want to build a model predicting next month's return from a set of features. One option is to fit 500 separate models, one per stock, each trained only on that stock's own five years of history — about 1,250 rows each. Another option is to pool everything into one shared model trained on all 500 stocks at once, giving it roughly 625,000 rows to learn from. Same underlying data, two very different amounts of "training experience" per model, and a real trade-off between them.

The trade-off

A per-asset model can, in principle, capture whatever is genuinely idiosyncratic about a specific stock — its own particular sensitivity to a feature, quirks in how it reacts to earnings, a relationship that simply doesn't hold for other names. But with only a few years of data per stock, a per-asset model has very little to learn from, and flexible models (anything beyond a very simple one) will happily overfit that small sample, mistaking noise specific to that stock's short history for a genuine, stable pattern.

A pooled model trained across hundreds of stocks has vastly more data to estimate a stable, general relationship from — order of magnitudes more rows — which lets it use more flexible model classes (gradient-boosted trees, neural networks) without immediately overfitting. The cost is that it assumes the relationship between features and returns is roughly the same shape across all the pooled stocks; if a feature genuinely means something different for a mega-cap tech stock than for a small-cap industrial, a pooled model will find some compromise relationship that isn't quite right for either.

Worked example: a feature that means different things

Suppose a "days since last earnings surprise" feature predicts a modest positive drift for large, liquid stocks (post-earnings-announcement drift, well documented and fairly stable) but has almost no reliable relationship for small, illiquid stocks, where the same feature is swamped by idiosyncratic noise and thin trading. A per-asset model fit only on the small stock's own 1,250 rows might, by chance, still find some fitted relationship for this feature — because with enough features and little data, a flexible model can always find something that fits noise — and mistakenly treat it as real. A pooled model trained across the whole universe, by contrast, will correctly weight this feature's relationship toward what the bulk of the (more numerous, more informative) large-cap data shows, producing a more honest, better-calibrated estimate of the feature's true average effect, even though it may slightly under- or over-state the effect for any single stock.

The middle ground: pooling with asset-specific structure

Many production setups don't fully commit to either extreme. A common compromise pools data for the bulk of the model but adds asset- or group-level structure on top — a categorical "sector" feature the model can split on, per-asset intercepts (fixed effects) that shift a baseline prediction up or down for a specific stock without changing the shared relationship's shape, or hierarchical/partial-pooling schemes that let a stock's own data pull its estimate away from the pooled average only to the extent that stock actually has enough history to justify it.

Compare train and test error against model complexity above — a per-asset model with too little data per stock sits on the high-variance end of this curve; pooling more data is one of the standard ways to move a flexible model back toward the sweet spot.

What this means in practice

Pure per-asset models are rare in modern cross-sectional equity ML precisely because most individual stocks don't have enough history to reliably support a flexible model on their own; fully pooled models are the default starting point, with sector or size groupings and per-asset fixed effects added where there's genuine reason to think behavior differs systematically across groups.