A customer segmentation lands well in the first meeting — four clean clusters, sharp boundaries, confident slide. Then someone in marketing notices every "segment" responds identically to campaigns, and that the segment descriptions read like income slabs: under 20k, 20-45k, 45-80k, above 80k. Recency, frequency and every behavioural column seem to have had no say at all.
A distance-based method (k-means, hierarchical, k-NN style logic) run on raw,
unscaled features where one column lives on a much larger numeric scale than the
rest — monthly income or annual spend in rupees beside days, counts and ratios.
Common in first segmentation projects, RFM analyses, and any notebook where
StandardScaler was planned but never wired in. The same failure hides inside
PCA on raw features, where the big-unit column claims the first component.
Linked module: 1.9 (Unsupervised learning).
Euclidean distance sums squared differences per column, so a column spanning 90,000 units contributes millions to the sum while a column spanning 200 days contributes a few thousand. The big column does not dominate the distance — it IS the distance, and clustering on it alone is what actually happened. Confirm in two prints: per-cluster min/max of the suspect column (the bands will be nearly non-overlapping — a histogram wearing cluster labels), and the crosstab or profile of every other feature (their per-cluster means will barely differ, or differ only through their correlation with the big column). A third tell: rerun the clustering with the big column divided by 1,000 and watch every "segment" reshuffle — real structure does not care what unit you billed in.
Scale before any distance is computed: StandardScaler (or a robust scaler when
outliers are heavy) on every numeric feature, fitted inside the same pipeline
that clusters. Rerun, then audit what now drives the clusters: compare each
feature's per-cluster centres against its overall spread, and check the cluster
count evidence (elbow, silhouette) again on the scaled space — the right k often
changes once rupees stop voting alone. Finally re-present honestly: the old
deck's "segments" were income bands, and stakeholders should hear that plainly
before they see the new ones.
House rule: no distance-based method touches raw features — scaling lives inside the pipeline, never in a notebook cell someone can skip. Add a one-line audit to every clustering script: print each feature's per-cluster centre spread divided by its overall standard deviation; if one feature towers over the rest, say so in the deck. And run the unit test that costs nothing: change one column's unit and confirm the segments survive.
Q: "Your k-means on customer data produced segments that are exactly income bands. Why, and what do you change?" Strong answer: explain squared-distance dominance in one sentence (the largest-scale column owns the sum), name the confirming print (non-overlapping per-cluster min/max on that column), state the fix (scaler inside the pipeline, then re-evaluate k on the scaled space), and add the professional step — telling stakeholders the earlier segments were an artefact, before they build campaigns on them.