Segments vs Populations: Why Your Segmentation Resets

A.What you are actually doing when you apply one

Apply a segment in most analytics tools and the tool takes the rows already in scope for that report and keeps the ones matching your condition. The result is correct and it is entirely local to that query.

Open a different report and you start again. The condition you wrote lives in the report you wrote it in, so a definition you care about, say enterprise accounts that have run a report in the last month, gets rebuilt by hand in every view where it matters, and the three rebuilds drift.

The definition is the valuable thing, and a segment gives it nowhere to live.

B.And it flattens as soon as the question has parts

The sharper limit is depth. A single condition can be made compound, so you can write something reasonably long, but you are writing it into one flat expression and reading it back later is unpleasant.

What you usually want is structurally different: a set of people, then a behaviour, then a qualifier on that behaviour. Those are three separate questions that happen to apply together, and expressing them as one string is why analytics segment builders end up looking like regular expressions.

A.Layer one: the population itself

A population is a filter over unique people. Define it once, by behaviour, and it becomes the set that other analysis runs inside rather than a condition you re-enter per report.

Because it resolves to people rather than sessions, membership means something durable: a person is in the set or they are not, on the strength of everything they have ever done, not on what happened in one visit.

B.Layer two: events, with AND and OR

Inside that set you then ask about events, and you can combine them. Did these people do A and B. Did they do A or B and not C. That is a genuinely different operation from narrowing the population, and keeping it separate is what makes it legible.

This is the layer most tools do have, and having it without the one above means every question restates the audience along with the behaviour.

C.Layer three: property WHERE clauses on those events

Then you qualify the events themselves. Not just purchased, but purchased where the plan was Growth, the source was paid social, and the order value was over some threshold.

Event properties are custom, so the qualifiers available are whatever you chose to record at the time. That is the point of putting the moment on the event rather than on the person, which is covered in people, events and properties.

A.Three that are awkward with one layer and direct with three

Which enterprise accounts that adopted the API have stopped using it. Population: enterprise, paid, over 90 days. Events: used the API historically, has not in 30 days. Properties: endpoint category.

Do paid-social customers behave differently from organic ones after month three. Population: acquired via paid social. Events: everything after day 90. Properties: whatever distinguishes the actions.

Of the people who read three or more articles before signing up, which topics did the ones who are still paying read. Population: still paying. Events: read blog post, at least three. Properties: the category on each read.

That last one is the loop this blog is measured by, and it is only expressible because the category rides on the event as a property.

B.Define membership by behaviour, not by attributes

Attribute-defined membership goes stale without telling you. Industry, company size and plan tier were true when they were written and may not be now, and nothing in the data marks the moment they stopped being accurate.

Behaviour-defined membership cannot go stale, because it is recomputed from events that are still arriving. Use attributes to slice a behavioural population, not to define one: enterprise accounts that stopped running reports is a population, enterprise accounts is a list.

C.Keep the set small, and the honest limits

The failure mode is proliferation: forty overlapping definitions, three of them some variant of active, nobody sure which is canonical. Most businesses need under ten, each with a name a salesperson would recognise.

Two limits worth stating. A population is only as good as the events underneath it, so this is downstream of instrumentation rather than a substitute for it. And composition makes it easy to build a query so specific it describes four people, which will feel like a finding and is not; check the size of the set before you read anything into what it does.

Kissmetrics keeps populations as a filter over unique people, with event conditions and property clauses layered inside, which is what makes the three questions above single queries rather than three exports and a spreadsheet. Related: segment to campaign and cohort analysis.