Seven Store Clustering Mistakes That Survive Into Production
Clustering on demographics instead of demand, freezing clusters for a year, and building more clusters than your supply chain can execute. The failures that make a clustering project look wrong when the method was fine.
See how Ward detects store groups that stopped matching how they actually sell
Get a demo → Take the 3-minute assessmentContents
- Why a good method produces bad clusters
- 1. Clustering on attributes instead of on demand
- 2. Building more clusters than you can execute
- 3. One cluster set for every category
- 4. Clustering on a year that was not normal
- 5. Freezing clusters for a year
- 6. No manual override, or nothing but manual override
- 7. Never measuring whether it worked
- What a working scheme looks like
Why a good method produces bad clusters
Store clustering is not a hard technique. The algorithms are forty years old and any competent analyst can produce a defensible set of clusters in a week.
The failures are almost never in the method. They are in what got fed into it, how many clusters were kept, and what happened to them afterwards. Seven of them show up repeatedly.
1. Clustering on attributes instead of on demand
Square footage, region, urban or rural, median household income. All easy to get, all feel explanatory, all routinely wrong.
Two stores with identical demographics sell very different category mixes, because catchment behavior is shaped by things no attribute captures: the employer down the road, the school run, the competitor that opened last year, whether there is parking.
Do it the other way round. Cluster on category sales mix per store over a full year. Then use attributes to explain the clusters you found. If a cluster has no attribute explanation, that is interesting, not a problem.
2. Building more clusters than you can execute
The analysis says 14 clusters improve fit. The planning team can maintain four. You will end up with four real clusters and ten that quietly converge on the nearest big one.
The constraint is not analytical, it is operational: every cluster is a distinct assortment to plan, an allocation rule to maintain, and a set of planograms to build and issue.
Start with the number you can execute. Run it for two seasons. Add a cluster only when a specific category makes a documented case for it.
3. One cluster set for every category
This is where most single-scheme approaches break. The stores that group together for beverages are usually not the stores that group together for baby, or for seasonal, or for fresh.
A single chain-wide cluster set is simpler to administer and worse at every category individually.
The usual compromise. One primary cluster set for operations, space and labour, with category-specific overrides for the three or four categories where the difference is large enough to be worth the extra maintenance. Not all twenty.
See how Ward detects store groups that stopped matching how they actually sell
Get a demo →4. Clustering on a year that was not normal
A refit, a nearby road closure, a competitor opening or closing, a three-month supply failure in a category. Any of these will move a store into the wrong cluster and the cluster will look perfectly reasonable.
Before clustering, list the stores that had something happen. Either exclude the affected window or exclude the store and assign it manually. It takes an hour and it prevents a class of error nobody catches downstream.
5. Freezing clusters for a year
Clusters get built in a project, signed off, and then treated as reference data.
A remodel, a new competitor within two miles, a road layout change or a shift in catchment can all move a store out of its cluster within months. The store keeps receiving the assortment for a cluster it no longer belongs to.
The fix is not more frequent full re-clustering. It is a trigger. Any store with a remodel, a format change, or a sustained deviation from its cluster's sales pattern gets reviewed individually, immediately. Full re-clustering once a year is fine on top of that.
6. No manual override, or nothing but manual override
Both extremes fail. A scheme with no override cannot handle the airport store, the campus store or the one with a tourist season. A scheme where every store has been hand-adjusted is not a clustering scheme, it is 400 individual assortments with a clustering story attached.
Allow overrides, count them, and review them. If more than about 10 percent of stores are overridden, the clusters are wrong and the overrides are telling you how.
7. Never measuring whether it worked
The most common of the seven. Clusters get implemented and the question of whether they improved anything is never asked, because by then the project has closed.
Two measurements are worth running.
- Within-cluster versus between-cluster variance on the thing you clustered for. If stores inside a cluster differ from each other about as much as they differ from other clusters, the clusters carry no information.
- A held-out control group. Deliberately leave a matched set of stores on the old assortment for two seasons. Compare sales per square foot and markdown rate in the affected categories. Without a control, every result is confounded with the season.
What a working scheme looks like
Four to seven primary clusters, built on category sales mix rather than store attributes, with overrides on two or three categories where it pays. Under 10 percent of stores manually overridden. A trigger that forces individual review when a store changes. And a control group that proves the whole thing is worth the maintenance.
None of that is sophisticated. All of it is the part that gets skipped when clustering is treated as an analysis exercise rather than an operating process.
See how Ward detects store groups that stopped matching how they actually sell
Ward monitors your stores 24/7 and delivers insight cards, not dashboards. First cards in 48 hours.