Compressing the customer

PCA hands back new axes called principal components, with three properties worth saying plainly:

• Each component is a DIRECTION through the original features - a weighted recipe: so much frequency, so much monetary, minus so much recency. Those recipe weights are the loadings, and reading them tells you what the axis means in business terms.
• Components are orthogonal - each new axis is at right angles to all previous ones, so no component repeats information another already captured.
• They arrive ordered by variance explained - PC1 carries the most spread, PC2 the most of what remains, and so on. Compression is just "keep the first few, drop the rest."

On our pile, read the PC1 loadings and a story appears: frequency and monetary point one way, recency points the other. PC1 is roughly an "engagement/value" direction - VIP regulars at one end, lapsed and one-time customers at the other. The axis you have been squinting at since session 3 had a meaning all along.

PCA chases variance - so whichever column has the biggest raw variance owns PC1. Sound familiar? It should: this is session 2's cents disaster wearing a different hat. scikit-learn's PCA automatically centers the data (subtracts each column's mean) but does NOT scale it. Centering is free; scaling is YOUR job, before fit.

Skip it on our pile and the monetary column - thousands of cents against tens of days and orders - dwarfs everything. PC1 becomes "basically the cents column", the variance table declares near-total victory for one component, and the beautiful 2D picture is a picture of a unit choice. Scale first (z-scores, session 2), and the three features compete fairly for the components.

Worth saying once, clearly: PCA is fully unsupervised. It never sees cluster labels, planted truth, or business meaning - it sees a cloud of scaled numbers and chases spread. When our five segments come out visibly separate on PC1/PC2, that is not PCA being clever about segments; it is the segments being different ENOUGH, in the scaled features, that the directions of biggest spread happen to run between them. If segments ever looked well-mixed in a PCA view, that would not prove they are fake - it would only mean their differences live in the directions PCA threw away. One more reason the variance receipt matters: it tells you how much room "hidden in the discarded 14%" actually has.

Compression earns its place three ways:

• Before clustering: fewer, decorrelated dimensions. Distance-based algorithms like k-means behave better when redundant, correlated columns are not double-counting the same behavior - PCA hands you axes with the redundancy squeezed out.
• Visualization: what we have been doing all course. High-dimensional pile, two-dimensional screen; PCA picks the least-lossy flat view.
• Noise reduction: the last components often carry measurement jitter rather than structure. Dropping them can clean the signal - compression as a filter.

How many components to keep? The working rule of thumb: keep components until the cumulative variance explained is enough for your purpose. On our pile PC1+PC2 = 86% - comfortably enough to see five segments, as the lab will show.

And the price, stated honestly: we left 14% of the story on the floor - real differences between customers that the flat picture cannot show. And we traded interpretability: a principal component is a MIX of features, not a feature. "Days since last order" is a column you can point at; "a weighted blend of F and M minus some R" needs a paragraph. Compression is a purchase, and the variance table is the receipt.

"Enough" cumulative variance is a purpose question, not a universal threshold. For a projector slide meant to show rough structure, a lower share can serve; for feeding a clustering pipeline whose output ships to marketing, you want the receipt high enough that you can defend what was discarded. Two habits transfer to any dataset: first, always look at how the percentages DECAY - a steep drop after a few components means the data is internally redundant and compresses gracefully, while a flat, even spread means every component carries real story and compression will be bloody. Second, say the discarded share out loud in reviews ("this view drops 14% of the variance") - the sentence costs nothing and inoculates the room against treating the picture as the whole truth.

None of this is folklore - it comes from the sources closest to the tools:

• t-SNE cluster SIZES are meaningless. The algorithm equalizes density, so a huge diffuse group and a tiny tight one can render as similar-sized islands. Distill's "How to Use t-SNE Effectively" demonstrates this interactively.
• t-SNE inter-cluster DISTANCES may mean nothing. Two islands far apart in the plot are not necessarily far apart in reality - same Distill source, same interactive proof.
• Low perplexity makes pure noise look clustered. Turn the perplexity knob down and random uniform points sprout convincing clumps - the algorithm's most dangerous party trick, and session 9's theme in miniature.
• UMAP's own FAQ blesses clustering on UMAP output only "yes, with care" - and the care is specific: use a density-based method like HDBSCAN, NOT k-means, because UMAP does not preserve density. When a tool's own authors put a warning label on a use case, the warning is the documentation.

The working rule, on one line: PCA to compress and feed algorithms; t-SNE/UMAP to LOOK; never read embedding distances or sizes as facts.

After all those warnings, the honest counterweight: for LOOKING at genuinely high-dimensional data - text embeddings, image features, hundreds of behavioral columns - nonlinear embeddings routinely reveal neighborhood structure that PCA's flat shadow smears together. The pros' posture is not "never use t-SNE"; it is "use it to generate hypotheses, then verify every hypothesis in the original features." The plot is the question, never the answer. StatQuest's t-SNE and UMAP videos are a gentle next step if you want the mechanics.