One pooled model with shared coefficients or five per-product-line fits — how do you decide?

## Sharing is a regularizer, not a packaging choice The instinct is to treat 'one model or five' as an engineering decision. It is a modelling decision with a precise statistical meaning. Forcing five product lines to share one coefficient block constrains the hypothesis space: the fit is no longer allowed to say that price sensitivity differs between lines. Constraining the hypothesis space is exactly what a regularizer does. Full pooling is the strongest possible version of that constraint — an infinite penalty on any between-line difference — and five independent fits are the same penalty set to zero. Everything useful follows from seeing the dial. ## The two ends **Full pooling.** Every coefficient is estimated from all n rows, so the estimates are as stable as your data allows. If the lines genuinely share the relationship, this is strictly better than fitting them apart: same bias, less variance. If they do not, the shared coefficient is a compromise that is wrong for every line, worst for the line least like the others. **Complete separation.** Each line's fit is unbiased for that line's true relationship, and each is estimated from its own rows only. That is fine for the line with 400,000 rows and often catastrophic for the line with 900. The tell is a per-line coefficient table where one line's estimates have implausible signs and enormous standard errors — that line was borrowing strength from the others and you took it away. ## The middle, which is usually the answer Fit a single model on all lines with a shared coefficient block plus per-line deviation terms, and penalise only the deviations. A very large penalty collapses to full pooling; zero recovers separate fits; a tuned value lets each line depart from the shared block only as far as its own data justifies. Large lines, with plenty of evidence, pull away when they really differ. Small lines, with little evidence, are pinned near the shared block, which is precisely what you want for them. This is partial pooling, and it needs no special machinery — a shared block, line indicator terms and interactions, and one penalty strength chosen on validation. ## The facts that decide it **Volume, and especially skew.** Ask for rows per line before anything else. Roughly equal, large volumes make separation cheap. A long tail of tiny lines makes pooling nearly mandatory for the tail even if the head can stand alone. **Actual heterogeneity, measured.** Do not argue about whether the lines differ; test it. Add line-by-feature interactions for the features you suspect, penalise them, and see which survive and whether per-line validation error improves. Surviving, sizeable interactions are evidence of real difference. Interactions that shrink to nothing say the shared block was adequate and you keep the variance saving. **Cold start.** A sixth product line launches next quarter. Under a pooled model it has a working predictor on day one from the shared coefficients. Under five independent fits it has nothing until enough of its own data accumulates, and you end up hand-building a pooled fallback anyway — at which point you have the pooled model plus an exception. Cold start alone frequently decides the question. **Operational cost.** Five models are five retraining schedules, five monitoring dashboards, five drift alarms and five sets of feature-pipeline drift to keep aligned. That cost is real, recurring, and paid by a team, not by the validation metric. It should be weighed explicitly, not smuggled in. **Genuine incompatibility.** Sometimes separation is not a variance question at all. If two lines have different features available, different label definitions, or different regulatory constraints on what may enter a model, sharing coefficients is not a tradeoff — it is a category error. Say so and separate. ## The evaluation trap The most common way this decision goes wrong is measurement. A single metric on the pooled test set is dominated by the largest line, so a line the shared coefficients serve badly is invisible in the headline number, and the pooled model looks like a clean win right up until the small line's owner complains. Always report per line, and decide with the worst line in view, not the average. If you are choosing a penalty strength for partial pooling, tune it against a per-line summary — the worst line's error, or an average weighted towards the small lines — rather than the pooled mean. ## The organisational angle There is a second axis a lead has to own: who maintains what. Five models can mean five teams each free to iterate, which is sometimes worth real accuracy. One pooled model means one owner and one release, which is cheaper and slower to specialise. Do not let this axis silently drive the statistical decision, but do state it, because the team that inherits the choice lives with it far longer than the launch metric does.