Thirty columns that are really about four things
Open a process export and you will find thirty measurements side by side. Look closer and most of them move together: three thermocouples on the same furnace, two pressure taps on the same line, a flow rate and the pump speed that drives it. Reading them one at a time is not just slow — it double-counts. If two columns measure the same thing, that thing gets a vote twice.
What principal components do. They build new axes as weighted mixtures of your columns, chosen so the first captures as much of the variation as possible, the second captures as much of what is left as possible, and so on — with every axis independent of the others. Usually a handful of axes cover most of the variation, and the rest is measurement noise. Thirty columns turn out to be about four things.
How to read a loading. A loading is the correlation between an original variable and a component. The variables with large loadings are what the component is; name it after them. If the three furnace thermocouples all load heavily on the first component, that component is "furnace heat" and you have just learned that your thirty columns contain one temperature, not three.
⚠️ The mistake that quietly ruins everything. Scaling. If temperature runs around 750 and a ratio runs around 0.5, then without standardising, temperature's variance is thousands of times larger and the first component becomes, almost exactly, temperature. The output looks completely reasonable — a component explaining 98% of the variance — and it has taught you nothing except which column has the biggest numbers. Standardise unless every column is genuinely in the same unit. SenSight defaults to this and warns you when you turn it off.
Clustering asks a different question. Not "which columns go together" but "which rows go together". Do the batches fall into natural families? The honest catch is that k-means always returns exactly k clusters, even in pure random noise — it partitions whatever you give it. So the number that matters is not the cluster list, it is the silhouette score: how much tighter each group is than its distance to the nearest other group. Above about 0.5, the structure is real. Below about 0.25, you have drawn lines through a single cloud.
Discriminant analysis runs it backwards. Here you already know the groups — pass and fail, supplier A and supplier B — and you want to know whether the measurements can tell them apart, and which measurements do the work. The trap is scoring the model on the same rows you fitted it with: it has seen every answer, so it flatters itself. Cross-validation refits the model without each row and then classifies that row, which is the honest number. And even that must be read against the baseline: if 90% of your rows are "pass", a model that always says "pass" is 90% accurate and completely useless.
What principal components do. They build new axes as weighted mixtures of your columns, chosen so the first captures as much of the variation as possible, the second captures as much of what is left as possible, and so on — with every axis independent of the others. Usually a handful of axes cover most of the variation, and the rest is measurement noise. Thirty columns turn out to be about four things.
How to read a loading. A loading is the correlation between an original variable and a component. The variables with large loadings are what the component is; name it after them. If the three furnace thermocouples all load heavily on the first component, that component is "furnace heat" and you have just learned that your thirty columns contain one temperature, not three.
⚠️ The mistake that quietly ruins everything. Scaling. If temperature runs around 750 and a ratio runs around 0.5, then without standardising, temperature's variance is thousands of times larger and the first component becomes, almost exactly, temperature. The output looks completely reasonable — a component explaining 98% of the variance — and it has taught you nothing except which column has the biggest numbers. Standardise unless every column is genuinely in the same unit. SenSight defaults to this and warns you when you turn it off.
Clustering asks a different question. Not "which columns go together" but "which rows go together". Do the batches fall into natural families? The honest catch is that k-means always returns exactly k clusters, even in pure random noise — it partitions whatever you give it. So the number that matters is not the cluster list, it is the silhouette score: how much tighter each group is than its distance to the nearest other group. Above about 0.5, the structure is real. Below about 0.25, you have drawn lines through a single cloud.
Discriminant analysis runs it backwards. Here you already know the groups — pass and fail, supplier A and supplier B — and you want to know whether the measurements can tell them apart, and which measurements do the work. The trap is scoring the model on the same rows you fitted it with: it has seen every answer, so it flatters itself. Cross-validation refits the model without each row and then classifies that row, which is the honest number. And even that must be read against the baseline: if 90% of your rows are "pass", a model that always says "pass" is 90% accurate and completely useless.
Try it in the app
Try: Analysis → Multivariate. Run PCA on six or more numeric columns, then turn standardising off and run it again — watch the first component collapse onto whichever column has the largest numbers.