10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps

Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps

In Salesforce Data Cloud, constructing effective audience criteria requires a precise understanding of the underlying data model relationships. Marketers frequently assume that dragging attributes onto a canvas behaves like simple spreadsheet filtering. However, because customer data models consist of normalized relational tables with varying cardinalities (1:1, 1:N, and N:M), the way criteria are structured within the canvas dictates the exact logical set operations executed in the lakehouse.

The distinction between Direct Attributes and Related Attributes, and the operational mechanics of the Container Concept, represent the single most heavily tested subject area on the Salesforce Certified Data Cloud Consultant examination. Mastering these concepts prevents costly marketing activation errors where campaigns are delivered to unintended audiences.

---

Direct Attributes: 1:1 Architecture & Evaluation

A Direct Attribute is a field that resides directly on the entity chosen as the "Segment On" target object. When segmenting on UnifiedIndividual__dlm, direct attributes represent the flattened, reconciled profile fields established by Identity Resolution reconciliation rules.

┌─────────────────────────────────────────────────────────────────────────┐
│               DIRECT ATTRIBUTES: 1:1 CARDINALITY MODEL                  │
├─────────────────────────────────────────────────────────────────────────┤
│  Target Entity: UnifiedIndividual__dlm                                  │
│  ┌────────────────────┬───────────────────┬──────────────────────────┐  │
│  │ UnifiedRecordId__c │ FirstName__c      │ BirthDate__c             │  │
│  ├────────────────────┼───────────────────┼──────────────────────────┤  │
│  │ UNIF_001           │ 'Sophia'          │ 1988-04-12               │  │
│  │ UNIF_002           │ 'Marcus'          │ 1995-11-23               │  │
│  └────────────────────┴───────────────────┴──────────────────────────┘  │
│  Each profile row has EXACTLY ONE value per attribute.                  │
└─────────────────────────────────────────────────────────────────────────┘

Characteristics of Direct Attributes

• 1:1 Cardinality: Exactly one record exists on the target entity per customer. A profile cannot have two birthdates or three primary billing countries on UnifiedIndividual.
• Deterministic Single Evaluation: When a filter evaluates BillingCountry == 'Canada', Data Cloud inspects that single value. If it matches, the profile passes; if not, it fails.
• Available Operators:
  • Text: Is Equal To, Is Not Equal To, Contains, Does Not Contain, Starts With, In, Not In, Is Empty, Is Not Empty.
  • Number: Equals, Does Not Equal, Greater Than, Greater Than or Equal, Less Than, Less Than or Equal.
  • Date: Is Between, Is Before, Is After, In The Last (Rolling Days/Weeks/Months), Is Anniversary (Birthdays).
• Query Performance: Extremely fast. Because direct attributes exist on the target entity table itself, the query compiler does not need to perform expensive table joins; it evaluates criteria via simple columnar partition scans.

---

Related Attributes: 1:N Relational Architecture

A Related Attribute is a field that originates from an entity other than the Segment On target object, connected to it via a defined relationship path in the Data Model. These entities typically represent transactional engagements, event logs, service cases, or multi-value profile extensions.

┌─────────────────────────────────────────────────────────────────────────┐
│               RELATED ATTRIBUTES: 1:N CARDINALITY MODEL                 │
├─────────────────────────────────────────────────────────────────────────┤
│  Target Entity: UnifiedIndividual__dlm (Parent: 1)                      │
│  Related Entity: SalesOrder__dlm       (Children: N)                    │
│                                                                         │
│  Customer: Sophia (UNIF_001)                                            │
│  ├── Order #101: 2026-01-15 | Total: $120 | Status: 'Completed'        │
│  ├── Order #102: 2026-05-20 | Total: $45  | Status: 'Returned'         │
│  └── Order #103: 2026-09-02 | Total: $350 | Status: 'Completed'        │
│                                                                         │
│  Customer has MULTIPLE child records. Evaluation requires set logic!   │
└─────────────────────────────────────────────────────────────────────────┘

Canonical Examples of Related DMOs

• Engagement DMOs: SalesOrder__dlm, SalesOrderProduct__dlm, WebsiteEngagement__dlm, EmailEngagement__dlm.
• Service DMOs: Case__dlm, ServiceContract__dlm.
• Loyalty DMOs: LoyaltyMemberTier__dlm, LoyaltyLedger__dlm.

The Join Path Traversal

When segmenting on UnifiedIndividual__dlm, querying a related object like SalesOrder__dlm requires Data Cloud to execute a relational traversal behind the scenes:

1. Start at UnifiedIndividual__dlm (UnifiedRecordId__c).
2. Traverse through the lineage bridge UnifiedLinkIndividual__dlm to find contributing IndividualId__c keys.
3. Join from Individual__dlm to SalesOrder__dlm using the foreign key relationship (e.g., SalesOrder.SoldToCustomerId__c = Individual.Id__c).

Because a customer can have hundreds of orders or thousands of web clicks, evaluating criteria across these child records introduces the necessity of containers.

---

The Container Concept: The Co-Occurrence Engine

The most critical architectural principle in Data Cloud segmentation is The Container Concept. In a 1:N relationship, grouping attributes inside a single container versus separating them across multiple containers fundamentally alters whether criteria must occur on the SAME child record or across ANY child record.

┌─────────────────────────────────────────────────────────────────────────┐
│              THE CONTAINER PRINCIPLE: SAME VS. SEPARATE                 │
├─────────────────────────────────────────────────────────────────────────┤
│  CASE A: SAME CONTAINER (Single Record Co-Occurrence)                   │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ CONTAINER 1 (SalesOrder)                                          │  │
│  │  - OrderDate IN LAST 30 DAYS                                      │  │
│  │  - OrderTotalAmount > 100                                         │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  SQL Meaning: "Does there exist at least ONE SINGLE order that was    │
│  both placed in the last 30 days AND has an amount > $100?"          │
├─────────────────────────────────────────────────────────────────────────┤
│  CASE B: SEPARATE CONTAINERS (Independent Across Any Child Record)      │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ CONTAINER 1 (SalesOrder): OrderDate IN LAST 30 DAYS               │  │
│  └──────────────────────────────────┬────────────────────────────────┘  │
│                                    AND                                  │
│  ┌──────────────────────────────────┴────────────────────────────────┐  │
│  │ CONTAINER 2 (SalesOrder): OrderTotalAmount > 100                  │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│  SQL Meaning: "Does this customer have ANY order in the last 30 days, │
│  AND do they have ANY order (ever!) with an amount > $100?"          │
└─────────────────────────────────────────────────────────────────────────┘

The Underlying SQL Translation

To understand why this distinction is so vital, examine how Data Cloud compiles both scenarios into SQL queries over the lakehouse:

SQL for Case A (Same Container - Co-Occurrence):

/* Same Container: Evaluates within a single correlated EXISTS subquery */
SELECT u.UnifiedRecordId__c
FROM UnifiedIndividual__dlm u
WHERE EXISTS (
    SELECT 1 
    FROM SalesOrder__dlm o
    JOIN UnifiedLinkIndividual__dlm l ON o.SoldToCustomerId__c = l.SourceRecordId__c
    WHERE l.UnifiedRecordId__c = u.UnifiedRecordId__c
      AND o.OrderDate__c >= CURRENT_DATE - INTERVAL '30' DAY
      AND o.OrderTotalAmount__c > 100
);

A customer qualifies only if a single order satisfies BOTH conditions simultaneously.

SQL for Case B (Separate Containers - Independent Evaluation):

/* Separate Containers: Evaluates two independent EXISTS subqueries */
SELECT u.UnifiedRecordId__c
FROM UnifiedIndividual__dlm u
WHERE EXISTS (
    SELECT 1 
    FROM SalesOrder__dlm o1
    JOIN UnifiedLinkIndividual__dlm l1 ON o1.SoldToCustomerId__c = l1.SourceRecordId__c
    WHERE l1.UnifiedRecordId__c = u.UnifiedRecordId__c
      AND o1.OrderDate__c >= CURRENT_DATE - INTERVAL '30' DAY
)
AND EXISTS (
    SELECT 1 
    FROM SalesOrder__dlm o2
    JOIN UnifiedLinkIndividual__dlm l2 ON o2.SoldToCustomerId__c = l2.SourceRecordId__c
    WHERE l2.UnifiedRecordId__c = u.UnifiedRecordId__c
      AND o2.OrderTotalAmount__c > 100
);

A customer qualifies if they bought a $5 coffee yesterday (matches Subquery 1) and bought a $500 laptop three years ago (matches Subquery 2). These are completely different audiences!

Scenario Matrix: Container Architecture in Action

---

Aggregations on Related Attributes

When filtering on 1:N related attributes, marketers often need to evaluate summary metrics rather than individual record fields. Data Cloud provides built-in Aggregation Operators directly on related attribute containers.

┌─────────────────────────────────────────────────────────────────────────┐
│                 AGGREGATION OPERATORS ON RELATED DMOs                   │
├──────────────┬─────────────────────────────┬────────────────────────────┤
│ Operator     │ Target Field Data Type      │ Typical Business Example   │
├──────────────┼─────────────────────────────┼────────────────────────────┤
│ COUNT        │ Record ID / Any field       │ Number of orders >= 3      │
│ SUM          │ Numeric (Amount, Points)    │ Total spend > $1,000       │
│ AVERAGE      │ Numeric (Score, Rating)     │ Average order value > $75  │
│ MINIMUM      │ Numeric or Date             │ Earliest order date < 2024 │
│ MAXIMUM      │ Numeric or Date             │ Latest order date > 30 d   │
└──────────────┴─────────────────────────────┴────────────────────────────┘

Aggregation Filtering with Time Windows

Aggregations can be scoped using nested conditions. For example, a marketer can configure:

• Container Entity: SalesOrder__dlm
• Aggregation: SUM(OrderTotalAmount__c) >= 500
• Nested Filter: OrderDate__c IN The Last 90 Days

Data Cloud first filters the related records to include only those within the last 90 days, and then computes the SUM of OrderTotalAmount across that subset. If the sum is $500 or greater, the customer enters the segment.

Aggregations in Segmentation vs. Calculated Insights

A common architectural dilemma is deciding whether to compute metrics directly within the segmentation canvas or pre-calculate them using a Calculated Insight (CI):

• Use Segmentation Canvas Aggregations: For ad-hoc, campaign-specific aggregations used in only one or two segments (e.g., "Count of purchases in the last 14 days during the flash sale").
• Use Calculated Insights: For enterprise-wide, multi-segment metrics (e.g., LifetimeSpend, RFM_Score, ChurnRisk). CIs pre-aggregate metrics during scheduled batch cycles and store them as indexed dimensions/measures. Dragging a pre-computed CI metric onto the canvas evaluates as a Direct Attribute (1:1), eliminating expensive relational joins during segment evaluation and slashing credit consumption.

---

Critical Exam Traps & Consultant Anti-Patterns

[!CAUTION] Exam Trap 1: The "Split Container" Product Purchase Trap Scenario: "A marketing manager wants to identify high-value customers who purchased both a Tennis Racket and Tennis Balls in the exact same transaction to offer them a complimentary racket cover. The consultant dragged 'ProductCategory == Tennis Racket' into Container 1 and 'ProductCategory == Tennis Balls' into Container 2 with an AND operator. Why will this segment produce inaccurate results?"

• Why it fails: Putting criteria in separate containers evaluates whether the customer has any order with rackets and any order with balls across their entire history. A customer who bought tennis balls three years ago and a racket yesterday will be included! To enforce single-transaction co-occurrence, both criteria must reside within the SAME container at the SalesOrderProduct__dlm level.

[!WARNING] Exam Trap 2: Cardinality Explosion through Multi-Hop Traversal Data Cloud allows traversing relationships up to 4 hops away from the Segment On entity (e.g., UnifiedIndividual -> Individual -> SalesOrder -> SalesOrderProduct -> ProductCategory). However, traversing deep 1:N relationships causes exponential join expansion in distributed queries. If a consultant builds criteria spanning multiple multi-hop child objects simultaneously, segment compilation time and compute credit usage will spike dramatically. The consultant should resolve this by pre-aggregating child attributes into a Calculated Insight.

[!NOTE] Exam Trap 3: Inverting Direct and Related Logic Remember: Direct attributes can never be placed into multiple containers to represent different values because a direct attribute has only one value per profile. Attempting to evaluate UnifiedIndividual.BillingState == 'CA' in Container 1 AND UnifiedIndividual.BillingState == 'NY' in Container 2 with an AND operator will always return 0 records, because no single individual can have a billing state that is simultaneously CA and NY.