Understanding Segments

Open a Downloads report and it shows every download, everywhere, from everyone. But the person who asked for it did not want every download. They wanted downloads in North America, and the report just handed them Europe and Asia too. An hour later a different question arrives: a browser engineer needs to know whether Safari renders the checkout correctly and holds its cookies, so the only data that matters is Safari data, and the report is showing all of it. By the afternoon the mobile app team wants their app's numbers alone, cleanly separated from the website.

Three people, three slices, one pile of data. Not one of them needed all of it. Almost nobody ever does.

You already know how to do this

Faced with too much of anything, a person narrows. Reach for an encyclopedia to research the geography of North Africa and you do not read it cover to cover. You open the geography volume, turn to Africa, then to the northern region, and start there. You never touch the entries on art or politics, because they cannot answer the question in front of you. The narrowing is so automatic it barely registers as a decision.

Analytics is that same move, at scale. A single day of traffic is far too much to read. So you narrow, on purpose, until what is left can actually answer something. Adobe Analytics has a name for the instrument that does the narrowing. It calls it a segment. It is the second instrument this phase puts in your hands: the calculated metric defined a number of your own, and the segment defines the slice of people it describes.

Why not just call it a filter

Because a filter, in the everyday sense, is a much smaller thing than a segment actually is, and the distance between the two is the whole point of this module.

Picture a spreadsheet, forty columns wide and tens of thousands of rows deep. To make sense of it you apply a filter, and every row that does not match is hidden from view. It works. But look closely at what you are holding. That filter lives in that one sheet. It hides rows; it never creates anything. Close the file and it is gone. You cannot hand it to a colleague, cannot drop it onto a different report, cannot reuse it next month without building it from scratch again. A filter is an action you perform on data, and when it is finished it leaves nothing behind.

A segment is a filter that became a thing

English already knows the difference. A film uses a segment of a song, never a filter of a song. A market has segments, distinct parts with an identity of their own. The word segment names a real piece that exists on its own; the word filter names something you do to something else. Adobe chose the right word on purpose.

An Adobe segment is a saved object. It has a name. It carries its own definition. You build it once and then apply it to any report you own, hand it to a colleague, stack it on top of another segment, and come back to it in six months without rebuilding a thing. Where a spreadsheet filter hides rows and then evaporates, a segment defines a slice and stays. That shift, from an action into an object, is what turns segmentation into an engineering tool rather than a convenience, and it is why the people who live in reporting spend a real part of every week building, sharing, and refining them.

That is not only a point about vocabulary. It is a test you can run on any segment before building it, and it catches more bad definitions than any amount of care inside the builder.

The habit is worth keeping because it survives this page. It applies to a segment nobody has written about yet, in a product this site does not cover, which is the difference between learning a feature and learning how to think about one.

And it carries a scope, because this is journey data

Here is where a segment stops resembling a spreadsheet filter at all. A spreadsheet is a flat grid of rows. Adobe Analytics data is not flat. It is a journey: individual actions grouped into sessions, and sessions grouped under the person who made them. A hit sits inside a visit, and a visit sits inside a visitor. If those distinctions are new, a visit is a session, a run of hits that ends after thirty minutes of inactivity, and a visitor is a unique cookie or device rather than a guaranteed person; both are defined in Key Terminology.

Because the data is layered this way, a segment cannot simply say "downloads whose file name contains pdf" and stop. It has to declare how wide a net to cast. Should it return only the exact hits where a download happened? The whole visit that contained one? Everything that visitor ever did, across every session they have, because they downloaded a single time? Each choice hands back a different and larger set of data, and each answers a genuinely different question. Adobe calls this choice the container, and it comes in three sizes that match the three layers of the journey: Hit, Visit, and Visitor.

That one choice governs what a segment gives back, and getting it wrong is the most common way a segment returns a confident, well-formatted, wrong answer. It carries enough weight to have earned its own section, Segment Containers.

Not a new idea, and not a side feature

Segmentation is not a recent addition bolted onto reporting. It predates the interface most analysts use today. Before Analysis Workspace existed, serious analysis in Adobe happened inside a standalone desktop application called Discover, later renamed Ad Hoc Analysis, and segmentation sat at the center of it. When Adobe consolidated its analysis tools, Ad Hoc Analysis reached end of life on March 1, 2021, and its segmentation moved into Analysis Workspace, where it lives now. The tool around segments changed completely. The importance of segments did not move an inch.

That is worth holding onto, because it explains why so much of what follows exists. Segments are not a reporting garnish. They are how a practitioner turns a wall of collected data into the specific question a stakeholder actually asked, and doing that well is a daily craft, not a one-time setup.

The one choice that shapes every segment

So the mental model to carry forward is small and sharp. A segment is not a filter that hides rows. It is a named, saved, reusable object that defines a slice of journey data and travels wherever you send it. And before it can define anything, it has to answer one question first: how wide does it reach? A single hit, a whole visit, or an entire visitor?

That question is the container, and it is where segmentation stops being an idea and starts being a thing you build.