Salesforce Data 360 Segmentation: Concepts, Types & How It Works

What are Segments

Segmentation definition

Let’s start from the definition perspective. In Data 360, as in multiple other tools that offer this kind of capabilities, segments are nothing more than just data queries. You can define Segmentation in Data 360 as the process of creating queries to identify a specific audience based on shared characteristics, attributes, and behaviors.

In Data 360, the segment result will be a simple list of unique identifiers of records from the Data Model Object (DMO) that you segmented on. Segments can be based on Profile or Engagement data, so you can segment on Unified Individuals, Accounts, Households, Leads, non-unified profile data, or even Sales Orders, Cases, or other engagement-based data that you have in our system.

From the higher-level view, Segment answers who or what will be targeted. Nothing more.

Segmentation vs. Activation vs. Data Graph

In Data 360, you have to create a segment and then activate it using the Activation functionality. But why do you have to create a segment with filters and then an activation with another set of filters? Or why do you have to create a segment and then use the Data Graph to personalize the message in Marketing Cloud Next?

Last sentence from the previous section is crucial for us here - segment answers who will be targeted. But depending on where you want to use this data, you have to use Activation or Data Graph. Activation answers where and with what context people should be sent, and it is used for Cloud Storage, Ads, and Marketing Cloud Engagement activation targets.

The same goes for Data Graph used in Marketing Cloud Next and in other specific cases, but this time it only answers the “what context” part, as in Marketing Cloud Next, segments are consumed directly within Data 360 without being pushed to an external destination.

How Segmentation in Data 360 works

Segment On

Segment On defines the target object used to build our segment. Any Data Model Object that was mapped as the Profile or Engagement category can be used as our “Segment On” entity.

Within segmentation, the object you select for “Segment On” defines the target entity used to build your segment and establishes the strict foundation for how all subsequent attributes are evaluated.

Segment on Unified profile DMOs

Usually, you will segment on Unified DMOs, such as Unified Individual, Unified Account, or Unified Household, which are created and governed by your Identity Resolution rulesets. When you segment on the Unified Individual, Data 360 evaluates the data model and qualifies the Unified Individual if at least one of its underlying, matched Individuals meets your defined filter criteria.

Establishing a unified profile as your “Segment On” entity allows your segmentation rules to evaluate aggregated data and behavioral attributes from across multiple connected sources (within multiple Individuals), rather than evaluating each source record in isolation. This enables you to build audiences based on “a holistic, 360-degree view of the customer”, as Salesforce describes. By merging e-commerce history, loyalty data, service interactions, and any other data into a single queryable entity, campaigns target the person with context from all sources.

Technically, targeting the Unified DMO shifts the payload generated during Activation and acts as an inherent deduplication layer. Because the segment targets the reconciled “unified profile” instead of disjointed Individuals, activations output a single, consolidated payload per Unified entity.

This architecture guarantees that messages are not sent to the same individual across overlapping source systems, while requiring that the activation target is correctly mapped to extract the prioritized contact points (such as the highest-ranking email or phone number) linked to that unified profile.

Segment on non-unified profile DMOs

Segmentation on non-unified profile DMOs is fully supported and typically targets the standard Individual or Account objects, though any distinct profile DMO can be selected as the “Segment On” entity. An Individual profile represents a single, isolated instance of a person originating from a specific external system, such as a distinct SubscriberKey synced from Marketing Cloud Engagement or a distinct Contact Id from CRM.

Unlike unified profiles, selecting a non-unified DMO means the engine evaluates each distinct instance of a person independently across all ingested data streams, treating every source record as its own discrete entity.

From a business and operational standpoint, this approach is highly valuable when your segment rules must be strictly restricted to the context of one specific source system. This strict segmentation evaluation ensures that your criteria analyze only the exact attributes, behaviors, and consent preferences tied directly to that specific source record, explicitly avoiding the blending of data from other systems.

While segmenting at the Individual level simplifies the query evaluation against a single source, you must be acutely aware of its direct impact on the downstream Activation payload. Because the activation is inherently based on the segmented entity, evaluating isolated source records means that if a customer has three distinct profiles across different external systems, they could qualify and enter the segment three separate times (depending on the segment criteria). This introduces a risk of sending duplicate messages.

Segment on Engagement DMO

You can choose Engagement Data Model Objects directly as your “Segment On” entity as well. When you pivot to segmenting on an engagement object, each engagement record fundamentally becomes its own unit of segmentation. For example, if a single customer registers for two different webinars, each registration operates as an independent, distinct record within your segment, rather than rolling up into a generalized list where the customer appears only once.

A perfect example of using Engagement DMO as a segment on an entity is when communication must be triggered by a specific group of events. Suppose a system error occurred where customers who used a specific coupon code received a 10% discount instead of 20%.

To remain compliant and guarantee that a corrective refund email is generated for each sales order, even if a single customer placed multiple affected orders, you would purposefully build your segment based on the Sales Order DMO, rather than evaluating at the Individual or Unified Individual level.

Segmenting directly on an Engagement DMO requires a careful approach, regarding downstream Activation and system performance. Because the segmentation unit is the event itself, the primary key passed in the activation payload will be the Engagement ID (such as the Order ID). Be sure that you have the proper Contact Point Email set during the Activation phase, so the destination system knows where to route the message.

Direct vs Related Attributes

In Salesforce Data 360 segmentation, attributes represent the information or data found in data model objects (DMOs) and are categorized into two distinct types. This classification is strictly dictated by the relationship cardinality established in your Data Model configuration, and the evaluation always originates directly from the object that was selected for “Segment On”.

Direct Attributes (1:1)

Direct attributes are those that have a strict one-to-one relationship with the Segment On object, meaning a user has only one value for that specific record. For example, if the Individual DMO is selected as the Segment On target, intrinsic fields like First Name, Last Name, or Gender are treated as direct attributes.

Additionally, all attributes from other DMOs that are joined to that individual with a strictly defined relationship cardinality of 1:1 will also render as direct attributes, allowing marketers to query straightforward demographic or profile traits without complex logic.

Related Attributes (1:N)

Related attributes possess a one-to-many (1:N) relationship, meaning they could have multiple values per attribute for a specific user. Examples of related attributes include behavioral or transactional data coming from related DMOs, such as Sales Orders, Web Interactions, or Email Engagements.

Because multiple related records can exist for a single profile, developers and marketers must use Containers (or Value Rules) when building segments. Grouping criteria into a single container forces the engine to evaluate the logic against the same related record (e.g., ensuring the same Sales Order contains both “Shoes” and the status “Returned”), rather than matching those distinct criteria across entirely different transactions.

Segment Types

In Data 360, you will find a variety of segment types. They are tailored to different use cases, with different data processing speeds, organizational logic, capabilities, and limitations. You can also find other definitions of segments (e.g., Nested Segments) across documentation or promotional/educational materials.

Standard Segment

Standard Segments are the foundational type, used in most scenarios. It operates on publish schedules and lookback windows. With different schedules, comes different possible variations. For daily and weekly schedules you can define days when segment should be published, for monthly schedules you can choose day of month or set the last day of each month. You have also two publish schedule types:

• Standard Publish - default option, providing a 12 or 24-hour refresh window.
• Rapid Publish - available for Marketing Cloud Engagement, Data 360 or File Storage activation targets, it offers publish every 1 hour or every 4 hours. It looks only at the last 7 days of engagement data and you can build up to 20 rapid segments in your org.

Standard segments also come with a lookback window. It defines the time range of engagement type data that is considered when creating a segment. The default lookback period is 90 days, but you can set a period up to 2 years.

If there is no filter applied to the Event Time field in your segment criteria, the segment will automatically exclude records outside of this lookback window. If the segment criteria specifies a shorter range, e.g., 60 days, these criteria take precedence.

These segments will be the core of your segmentation scenarios in Data 360. They are simple, flexible in terms of criteria, and are the core functionality of this tool, following the Marketing Cloud Next and also Marketing Cloud Engagement activation.

Real-Time Segment

Real-Time Segments are less common, as they require an additional real-time data layer, which includes real-time Ingestion, Data Graph and Identity Resolution. They handle the segmentation process in milliseconds.

These segments rely on real-time Data Graphs, so when the change in data will occur and a customer falls into the criteria, they will be instantly added to the segment and the resulting segment membership will be saved in the real-time Data Graph record.

They also come with limits:

• You can create up to 35 real-time segments
• Real-time segment can include a maximum of 1 Engagement type Data Model Object (DMO)
• Maximum of 1 streaming event can be included in a real-time segment
• You can add only 1 nested segment within a real-time segment
• Exclusions are currently unavailable in real-time segments

If you plan to build a real-time layer in Data 360 (which remains very expensive), you should segment with real-time segments. But with current limits, I assume that only a trickle of Data 360 customers use the real-time layer.

Waterfall Segment

Waterfall Segments are… not segments at all. They are just a list of Standard Segments that you can group and prioritize. This feature provides mutual exclusivity - the visual prioritization of segments within a container with orchestration.

The primary use case is for campaigns with multiple offers, where marketers want to ensure that customers only qualify for one of many potential segments, allowing them to provide more pointed and targeted messaging to the right customers.

For example, if you want to group segments in some hierarchy, like VIP Customers > High LTV Customers > Rest, you can do this with Waterfall Segments and be sure that people from the VIP Customers segment will not be qualified to the High LTV Customers segment and the Rest segment. The same goes for people from High LTV Customers - they will not be qualified to join the Rest segment.

Unlike standard segment activations that might create separate outputs, all waterfall segments are activated to a single Data Extension or file. To distinguish the records, 2 extra columns are added for identification in the activation target.

The current limit of Waterfall Segments is 20 segments per org.

Dynamic Segment

The newest addition to the list is Dynamic Segment. Unlike traditional segments where filter values are static (e.g., “First name is equal to Szymon”), dynamic segments support parameterized filters. You can set a filter to a variable placeholder, and the actual value will be passed down and supplied at runtime by a broadcast flow.

Dynamic segments are faster than standard segments because they operate on interactive engines. They support parallel execution and are evaluated strictly on demand, but, unlike standard segments, dynamic segments have no data persistence. The output of a dynamic segment is not written back to segment membership DMOs, which decouples the segment query execution process from data persistence.

You can’t set a publish schedule for this segment — it can be triggered only via broadcast flows. Dynamic Segment supports Calculated Insights and segment nesting (but only if the nested segment is a standard one).

Dynamic Segments are currently positioned as a perfect tool to provide ad-hoc communication for special groups, like operational notifications (e.g. change of the event date/schedule) or service notifications (e.g. product/service issue), but maybe in the future they will be more flexible and could cover advanced automatic campaign creation.

Nested Segment

Nested Segments are not a “type” themselves, but you can find info about them in many places. They are just standard segments added to other segments. Instead of configuring audience rules from scratch, the system allows you to reference a previously defined segment as a single filter criterion within the logic of a new segment.

You can use nested segments when you have established complex audience definitions that need to be applied repeatedly across multiple new campaigns or segment definitions. A good example is when you want to exclude a specific group of people that received communication (because they were in the segment) - you can do this simply by reusing the segment as a nested segment.

You can choose two segment publish behaviors:

• Use Last Published Membership - better performance and cheaper option, because the system will look for membership criteria, the drawback is that you will base on data from the past, as it will get the data from the last published membership.
• Use Segment Criteria - slower and more expensive, as this option duplicates segment criteria from the nested segment, but in this case you will have fresh data.