Clustering

For a long time, deciding how to split users was something people did by hand. Teams carved the base up by signup date, plan, or company size, then sent a different message to each slice.

The trouble was that those dividing lines came out of what everyone already believed. When Mia at Pagedeck asked how people were actually using the product, she got as many answers as there were people in the room. Ravi split the base by acquisition channel, Sofia split it by contract size, and Theo split it by login frequency. None of those cuts was wrong, but each one started from the answer someone wanted to confirm and sliced the data to fit it, so nothing anybody didn't already suspect ever surfaced.

Clustering reverses the order of the cut. Nobody fixes the criteria first. The records are left to fall together by similarity, and only afterwards does a person read what the resulting groups have in common. Run Pagedeck's 50,000 accounts through it using nothing but usage patterns and the teams that only write meeting notes separate from the teams that only write proposals — a line nobody drew in advance. Letting a machine find structure in data that carries no answer key is called unsupervised learning, and clustering is the most widely used task within it.

It runs in five steps: decide what counts as one record, turn that record into numbers, put the numbers on a common scale, pick a method and a number of groups, then read the groups that come out.

1. Decide what a single point is. Whether one point means one account, one user, or one document changes the story the result tells. If Pagedeck is reworking its pricing, the account is the point, because the account is the thing that pays.
2. Turn that point into a set of numbers. The machine never sees the account itself — it sees features, the individual input values pulled out of the records. Four or five numbers stand in for the whole account: documents created per day, people invited, share of documents that got a comment, share of documents started from a template.
3. Put the values on a common scale. If documents per day runs from 0 to 50 while invited members runs from 0 to 300, the larger number dominates the distance calculation by itself. Squeezing each value into the range 0 to 1 is what lets all four count equally.
4. Pick a method and a number of groups, then run it. The most common approach places a center point for each group and repeatedly reassigns every point to its nearest center — and how many groups to look for is a number a person supplies. Run it for three, four, five, and six groups and compare.
5. Read the groups and name them. The machine only calls them group 1 and group 2. Noticing that the accounts in group 1 create several documents a day but almost never invite anyone, and deciding to call them solo users, is work only a person does.

Steps 3 through 5 rarely finish on the first pass. When a group refuses to make sense, change the number of groups; if it still refuses, go back to step 2 and swap the features out.

Clustering belongs in the moments when you don't yet know what you're looking for. Investigating churn without knowing what types of users even exist, or having to set pricing tiers with no evidence about where the breaks should fall, are both that kind of moment. It's a tool for producing questions rather than confirming answers.

It has three limits. First, there is no answer key, so there is no way to score the result as right or wrong. Ask for four groups on a given dataset and you get four; ask for seven and you get seven. Which of the two is real is not something the machine will tell you.

Second, the features you supply decide the entire outcome. Feed it session time and document count and it will separate heavy users from light users, which is something you knew before running anything. Getting something new out of it means supplying values nobody has put side by side before.

Third, groups separating cleanly doesn't make the split useful. If no different action suggests itself for each group, the whole exercise ends as a nice-looking picture. That's why many teams write down one sentence before they start: what will we do differently once the groups come out.

"I clustered the 50,000 accounts and they fall into four groups. The teams that only write meeting notes are the biggest one."

The types came out of usage records rather than a boundary somebody chose.

"This should be classification, not clustering. We already know what answers we're looking for."

When the categories exist in advance, clustering isn't the right task.

"We got seven groups and three of them don't explain anything. Let's look at the features again."

When the output can't be read, suspect the input rather than the method.

Pagedeck ran one the quarter it decided to rework pricing. Mia asked Theo to do it and four groups came back: accounts creating documents daily but rarely inviting anyone, accounts with plenty of invited members but only a handful of documents, accounts reusing one template over and over, and accounts that fit nowhere. The second group stood out. Lots of people had been let in and nobody was writing anything, and those accounts turned out to account for half the next quarter's cancellations.

Why that was happening only came out after Sofia called eight of them. They were teams where the decision to adopt came from above and nobody had ever shown anyone how to use the product. All clustering did was decide which accounts to call.

The most common mistake is reading the groups that come out as a customer split you can use as-is. A line drawn by numbers rather than by a person looks more trustworthy. But the line the machine drew is only the result of pulling nearby points together in the space of the values it was given, and whether that grouping means anything commercially is a separate question entirely. Skip past that and you end up giving each group a plausible name, sending each one a different email, and seeing exactly the response you saw before. Segmentation, the work of dividing a market into groups that behave alike, can use a clustering result as raw material — but raw material is not the finished split.

The other frequent mistake is believing the machine decides how many groups there are. It's described as finding structure without an answer key, so it sounds like the count would come free, but most widely used methods only run once a person supplies that number. Take the first run at face value and you write "this product has five user types" into a document when the honest sentence is "we asked for five groups and got five."