Clusters built from store attributes group stores that look alike, and the range decision depends on stores that sell alike, which is a different thing. Cluster on within-category demand share vectors instead, per category rather than once for the chain, since the grouping that works for beer is wrong for baby food. Fisher and Rajaram built exactly this in Marketing Science in 2000 to pick test stores. The cluster count is set by execution capacity rather than by a statistic: the space team can build a fixed number of planograms a season, and that number is your k. Re-cut on a planned cadence with a membership stability constraint, because every re-cut destroys the comparables the plan is built on.
Four hundred stores sit in twelve clusters. The clusters were built from a grid: three trading regions crossed with four size bands. Every category uses them, because they came down from a project five years ago and nobody has had a reason to rebuild them.
Then look at what the category managers actually do. The beers and wines manager keeps a list of thirty stores she treats as an exception, because they sit near universities and the cluster puts them with everything else in their region and size band. The babycare manager has a different list of forty. The pet manager ignores the clusters entirely and ranges by store, which takes her three weeks every season and produces a plan nobody can review.
Those exception lists are the evidence. When three categories each maintain a separate override on top of one shared cluster set, the shared set is not carrying the decision it was built to carry. It groups stores that resemble each other, when the range decision depends on stores that buy the same way.
What the clusters need to predict
Start from the decision the cluster exists to make. In practice it is one of three: which lines a store carries, how many facings each line gets, and what a store's forecast should look like before its own history is trusted. All of those are about the shape of demand across items inside a category, expressed as shares.
That gives you the feature vector directly. For each store, take unit sales by item within one category over a full year, divide by the store's category total, and you have a vector of shares that sums to one. Two stores are similar when those vectors are close, regardless of whether one turns over four times the volume of the other.
The normalisation is the part people skip, and it is what separates a demand cluster from a size cluster. Cluster on raw units and the dominant axis of variation is store volume, so you rediscover your size bands with extra steps. Cluster on shares and volume drops out, leaving the composition differences that actually drive a range decision.
Two adjustments make the shares usable. Deflate any item-store week where the item was unavailable, since a zero caused by an empty shelf reads as a taste preference and will pull a store into the wrong group. And treat items launched partway through the year separately or exclude them, because a store that got a launch in March and a store that got it in September will look different for reasons that have nothing to do with their shoppers.
Fisher and Rajaram built a clustering method on this logic in Marketing Science in 2000, for the problem of choosing which stores to use in a fashion test. Their grouping came from sales pattern similarity rather than from store descriptors, and the test stores were then drawn to represent each group. The application differs from range planning and the underlying claim is the same one: stores that sold alike historically will respond alike next time, and store attributes are a weak proxy for that.
One cluster set per category
The instinct to have a single set of clusters is strong, since one set is easier to govern and to explain to the board. It is also why the exception lists exist.
Demographic structure moves categories in different directions. A store in a dense city centre skews toward small pack sizes across most of the shop, and it also skews toward premium in coffee and value in household cleaning, which no single grouping captures. A store with a large car park and a big trolley shop skews the other way on pack size and differently again on category mix.
Run the clustering per category and you get clusters that mean something inside that category, plus a useful by-product. Compare the memberships across categories and you can see which categories genuinely need their own grouping and which land on nearly the same partition. In most chains a handful of categories are strongly idiosyncratic, a larger set collapses onto two or three common patterns, and the ones that collapse can share a cluster set without loss.
Mantrala and colleagues set out the assortment planning problem in the Journal of Retailing in 2009 and were direct about why it stays hard, including the interaction between localisation and the tractability of the decision. The practical reading is that per-category clustering buys accuracy at the cost of governance effort, and the governance effort is real: twenty categories with their own clusters is twenty conversations at range review rather than one.
How many clusters, and who decides
The statistical answer and the operational answer disagree, and the operational one wins.
The statistics give you a range. Silhouette width, from Rousseeuw in 1987, measures how well each store sits in its assigned group against the next nearest one. The gap statistic, from Tibshirani, Walther and Hastie in 2001, compares your within-cluster dispersion against what you would see under a null with no structure. Both usually indicate that more clusters keep helping, with diminishing returns, and neither knows anything about what it costs to run them.
The cost is concrete and lives outside planning. Each cluster in a category needs its own planogram, and someone has to build it, review it, and get it executed in store. A space team that can produce a certain number of planograms per category per season has set your k, and that number is typically small, between three and six for most categories in a chain of a few hundred stores. Distribution constrains it too, since a line that ranges in one cluster of thirty stores has to clear a minimum order quantity from the supplier and turn fast enough at the depot to avoid ageing.
So the sequence runs: ask what the space team can build, then use the statistics to check whether that number is defensible. If silhouette width collapses between four and five clusters, five is buying you nothing and four is the answer. If it is still climbing steeply at six and you can only execute four, you have a documented case for either more planogram capacity or a small exception list on top of four clusters, which is the honest version of what the category managers were doing informally.
One test is worth more than either statistic. Hold out the most recent quarter, assign each store its cluster centroid share vector as a forecast of its item mix, and measure the error against what the store actually sold. Compare that against the same test using the chain average and using the store's own history. If the cluster centroid does not beat the chain average by a clear margin, the clustering is not earning its keep, and if the store's own history beats the centroid everywhere, you have enough data to plan by store in that category and do not need clusters at all.
What clustering buys on the forecast
The forecasting argument is separate from the range argument and often larger.
At store-item-week level most of a supermarket range is intermittent. An item selling forty units a week across two hundred stores averages a fifth of a unit per store per week, so the individual series is mostly zeros with occasional ones, and any method fitted directly to it is fitting noise. Those series want a count method built for intermittency rather than a smoothed average.
Clusters give you a middle level. Aggregate the item to cluster level, where a fifth of a unit per store across a cluster of forty stores becomes eight units a week, which is a series with actual signal in it. Forecast there, then disaggregate to stores using each store's share within the cluster, smoothed over a long window. The cluster level absorbs the noise and the share allocation carries the store difference.
That structure creates the usual consistency problem, since the store forecasts have to sum to the cluster forecast and the cluster forecasts to the chain. Reconciliation methods exist for exactly this, and the minimum trace approach from Wickramasuriya, Athanasopoulos and Hyndman in the Journal of the American Statistical Association in 2019 sets the current standard for combining levels rather than picking one and splitting it. The relevant point for cluster design is that the reconciliation works better when the middle level is a real grouping. Clusters formed on demand share give the middle level coherent series. Clusters formed on square footage give you an aggregate of unrelated things, which reconciles arithmetically and helps nothing.
Re-cutting without breaking the plan
Clusters drift. Catchments change, a competitor opens, a store gets refurbished, and after three years a meaningful share of stores are in the wrong group.
The cost of fixing it sits downstream, in everything that assumed the old grouping. Last year's cluster-level actuals no longer correspond to this year's clusters, so the comparables that the buy is built on are broken. The planograms have to be rebuilt for any cluster whose composition changed enough to shift the ranking of items. Any target or bonus set at cluster level has to be restated.
Three practices keep that manageable.
Re-cut on a fixed cadence, ahead of the range review. Annually for fast-moving categories, every two years elsewhere, with the date known in advance so history can be restated in one pass rather than argued about mid-season.
Warm start from the existing assignment and constrain movement. Initialise the algorithm at the current clusters and add a penalty for reassignment, so a store only moves when the evidence is strong. A cluster set that reshuffles a third of the estate every year is telling you the features are unstable, usually because the window is too short or unavailability has not been corrected out.
Restate history on the new clusters before anyone plans on them. Recompute the last two years of cluster-level sales using the new memberships, so the comparison the buyer makes is like for like. This is a few hours of work and it prevents an entire season of arguments about whether a cluster grew.
Stores that keep moving between clusters deserve inspection rather than reassignment. Usually they are mixed catchments sitting near a boundary in the feature space, and they make good candidates for a small managed exception list.
Where this stops
Clustering compresses store differences into a small number of profiles, and the compression discards something real. In a chain of four hundred stores there are usually a handful that are not like anything: a flagship, a transit location, a store on the edge of a tourist area with a season that inverts twice a year. Forcing them into the nearest cluster gives them a range that fits nobody, and the correct treatment is to plan them individually and accept the cost. Deciding how many such stores you can afford to hand-plan is a resourcing question rather than an analytical one, and the number in most chains is smaller than the number of stores that want the privilege.
The method also needs a year of clean store-item history to work from, which rules out newly opened stores and stores that changed size materially. Those have to be assigned by judgement or by their nearest analogue until they have traded a full cycle, and a new store assigned to the wrong cluster carries that error through its first year of ordering.
There is a ceiling on all of this, set by whether store-level demand differences are large enough to matter in your categories. In some categories they are, and localised ranges move a visible share of category sales. In others the mix is close to uniform across the estate and the clustering exercise produces four groups that all want nearly the same range. The holdout test described earlier tells you which case you are in, and running it before the project is a better use of a week than running it after.
Take one category with clear regional variation, build the store share vectors for a year, cluster them, and put the resulting groups side by side with the exception list the category manager already maintains by hand. The overlap will tell you within an afternoon whether this is worth doing across the range.
More on this in retail on the DemandLabs platform.
