10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic

Segment Schedule, Refresh Frequencies & Exclusion Logic

Designing enterprise audiences in Salesforce Data Cloud requires more than configuring filter criteria on a canvas; it requires architecting a sustainable, cost-effective, and operationally synchronized execution strategy. Audiences are dynamic entities: customer attributes change, transactions occur continuously, and opt-outs arrive across multiple channels.

A certified consultant must understand how segment publishing schedules operate, how to balance audience freshness against platform credit consumption, how to implement reusable exclusion logic to honor customer preferences and suppression rules, and how upstream dependencies dictate segment recalculation timing.

---

Segment Publishing Cadences & Scheduling Architecture

When a segment definition is created in Data Cloud, it is initially in a Draft state. To materialize membership and enable activation to downstream targets, the segment must be published. Data Cloud provides several execution models:

┌─────────────────────────────────────────────────────────────────────────┐
│                     SEGMENT REFRESH CADENCE OPTIONS                     │
├──────────────────┬──────────────────────────────────────────────────────┤
│ Cadence          │ Operational Characteristics & Use Cases              │
├──────────────────┼──────────────────────────────────────────────────────┤
│ 12-Hour Cadence  │ Runs twice daily at 12-hour offsets.                 │
│                  │ Used for time-sensitive, high-velocity campaigns.     │
├──────────────────┼──────────────────────────────────────────────────────┤
│ 24-Hour Cadence  │ Runs once daily at a specified scheduled hour.       │
│                  │ Standard enterprise default for regular marketing.   │
├──────────────────┼──────────────────────────────────────────────────────┤
│ Manual           │ Executed on-demand by clicking "Publish Now".        │
│ (Publish Now)    │ Used for campaign launches, testing, and debugging.  │
├──────────────────┼──────────────────────────────────────────────────────┤
│ Don't Refresh    │ Inactive schedule; preserves static snapshot.        │
│ (Static Freeze)  │ Used for one-off historical campaigns and control.   │
└──────────────────┴──────────────────────────────────────────────────────┘

Operational Considerations for Batch Schedules

• Execution Offset Windows: Data Cloud does not guarantee that a 24-hour segment scheduled for 02:00 UTC will finish at exactly 02:01 UTC. Segments enter a managed execution queue. Depending on platform load and the complexity of the compiled SQL, execution typically completes within a predictable window.
• Alignment with Upstream Pipelines: A major consultant error is scheduling segment refreshes before upstream data ingestion and Identity Resolution batch jobs have completed. If CRM data ingests at 01:00 UTC and Identity Resolution runs at 03:00 UTC, scheduling the segment for 02:00 UTC will cause the segment to evaluate against yesterday's stale identity clusters!

---

Streaming Segments: Near-Real-Time Audience Evaluation

While standard batch segments run on 12-hour or 24-hour schedules, certain enterprise scenarios demand immediate audience membership updates. For these use cases, Data Cloud provides Streaming Segments.

Architectural Mechanics of Streaming Segments

• Event-Driven Processing: Streaming segments operate on incoming streaming data streams (ingested via the Web & Mobile SDK or Ingestion API). As streaming events arrive in Data Cloud, the streaming query engine evaluates the event payload nearly instantaneously (within seconds to minutes).
• Downstream Orchestration: When a customer qualifies for a streaming segment, they can immediately trigger a Data Cloud-Triggered Flow or activate to a real-time Data Action Target (e.g., publishing a Platform Event or firing an external webhook).

Batch Segments vs. Streaming Segments

[!NOTE] The Streaming Trade-Off Streaming segments cannot execute complex multi-table joins across deep historical datasets. They trade historical relational depth for real-time velocity. If an audience requires evaluating customer lifetime spend over 3 years combined with offline retail purchases, it must be authored as a Batch Segment, not a Streaming Segment.

---

Segment Exclusion Mechanics: Suppressing Unwanted Audiences

Audience suppression is a fundamental compliance and governance requirement. Enterprise marketers must reliably exclude specific cohorts—such as opted-out individuals, active customer support ticket holders, competitor domains, churned subscribers, or recent purchasers (frequency capping).

Data Cloud provides two primary architectural patterns for audience exclusion:

┌─────────────────────────────────────────────────────────────────────────┐
│                     EXCLUSION ARCHITECTURAL PATTERNS                    │
├────────────────────────────────────┬────────────────────────────────────┤
│ PATTERN 1: IN-CANVAS NOT LOGIC     │ PATTERN 2: SEGMENT-LEVEL EXCLUSION │
├────────────────────────────────────┼────────────────────────────────────┤
│ Criteria configured in container   │ Entire pre-built segment selected  │
│ toggled to "Exclude" (NOT block)   │ as an Exclusion filter             │
│                                    │                                    │
│ Target Audience                    │ Target Audience                    │
│   MINUS Container [Status == Churn]│   EXCEPT [Master Suppression Seg]  │
│                                    │                                    │
│ Scope: Single segment specific     │ Scope: Enterprise-wide reusable    │
└────────────────────────────────────┴────────────────────────────────────┘

Pattern 1: In-Canvas Criteria Exclusion (NOT Logic Containers)

• How It Works: Inside the segmentation canvas, the author adds a container, sets its internal logic, and toggles the container action from Include to Exclude.
• Compiled SQL: Compiles into a WHERE NOT EXISTS (...) or AND attribute != 'value' condition in the generated query.
• Best Used For: Highly specific, campaign-level exclusions that are not reused elsewhere (e.g., "Exclude customers who opened the test pilot email yesterday").

Pattern 2: Segment-on-Segment Exclusion (Exclusion Segments)

• How It Works: In the segment configuration panel, the author selects one or more existing Data Cloud segments to serve as Exclusion Segments.
• Compiled SQL: Compiles into an EXCEPT or NOT IN (SELECT MemberId FROM MarketSegmentMembership WHERE SegmentId = '...') set operation.
• Enterprise Benefits:
  • Centralized Governance: A data governance team can maintain a single "Global Suppression Segment" (containing unsubscribed emails, invalid contact points, competitors, and privacy opt-outs). Marketing teams across the enterprise simply attach this suppression segment to every outbound campaign.
  • Reusability & Maintenance: If the suppression criteria change (e.g., adding a new competitor domain), updating the single suppression segment automatically applies to all dozens of campaign segments that reference it upon their next run.

Comparison: In-Canvas Exclusion vs. Segment-on-Segment Exclusion

---

Resource Consumption, Credit Burn & Execution Performance

In Salesforce Data Cloud, lakehouse query compute is not infinite; it consumes Data Cloud Credits. Every time a segment publishes, the distributed query engine scans columnar data blocks and executes distributed joins. The computational cost scales directly with query complexity, data volume, and refresh frequency.

Credit Consumption Cost Drivers

1. Refresh Frequency: Switching a segment from a 24-hour schedule to a 12-hour schedule doubles the number of daily query executions, effectively doubling the credit consumption for that audience.
2. High-Cardinality 1:N Joins: Segments that traverse multiple 1:N relationship paths (e.g., Individual -> Order -> OrderLineItem -> Product) force the query engine to scan billions of transactional rows.
3. Unbounded Date Ranges: Filtering on related attributes without date constraints (e.g., "Has ANY order ever") prevents the engine from utilizing partition pruning, forcing full-table scans across years of historical data.

Scheduling Best Practices for Performance & Cost

• Reserve 12-Hour Cadence for Fast-Moving Audiences: Only assign 12-hour refresh schedules to campaigns where audience membership shifts materially throughout the day (e.g., cart abandoners, daily flash deals). Quarterly retention or VIP loyalty segments should always run on a 24-hour schedule.
• Schedule Staggering: Avoid scheduling 100 enterprise segments to execute at the exact same hour (e.g., 00:00 UTC). Stagger segment schedules across off-peak hours to avoid query queue contention and compute throttling.
• Freeze Inactive Segments: When a seasonal campaign concludes (e.g., "Black Friday 2026"), immediately switch the segment schedule to Don't Refresh to halt credit burn while preserving historical membership records.

---

Upstream Dependencies & Recalculation Cascades

A pervasive misconception among Data Cloud practitioners is that audience segments update instantaneously whenever underlying data changes. In reality, Data Cloud operates on a strict Upstream Dependency Chain:

┌─────────────────────────────────────────────────────────────────────────┐
│                     THE UPSTREAM DEPENDENCY CASCADE                     │
├─────────────────────────────────────────────────────────────────────────┤
│  1. Ingestion Streams: New orders and contact records ingest into DLOs  │
│                             │                                           │
│  2. Harmonization: DLOs map to canonical DMOs                           │
│                             │                                           │
│  3. Identity Resolution: Match Rules cluster records -> Unified DMOs    │
│                             │                                           │
│  4. Calculated Insights: Batch CI jobs compute metrics (LifetimeSpend)  │
│                             │                                           │
│  5. Segment Refresh: Scheduled query evaluates canvas rules             │
│                             │                                           │
│  6. Activation Publish: Payloads compiled & pushed to Ad/Email targets  │
└─────────────────────────────────────────────────────────────────────────┘

What Happens When Upstream Objects Change?

• New Ingested Data Arrives: Ingesting 10,000 new orders does not alter segment counts until the segment executes its next scheduled or manual run.
• Identity Resolution Ruleset Executes: If an Identity Resolution run merges two previously separate customer clusters into a single Unified Individual, the segment audience size will decrease by one profile—but only after the segment runs again.
• Calculated Insight Recalculates: If a CI updates customer lifetime spend scores at 04:00 UTC, a segment evaluating that CI metric will not reflect the new scores until its own schedule triggers at or after 04:00 UTC.

---

Critical Exam Traps & Consultant Pitfalls

[!WARNING] Exam Trap 1: Scheduling Activation Before Segment Refresh Scenario: "An activation to Marketing Cloud is scheduled daily at 05:00 UTC, while its underlying segment is scheduled to refresh daily at 05:30 UTC. Marketing complains that newly qualified customers are missing from the morning email blast."

• Root Cause: The activation job executes 30 minutes before the segment recalculates! It packages yesterday's stale membership list. The consultant must re-sequence the schedules so the segment refreshes first (e.g., 04:00 UTC) and the activation executes after (e.g., 05:00 UTC).

[!CAUTION] Exam Trap 2: The Exclusion Execution Order Dependency When using Segment-on-Segment Exclusion, the Exclusion Segment must complete its refresh before the primary segment evaluates. If the Exclusion Segment has not completed running, the primary segment will evaluate against an outdated exclusion list, potentially marketing to newly unsubscribed users.

[!NOTE] Exam Trap 3: 12-Hour Refresh on Infrequent Source Data If a client ingests source CRM data via a daily batch file once every 24 hours at midnight, configuring the downstream segment to refresh every 12 hours produces zero new data during the midday run—it merely burns query compute credits re-evaluating the exact same data. Always match segment cadence to the ingestion frequency of the underlying data streams.