The Aggregation Level Is a Modeling Decision

Aggregation is never neutral.

A team rolls SKUs into product families because the SKU-level forecast is noisy. A planner rolls stores into regions because the model is too large. Finance rolls weeks into quarters because that is how the business review works. Engineering rolls customer demand into a single horizon total because it is easier to sample and faster to optimize.

Sometimes that is exactly the right move. Aggregation can reduce noise, improve runtime, simplify explanations, and make a decision system easier to operate.

Sometimes aggregation destroys the decision.

The problem is not aggregation itself. The problem is using aggregation as a technical convenience without asking which operational tradeoffs disappear when the data is rolled up.

Aggregate the state only if the decision allows it

The right aggregation level depends on the decision being made.

If the decision is how much total inventory to buy for a product family over a quarter, then family-quarter demand may be a reasonable input. If the decision is how to allocate that inventory across stores by week, family-quarter demand is not enough. The sequence and location of demand matter.

If the decision is whether to open a vendor order event, vendor-level aggregation may be useful because MOQ constraints operate at the vendor level. If the decision is which SKUs to include in that order, SKU-level economics still matter. If the decision is how to schedule production, product-family demand may hide changeover constraints, packaging rules, or material availability.

Aggregation should follow the decision structure. Do not aggregate first and then hope the decision still exists afterward.

What gets lost

Aggregation usually removes variance, timing, location, substitution, and constraint detail.

Rolling daily demand into weekly demand removes the order of events. That may be harmless for a slow-moving replenishment decision with weekly review. It may be fatal for a product with a weekend spike, a short shelf life, or a promotion that depletes inventory before the next receipt arrives.

Rolling SKU demand into family demand removes mix. That may be fine for upstream capacity planning if products are truly interchangeable. It is not fine when pack sizes, margins, shelf lives, vendor MOQs, or substitution behavior differ by SKU.

Rolling store demand into region demand removes spatial imbalance. That may be fine for high-level inventory budgeting. It is not fine when inventory cannot be moved quickly between stores or when one location stocks out while another sits on excess.

Aggregation is a lossy compression of the decision state. The question is whether the lost information matters for the action.

Forecast aggregation versus decision aggregation

Forecasting and decision making do not have to use the same level of aggregation.

A forecast may be more accurate at an aggregate level, but the decision may need disaggregate recommendations. A SKU-store forecast may be noisy, but the replenishment action still happens at SKU-store level. A family-level forecast can stabilize the total, while a disaggregation model allocates that total across SKUs and stores using recent sales, availability, seasonality, and operational constraints.

The reverse can also be true. A forecast may exist at a detailed level, but the decision may be aggregated because execution is aggregated. If a supplier only accepts vendor-family purchase orders, optimizing every SKU independently may be fake precision.

The useful design separates forecasting granularity from decision granularity. The model should ask: where is the uncertainty best estimated, and where is the action actually taken?

Those are related questions. They are not the same question.

A simple policy example

Suppose the business must decide how many units to buy from a vendor across a four-week horizon.

An aggregated decision might be:

[ X_v = \text{total units ordered from vendor } v ]

A more detailed decision might be:

[ x_{i,t} = \text{units ordered for SKU } i \text{ arriving in week } t ]

The aggregated model may be faster and easier to solve. It may also be sufficient if all SKUs have similar margins, pack sizes, lead times, and substitutability.

But if SKU margins differ, if some SKUs are seasonal, if one SKU is constrained by a case pack, or if demand timing affects stockouts, then (X_v) is not the real decision. It is only a budget of units that still needs to be converted into operational actions.

This is where many planning systems fail. They optimize an aggregate number and then use a heuristic to split it. The heuristic ends up making the actual decision. The optimizer gets credit for a decision it did not really make.

Uncertainty changes under aggregation

Aggregating demand changes the uncertainty distribution.

Demand for individual SKUs may be intermittent and skewed. Aggregated demand across many SKUs may look smoother. That smoothness can be useful, but it can also hide tail risk. If products are correlated because of promotions, weather, macroeconomic factors, or shared customers, aggregation may not reduce risk as much as expected.

The same applies to lead times and supply disruptions. If many SKUs depend on the same vendor, their supply risk is correlated. Aggregating demand while ignoring shared supply risk can create a model that looks stable and performs badly during disruptions.

A practical model should preserve the dependencies that affect the decision. If aggregate uncertainty is used, the system should still understand how aggregate outcomes map back to disaggregate constraints and actions.

Constraints decide the useful level

Constraints often reveal the right aggregation level.

If the constraint is a vendor MOQ, vendor aggregation matters. If the constraint is a truckload, lane aggregation matters. If the constraint is shelf space, store-SKU aggregation matters. If the constraint is cash, portfolio aggregation matters. If the constraint is expiration, batch and time aggregation matter.

The model should not aggregate below the level where a binding constraint operates. If a cold-storage capacity constraint is location-specific, a regional aggregate inventory number cannot enforce it. If a supplier minimum applies across a group, independent SKU models cannot see the shared threshold.

This is a simple diagnostic: list the constraints that can bind, then ask what level of detail is required to enforce them.

Metrics to track

When testing aggregation, do not only compare forecast accuracy or runtime.

Track decision value, infeasible downstream splits, stockout concentration, excess inventory concentration, allocation error, constraint violations after disaggregation, planner override rate, runtime saved, and explanation quality. Also compare aggregate recommendations to the decisions that are actually executed.

A model that improves forecast accuracy but creates worse allocation is not better. A model that solves quickly but hands the real decision to a fragile postprocessor is not better. A model that hides service failures inside an aggregate average is not better.

Aggregation earns its place only if the resulting decision is still economically sound.

Failure modes

The first failure mode is aggregating because the detailed model is hard. That may be necessary, but it should be acknowledged as an approximation, not sold as a principle.

The second failure mode is optimizing an aggregate decision and then pretending the disaggregation heuristic is harmless. The heuristic is often where the real decision happens.

The third failure mode is measuring only aggregate outcomes. Regional service may look good while individual stores fail. Family inventory may look balanced while the wrong SKUs are available.

The fourth failure mode is ignoring correlation. Aggregation does not eliminate shared risks.

The fifth failure mode is letting organizational reporting levels dictate modeling levels. Finance may review quarters. Customers buy on days. Suppliers ship on calendars. Warehouses receive by appointment. The model has to respect the operational clock.

What to do in practice

Choose aggregation by starting with the action, not the table.

Write down the exact decision to be made, the timing of that decision, the constraints that can bind, and the information available when the decision is made. Then decide which details can be safely compressed. Test the aggregated policy against a disaggregate simulator whenever possible.

Aggregation is powerful when it removes noise that does not affect the action. It is dangerous when it removes the action itself.

The level of aggregation is not a database preference. It is part of the model.