Segment Types and Sharing

Everything in this module so far built a single segment, alone, for a single analyst. That is where a segment starts, but it is not where its value comes from. The value shows up when an entire organization agrees on the same definition. If ten analysts each build their own version of "engaged purchasers," slightly differently, then ten reports quietly disagree and nobody trusts any of them. A segment kept in one person's account is a private note. A segment built once, correctly, and circulated is a shared source of truth.

So this section is about everything that surrounds the definition rather than the definition itself: the kinds of segments Adobe offers, how one gets saved and shared with a team, and how a segment can even leave Adobe Analytics entirely to become an audience that Adobe Target or Campaign can act on. The move here is from building a segment to circulating one.

Two ways to build, and a shortcut

Not every segment deserves the same ceremony. Adobe offers two creation paths that trade speed against reach.

A quick segment is the fast path. Built inside a single Workspace project, it does not appear in the Segment manager and cannot be shared, which is exactly right for a slice you need once. When a quick segment turns out to be worth keeping, opening it in the builder and making it available to all projects promotes it into a full saved segment. Templates run the other direction: Adobe ships ready-made definitions for common needs, and you open one, adjust it, and save it under your own name. The saved segment is the one that matters for everything that follows, because only a saved segment can be shared.

The Segment manager: where saved segments live

Every saved segment lands in the Segment manager, the hub for finding, organizing, and sharing them. It lists the segments you own, the ones scoped to all your projects, and the ones others have shared with you, each row showing its owner, the report suite it belongs to, its tags, and how many people it is shared with. Alongside its definition, every segment carries metadata that has nothing to do with logic and everything to do with keeping a library usable: a Title, a Description, and Tags. The description tells the next person what a segment is for without forcing them to open and decode its definition, and tags let the manager filter a crowded library down to what matters, so a search for everything tagged Funnel returns exactly those. This metadata is worth filling in even for a segment only you use today, because the moment it is shared it is the only thing standing between a useful component and an unlabeled mystery. How to name and structure it systematically, so a library stays sane at scale, is its own discipline and belongs to Segment Best Practices. That the fields exist, and that they carry the segment's intent rather than its logic, is this section's point.

Sharing: one definition, many people

By default a saved segment is visible only to the person who created it. Sharing is what turns it from a personal asset into an organizational one, and Adobe offers three widening levels of reach, gated by permission.

A regular user can share the segments they created, and only with individual users, which is the natural way to hand a segment to a colleague for a second opinion. An administrator can go wider, sharing with permission groups defined in the Admin Console, or with the entire organization at once. Sharing carries a subtlety that decides whether an organization's numbers stay aligned, and it is worth understanding precisely.

The Segment manager also lets an administrator mark a segment as approved, a visible signal that it has been vetted and is safe to rely on. The mechanic sits here, but the policy behind it, who is allowed to approve, and how a shared library is curated over time, is a governance question, and this curriculum treats governance as its own subject later on rather than folding it in here.

Publishing: when a segment leaves Analytics

Sharing keeps a segment inside Adobe Analytics, available to other analysts. Publishing does something more ambitious: it turns the segment into an audience the rest of the Adobe Experience Cloud can act on. The same definition of high-value cart abandoners that you analyze in a report can, once published, become a targetable audience in Adobe Target, a campaign audience in Adobe Campaign, or a trait in Audience Manager. One definition serves both analysis and activation.

Publishing is not a casual toggle. It works only if the organization uses Experience Cloud IDs, the shared visitor ID that lets separate Adobe solutions recognize the same person, and an administrator has to grant the segment-publishing permission through a product profile before the option even appears. Once published, the segment's definition reaches the Experience Cloud almost at once, but its membership, the actual list of people, is evaluated on a schedule rather than in real time, so an audience takes a few hours to become fully actionable in the downstream tools. The exact ceilings and timings are the kind of number Adobe revises, so they are recorded here as a dated snapshot rather than stated as permanent fact.

A segment also defines a Virtual Report Suite

Publishing sends a segment outward to other tools, but a segment does structural work closer to home too. A Virtual Report Suite is the parent report suite narrowed to a single slice, one brand, one region, or one app, so a team sees only their own data, and the thing that defines that slice is a segment. Virtual Report Suites covered that mechanism in full; the point worth carrying forward here is that the segment built in this module is the very same object that defines a VRS there. A segment is a reusable unit of logic, and a report is only one of the things that consume it.

Not every segment works everywhere

A segment is not automatically valid in every tool. A definition that runs perfectly in Analysis Workspace can be incompatible with Data Warehouse or Report Builder, often because it mixes container scopes in a way those engines cannot process, or uses sequential logic they do not support. The Segment builder and manager flag this with a compatibility indicator for each destination. It is worth checking before you rely on a segment in an export, because an incompatible segment does not fail loudly at report time. It simply is not available where you expected it, which is a far more confusing way to discover the problem.

Reuse by stacking, not by rebuilding

One more habit separates a tidy segment library from a sprawling one. Rather than building a single elaborate segment for every combination a team asks about, build small, single-purpose segments and stack them: applying two segments to the same report behaves like And, both must be true. Fifty state segments and five channel segments, stacked, answer the same questions as two hundred and fifty combined segments, with a fraction of the upkeep. Stacking is a reuse strategy, and it also draws a clean line against the sequences from Sequential Segments: stacking asks whether things are both true, in any order, while a sequence asks whether one came before another.

From circulating to curating

A segment can now travel. It can be built quickly or saved deliberately, shared with a colleague or an entire company, published as an audience for tools well beyond Analytics, and reused by stacking rather than rebuilding. What none of that guarantees is that the library stays usable. Without discipline, a shared library fills with near-duplicates, cryptic names, and heavy segments nobody remembers the purpose of. Keeping it clean, naming segments so others can find them, knowing when not to create a new one, and watching the performance cost, is a craft of its own. That is Segment Best Practices.