diff --git a/src/pages/docs/channels/options/deltas.mdx b/src/pages/docs/channels/options/deltas.mdx
index c644fc3f8a..e5e47378df 100644
--- a/src/pages/docs/channels/options/deltas.mdx
+++ b/src/pages/docs/channels/options/deltas.mdx
@@ -232,3 +232,9 @@ Note that a channel subscriber can experience a discontinuity in the sequence of
 * There may have been an internal error in the Ably system leading to the server being unable to preserve continuity on the channel.
 
 In these cases, the service indicates the discontinuity to the client, together with the reason, and this is usually visible to the subscriber in a channel `UPDATE` event.
+
+## Related optimization techniques <a id="related-optimization-techniques"/>
+
+- [Conflation](/docs/guides/pub-sub/data-streaming#conflation) delivers only the latest message per key in a time window. Use when intermediate values can be discarded.
+- [Server-side batching](/docs/guides/pub-sub/data-streaming#server-side-batching) groups messages into batches. Use when every message matters but delivery can be slightly delayed.
+- For a comparison of all optimization techniques, see the [Data Streaming guide](/docs/guides/pub-sub/data-streaming).
diff --git a/src/pages/docs/channels/options/index.mdx b/src/pages/docs/channels/options/index.mdx
index 775798840b..70088ffd9f 100644
--- a/src/pages/docs/channels/options/index.mdx
+++ b/src/pages/docs/channels/options/index.mdx
@@ -9,6 +9,10 @@ redirect_from:
 
 Channel options can be used to customize the functionality of channels. This includes enabling features such as [encryption](/docs/channels/options/encryption) and [deltas](/docs/channels/options/deltas), or for a client to retrieve messages published prior to it attaching to a channel using [rewind](/docs/channels/options/rewind).
 
+<Aside data-type='note'>
+Looking for message throughput optimization? For channels with high-frequency updates where only the latest value matters, see [Conflation](/docs/guides/pub-sub/data-streaming#conflation). For server-side message grouping, see [Server-side batching](/docs/guides/pub-sub/data-streaming#server-side-batching).
+</Aside>
+
 Channel options are set under the following properties:
 
 * [`Params`](#params)
diff --git a/src/pages/docs/guides/pub-sub/data-streaming.mdx b/src/pages/docs/guides/pub-sub/data-streaming.mdx
index 14bd543ced..e796bc5c4c 100644
--- a/src/pages/docs/guides/pub-sub/data-streaming.mdx
+++ b/src/pages/docs/guides/pub-sub/data-streaming.mdx
@@ -227,7 +227,7 @@ Here is a simple example illustrating the potential bandwidth savings from delta
 
 The savings increase as match state grows larger over time. This represents significant bandwidth savings while ensuring all users (including new joiners mid-match) receive the complete current state reconstructed from deltas.
 
-## How do I prevent clients from being overwhelmed by stale data?
+## How do I prevent clients from being overwhelmed by stale data? <a id="conflation"/>
 
 In cases such as Cryptocurrency trading, platforms may face a distribution challenge during volatile markets. Individual financial instruments can update 10+ times per second, generating large volumes of price changes. However, consumer applications typically refresh displays every second at most, meaning users never see the majority of intermediate values.
 
@@ -344,6 +344,16 @@ Configure [conflation](/docs/messages#configure-conflation) through [rules](/doc
   Message conflation is mutually exclusive with [server-side batching](/docs/messages/batch#server-side) on a channel or namespace. Choose the optimization that fits your use case.
 </Aside>
 
+### When to consider conflation <a id="when-to-consider-conflation"/>
+
+Consider enabling conflation when:
+- A channel receives frequent updates (even as low as 2-3 messages per second with the same conflation key) and consumers only need the latest value.
+- You want to reduce message delivery volume and associated costs.
+
+<Aside data-type='important'>
+Conflation discards intermediate messages. Within each conflation interval, only the last message for each conflation key is delivered to subscribers. All earlier messages within that window are permanently dropped. They are not stored, not available via history, and cannot be recovered. Do not use conflation for data where every message matters, such as chat messages, transaction events, or ordered commands. If you need to reduce message volume while preserving every message, consider [server-side batching](#server-side-batching) instead.
+</Aside>
+
 ### Key considerations
 
 When implementing message conflation, understand that it discards intermediate messages. Only use this for scenarios where clients need the latest state and missing updates is acceptable, such as prices, positions, or metrics. Never use conflation for chat, transactions, or audit logs where every message matters.
@@ -419,7 +429,7 @@ Here is a simple example illustrating the cost savings from conflation:
 
 The cost savings scale linearly with the number of consumers, making conflation increasingly valuable as your audience grows.
 
-## How do I manage costs and stability during massive bursts of activity?
+## How do I manage costs and stability during massive bursts of activity? <a id="server-side-batching"/>
 
 Live event platforms for sports, concerts, or conferences can face extreme traffic spikes during pivotal moments. When a goal is scored or an exciting moment occurs, thousands of users react simultaneously within seconds. In a 10,000-user room, just 10,000 reactions generate 100 million outbound messages.