“Can we make this real-time?” 

That’s a frequent request for Data Cloud teams, yet it is rarely examined in depth. Many assume real-time segmentation simply removes the wait from existing processes. 

However, real-time segmentation in Data Cloud is fundamentally different and intentionally more limited. 

It uses a separate data path, operates under stricter constraints, and omits several features found in batch segmentation, including exclusions. Recognizing these trade-offs is key. 

Let’s find out when you should be using real-time segments in Data Cloud. 

Activation in Data Cloud 

Batch and real-time are not the only options. Salesforce Data Cloud offers three ways of activation: 

• Standard publish runs on a 12- or 24-hour schedule with the full segmentation toolkit. 
• Rapid publish operates on a 1- or 4-hour schedule, is prioritized over standard segments, and provides the same capabilities. 
• Real-time segments complete on demand in milliseconds, but have significant limitations.

This distinction is important because most requests for real-time processing are driven by the need for faster results than daily schedules provide. In many cases, an hourly schedule is sufficient. 

That is where rapid publishing fits. 

Before planning to use rapid publish, though, note the following two constraints: 

• You can create up to 20 rapid segments
• You cannot convert a standard segment to a rapid schedule after creation

This decision must be made during the initial setup.  

The trade-offs of Salesforce Data Cloud real-time segments

A real-time segment cannot use exclusion criteria, nested batch segments, segment counts, or manual publishing. They’re intended to deliver instant results, not support advanced logic.

Here are the trade-offs associated with real-time segments:

• Real-time capabilities have relatively lower limits. A real-time data graph is limited to 200 KB and approximately 100 million records, compared to about 200 million for standard graphs. 
• Streaming data transforms are capped at 25 per organization, while batch transforms allow up to 1,000. Real-time ingestion supports only streaming; bulk ingestion is not available. 
• Real-time process definitions can be used for batch processing, however not all batch definitions are compatible with real-time processing. Real-time is a subset, not a superset.

If you can’t exclude, what about suppression? 

Suppression logic does not disappear; responsibility for it shifts. It must be managed downstream through activation rules, journey entry logic, or send-time suppression in your execution platform. 

This approach is feasible, but ownership must be clearly defined. Without explicit ownership, teams may activate audiences in real time without applying the necessary segmentation safeguards.

The activation layer also requires identity and contact-point decisions. A unified profile may include data from multiple sources, such as several email addresses or identifiers. Teams should specify which identifier and contact point the destination system will use. Don’t rely on Data Cloud to select the correct option for each use case. Now this is important because inconsistent identity selection can affect contact management, consent handling, and downstream customer tracking.

What real-time requires upstream 

Real-time segmentation is not a configurable option in the segment builder. 

Streaming ingestion via the Web SDK, Mobile SDK, or server-to-server is necessary, as bulk ingestion is not supported for this process. A real-time data graph is also needed. To enable segment functionality, you must add the Segment ID and Timestamp fields from the segment membership object to the graph.

This means the decision to use real time affects more than the segment itself. It influences how data is collected, processed, modeled, and made available throughout the architecture. 

Even beyond costs, spikes in event volume or upstream schema changes can increase processing demands and complicate recovery. Consider source-data stability and the ability to handle unexpected event volumes when designing real-time architecture.

Data Cloud segmentation costs

In Data Cloud, billing is primarily driven by frequency, not complexity. Credits are charged when a segment publishes, not during building or previewing, making audience refresh frequency the key cost factor. Shifting non-time-sensitive calculated insights from hourly to daily refresh can reduce costs by approximately 96%. Additionally, batch processing can be up to 53 times less expensive than streaming for calculated insights. 

These are significant differences. 

At the same time, Data Cloud’s processing speed is only one part of the equation. The destination system must also process and act on the data at the necessary speed. 

Publishing an audience hourly to a destination that updates only once a day increases processing and costs without enhancing the customer experience. Before choosing a real-time or rapid tier, evaluate the responsiveness of the entire activation chain, not just Data Cloud’s audience evaluation speed.

In some cases, an orchestrated schedule may be more effective than a faster fixed one. Segment publishing can follow an upstream process, such as a calculated-insight refresh, ensuring the audience is published only when the necessary data is available.

Remember, you can’t convert a standard segment to a rapid schedule after creation. Reverting a pipeline from streaming back to batch is rarely straightforward. 

Therefore, consider the tier decision as an architectural commitment with ongoing costs. 

Wrapping up 

Real-time processing is essential when immediate decisions are required. However, confirm the need for speed before accepting its associated limitations and costs.

Start by identifying the maximum acceptable delay before a decision loses its relevance:

• If a decision is only relevant during a customer’s active session, such as for an on-site offer, in-app next step, live agent context, or immediate event response, real-time processing is justified. 
• If a decision remains relevant for several minutes or up to an hour, rapid publishing can deliver the needed responsiveness while preserving full segmentation capabilities.
• If a decision remains valid for a day or longer, standard batch processing is typically the most appropriate and cost-effective choice.

The goal is to align processing speed with business value.

Generally, only a small subset of use cases requires the fastest processing tier. For other scenarios, faster processing is not always better; it may simply increase costs and restrictions.