Skip to main content

Building a segment: the membership rules before it activates anywhere

How a Data 360 segment is built: the object you segment on (typically the unified individual), the container-based AND/OR rules that define membership, filtering on Calculated Insights and related-object attributes, and the refresh cadence that decides how fresh the membership is. Building the audience only — where it activates is a sibling page.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

A segment is a saved set of membership rules that resolves to a list of people. Define "customers in Spain with lifetime value over 5,000 who haven't purchased in 90 days," and Data 360 (formerly Data Cloud) evaluates that against the unified profile and hands you back the individuals who qualify. That list is the segment's membership, and producing it correctly is the whole job of this page.

Everything else a segment does happens after this. A built segment is potential energy — it does nothing until it activates somewhere it does work (Data 360 principles, principle 8). This page is the front of that funnel: how the membership is defined. Where it goes (the activation target), how often it ships there (batch publish vs. real-time data action), and what consent permits — those are the sibling pages this one links forward to. Here the subject is narrow and load-bearing: the rules that decide who is in.

What you segment on: the object the membership is counted in

A segment is built on an object — Salesforce calls it the Segment On choice — and that object decides what each member of the resulting list is. Segment on the unified individual and every member is a resolved person; segment on a different DMO and you are building a list of that object instead. For the audiences Cleon builds, the answer is almost always the unified individual: the segment counts people, deduplicated by identity resolution, not raw source rows.

This is the same counting distinction the query layer warns about, seen from the segment side. The unified individual is the resolved profile — one row per real person, after identity resolution merged the source records (Data 360 principles, principle 4). Build the segment on it and "5,000 customers" means five thousand people. Build it on a source-aligned object by mistake and the same rule counts records, which is a different and usually larger number — the kind of mismatch that surfaces as two dashboards that won't reconcile.

The object you segment on is also the anchor every filter is relative to. A rule on the segmentation object is a direct filter on its own attributes; a rule on anything else is a traversal out to a related object, which only works where the relationship is modeled. That distinction is the next two sections.

Membership rules: containers, attributes, and AND/OR

Membership is built from filters grouped into containers. A filter is one condition on one attribute — Country = Spain, Lifetime Value > 5000. A container is a group of filters, and containers are where the logic lives: the operator between filters in a container, and the operator between containers, is AND or OR, and containers nest. That nesting is the entire expressive surface — it is how you say "(in Spain OR in Portugal) AND lifetime value over 5,000 AND not opted out."

Container  (AND)
├─ Country = Spain      OR      Country = Portugal     ← inner container (OR)
├─ Lifetime Value > 5000                               ← filter (AND with the group above)
└─ Email Opt-In = true                                 ← filter (AND)
   the membership is every unified individual the whole tree evaluates true for

The grouping is not cosmetic — it changes who qualifies. A AND (B OR C) and (A AND B) OR C are different audiences, and the segment canvas makes both easy to build, which means it makes the wrong one easy to build too. The discipline is the same one a SQL WHERE clause demands, except the parentheses are containers you drag rather than characters you type: decide the boolean shape of the audience before you arrange the containers, because the nesting is the logic.

Each filter narrows the set; nothing widens it except an OR. A segment with one over-broad container and a pile of ANDs underneath is usually scanning far more of the profile than the final audience needs — which is a cost decision, covered below.

Filtering on a Calculated Insight: retrieve the number, don't recompute it

Some of the most useful membership rules filter on a value the segment can't compute itself — lifetime value, an engagement score, orders per person. You do not re-derive those inside the segment. You define them once as a Calculated Insight and the segment filters on the pre-computed result, the same way it filters on a profile field.

This is principle 7 — compute once, retrieve many — at the point of consumption (consuming query results). The CI surfaces in the segment builder as a direct attribute: "lifetime value over 5,000" is a filter on the CI's measure, and the segment reads the number the CI already aggregated rather than re-running the aggregation on every refresh. Two segments filtering on the same CI agree by construction, because there is one definition of lifetime value and both quote it.

The cost of that convenience is that the segment inherits the CI's grain and its freshness, with no way to see either from the canvas. If the LTV insight is computed per unified individual, the filter means people; if it was accidentally computed at a finer grain, the same filter quietly means something else, and nobody filtering on it can tell (consuming query results). And a daily CI feeding an hourly segment means the membership reacts to a number that can be a day old — the staleness is the CI's, but the segment is where it bites.

Filtering on a related object: the traversal has to be modeled

A rule on the segmentation object is direct. A rule on a related object — "individuals whose orders this quarter exceed a threshold," where Order is a separate DMO — is a traversal, and a traversal works only where the relationship was modeled (relationships & keys). The segment builder lets you reach a related object's attributes exactly when the model already connects the two; where the relationship doesn't exist, the path simply isn't offered, and the rule can't be written.

This is the data-architecture relationship decision seen from the segmentation side: the segment is where an unmodeled traversal finally shows up as a question you can't ask. There is no error — the attribute just isn't there to filter on. The fix is upstream, in the model, with everything already depending on it, which is why the relationships a segment will need are worth modeling before the segment is built (Data 360 principles, principle 1).

One traversal is invisible but always present: the reach from a source-aligned engagement object back to the person. A source object never joins directly to the unified individual — the path runs through the identity link the resolution process maintains, the bridge that ties a source row to the resolved profile it was merged into. You don't write that join, and you can't shortcut it; it exists because identity resolution built it, and a rule that needs to connect an engagement event to a unified person depends on that link being in place. Model the relationship first, and the segment can traverse it; skip it, and the audience you were asked for can't be expressed.

Membership freshness: a segment is as fresh as its last publish

A segment's membership is not live. It is computed when the segment is published, and between publishes it serves the last set of members it resolved — exactly the freshness discipline that governs streams and Calculated Insights (Data 360 principles, principle 6), now applied to the audience itself. Publish on a daily cadence and the membership can be a day stale; the person who qualified this morning isn't in the list until the next run.

The publish cadence is a deliberate choice with a real tradeoff. Standard publish runs on a schedule from every 12 hours up to every 24, and evaluates against up to two years of engagement history — the deep, historical audience. Rapid Segment Publish refreshes far more often, as frequent as hourly, but it trades horizon for speed: it looks only at a recent window (the last seven days of engagement) rather than the full two years, and it targets Marketing Cloud specifically. The choice between them is the same freshness-versus-cost question every layer of Data 360 poses — and how the membership ships once published (and the batch-vs-real-time decision in full) is the activation sibling page, not this one.

The honest framing: decide how fresh the audience needs to be, set the publish cadence to meet that, and write it down next to the segment — so the next person doesn't assume the list is current when it's on a 24-hour clock.

Segment size and cost: you pay for what the rules scan

Cost in Data 360 scales with what you process, not what you store (Data 360 principles, principle 11), and a segment's processing is whatever its rules scan on every publish. A segment with a tight leading filter that eliminates most of the profile early is cheap; one that scans the entire profile every publish to apply a pile of ANDs is a recurring bill wearing a logic decision's clothes.

The size of the result and the cost of producing it are different numbers. A segment that resolves to a small audience can still be expensive if the rules force a full-profile scan to get there. The lever is the shape of the rules: filter on the most selective condition first, lean on Calculated Insights that were already computed rather than forcing recomputation, and don't scan two years of history when the audience only depends on the last ninety days. The cheapest segment is the one whose rules let Data 360 stop early.

What this page is not

Building the membership is one decision; what happens to it is several others, each with its own page in this subcategory. This page deliberately stops at the list of qualifying individuals. What it does not cover, by design:

  • Where the segment activates — the activation target, and why a perfect segment sent to the wrong place is just an expensive query. See activation targets.
  • How it ships — batch publish vs. real-time data action — the central activation decision, the one the whole subcategory turns on. Covered alongside the target, not here.
  • What consent permits — a segment must not be able to activate a person into a channel they opted out of (Data 360 principles, principle 9). See consent and activation.

The order is deliberate: you build a correct membership first, then decide where it goes, how fresh it ships, and what it's allowed to do. This page is step one. The rules that decide who is in are the foundation every later decision stands on — get them wrong and the cleanest activation in the world is delivering the wrong audience, faithfully.

Related

Reference: